The tip number 5 says Choose tools that respond quickly.
And this reminds me of the Tuuli development, and how Inform 7 takes ages to compile and run each time we hit the play button. I found myself, in each micro tweak, taking several seconds (too much) and me tabbing to social networks that do not contribute to a healthy use of my time.
This is not to complain about Inform 7 (or yes), I don’t pretend that Graham does magic to fix something that is not a real problem. I mean Inform 7 does a lot of hard stuff in the background, and I’m already pretty grateful of I7 as is. I wish more tools were like I7, and I’m glad it has been a cool influence for others IDEs like Twine or Inky.
I just wanted to comment on that fact, and how the Alexis’ article ring a bell in my experience with the Tuuli’s development.
Do you feel the same? Do you have some techniques to easy this effect of “wasted time”? (oh f&$% now I remember the time as a website builder using Wordpress, THAT was wasting time.)
Also, maybe I should program and fix bugs extensively, instead of micro fix, and micro mingle with the code. Or just shut the twitter up!!!
I know this is not the point of your post, but you may have read that Windows Inform 7 is the only platform that seems to encounter consistent compile delays (usually of between 5 to 30 seconds). On the Mac I barely notice it.
In this context (development), part of this is the ability to break up elements of work into multiple source files. TADS, for example, does conditional compilation which can make even the very largest games compile very quickly, particularly because you can modularize how you want – one file per NPC, one file per location, etc. So sometimes being able to respond quickly is simply being able to easily compartmentalize aspects. The more everything is jammed together – even with a nice index feature, like Inform 7 has – the more you can spend time analyzing rather than doing. This is the case regardless of compile time.
But then again, Inform 7 does have that amazing index and that can be a powerful element in being able to reason about what you have coded. However, it doesn’t really provide insight into the core aspects of IF: which is how a story / game plays out. The Skein / Transcript try to do that, but with a (potentially) lot of analysis overhead.
Also part of this is the ease of testing tools but also the ability of those tools to do their own analysis – hence, assertions, expectations, and so forth. I’ve been playing around with this in both TADS and Inform. Testing is always a help but if you have to manually analyze a bunch of stuff, the savings in time start to disappear. So the ability to run focused, isolated tests across modular aspects of code is also critical. In fact, if you can count on the tests doing a lot of the analysis for you, the compile time itself may not matter as much.
Anecdote: As part of my consulting career, previously I had done what’s called Story and Narrative Experience testing for Rockstar (Grand Theft Auto 5; fun!) and BioWare (Star Wars: The Old Republic; not so much fun). Critical to that kind of testing there were composable scenarios and workflows for how the narrative and plot elements were presented (pacing, reveal, etc). The compiles took a long time – but we had a solid idea of what to explore further because we were able to trust our tests and the analysis we got.
To me, IF development is no different than any other game development which is in turn no different than any other kind of development: you have to morph the cost of change curve to the cost of mistake curve. That means you can make as many mistakes as you want (here “mistakes” can be a desire to change how the narrative plays out). What matters is the feedback loop. In other words, what is the duration between the time you made a “mistake” and the time you found it. The longer that feedback loop is – even if it’s just the additive amount of time for compile – the more friction sets in with the development process overall.
I use Inform 7 on a Mac, and I’ve also found testing games inside the program with the Go button to be very slow. What I discovered is that it’s actually much faster to just compile a gblorb with Release and open that for testing purposes. Might be worth trying if other people have the same problem.
In HL development, I think I hacked the build setup to not generate the gameinfo.dbg (debug symbols) file. That got “Go” up to the same speed as “Release”. It still took a couple of seconds (on a 2011-era Mac) but that was acceptable for a quick code-and-test cycle.
Of course HL is a very large game. This trick wasn’t necessary until I had a whole lot of objects and topics in the source.
Well, Tuuli is a game that almost fit in z8, so yes, it is a very short game to compile. Probably is the problem of the windows build. I will try those suggestions, to try to release instead of “play”. Thanks!
If you’re using Windows Defender, that has a nasty habit of interfering with the compilation process by examining each HTML file produced when the index is built by the compiler. See “Help / Windows Inform Notes” from the Windows Inform 7 front-end. Unfortunately there’s little to be done about this other than providing instructions on how to try to exclude the affected directories and/or executables.
I’ve deactivated Windows Defender right away, with the main switch, and BAM! there it was. Inform 7 compiling in less than 5 seconds!
Well, People (I) usually don’t read help notes, but “Windows Inform Notes” don’t say anything at all about the issue.
Also if someone knows how to prevent Windows Defender to examine those files, that would be helpful. Although deactivating WD for work is a viable approach for me.
Good to hear that that helps. I can’t remember exactly when I added the note about Windows Defender to the “Windows Inform Notes” page in the help, but it was probably after the initial release of 6M62 - there have been a few updates to the Windows build since the initial release.
It’s difficult to know what to do about this issue, other than keep on mentioning it when people ask here. There’s no obvious way in code to tell if Windows Defender is going to get in the way, nor any obvious way to stop it (unsurprisingly).
I’m sorry to not to search for the issue previously, I was commenting the thing mindlessly, but I’m glad I did it. I think I should edit the title of this thread.
Is there a way in code whether it is getting in the way (during compilation), or just to tell how long compilation took? I.e. if it takes a suspiciously long time (relative to the size of the input file) then advice about WD exceptions might be appropriate in the compilation report.
There’s no way to tell that Windows Defender is definitely causing a problem, but timing compilation is certainly possible. The problem there is that you end up guessing what the ‘correct’ compilation time should be, and there’s always the risk of a false positive. It’s certainly something to consider, though.