IFComp 2015 Devblog #3: More small tools, and when to write or borrow them

I haven't actually been getting a ton of game done, but I have been knocking out things that've delayed me before. That's really important, because at the end I wind up with a lot of things I could've/should've done later.

Now, I do due diligence to check for something that already does what I want, but the thing is--if a script can take just a few minutes to put together, or if I'm able to modify it by myself, that's a big help. I like being able to write my own control language (which is far less technical than it sounds) because it gives me a feeling of autonomy. Also I may not have the bells and whistles of a bigger project.

Whether you should write your own scripts or search for them on the web is a tricky question, but I generally proceed with a couple Google searches, then I allow myself 15 minutes to write an adequate script. Often I put those 15 minutes when I would've been messing around anyway, so it is not time lost.

I'd think even an hour would be worth it--the thing is, I just want to have stuff to do instead of time-wasting, and personal projects are very good. I've found that writing my own code and finding someone who did it better, later, has given me faith that I can take that much more help from other people I don't know.

And here I like the quote of the perfect being the enemy of the good. Perfect = finding an app that does nearly exactly what you want. Good = being able to write something up that does what I want, basically and quickly. Perfect could also be the app doing everything I want--but I've found that I can tweak my code if a missing feature becomes annoying. A good time is the next time my mind would wander.

My question at IFAnswers.com on how best to back things up provided an interesting discussion. I provided a script for Windows or Unix, and someone promptly wrote up system-based ways to back things up. I was glad to see this, and it reminded me to look for this sort of solution first before spending my own time.

Though for what it's worth, I like being able to back files up by number: story.ni to story-2015-04-16-11-40-00.ni, or whatever. It just appeals to me aesthetically. I can also easily see how the file size grows with time, to track how much/well I'm working. So I think my programming time was well spent.


My two big scripts were:

• something that runs automatically every day to notify me if I haven't modified a critical file in X days (e.g. my hint file, or my walkthrough, or even the GBLORB...because if a release version doesn't build, that's a pain) as I think one of the big thing to avoid is long periods of inactivity. You need to nudge yourself to keep moving. We all have our own ways.
• a release-bundler. My big problem with release and crunch time is, I'm never sure if I have the right version. Or, I make one small good change, and I'm worried I'll forget to update a walkthrough.

I'd like to show off a chunk of code for the Ugly Oafs release, which was a pain. I figured it would be a great dry run because my IFComp 2015 game won't need all this, so it'll be a breeze by comparison. Also, it's just good to be organized.

name=uglyoafs,uo,14
v=3
out=ugly_oafs_release_%.zip
>>soffice --headless --convert-to pdf c:/games/inform/uglyoafs.inform/Source/uo.odt --outdir c:/games/inform/uglyoafs.inform/Source --headless
>>pdftk A=c:/games/inform/uglyoafs.inform/Source/uo.pdf B=c:/games/inform/triz/uoup.pdf C=c:/games/inform/triz/uodn.pdf cat A1-6 B C A7 output ugly-oafs-guide.pdf
F=c:/games/inform/zip/ugly-oafs-guide.pdf
F=c:/games/inform/uglyoafs.inform/Source/story.ni
F=c:\Users\Andrew\Dropbox\notes\ugly_oafs_release_%_notes.txt
F=C:\games\inform\uglyoafs Materials\Release\Ugly Oafs.gblorb
F=C:\games\inform\uglyoafs Materials\Release\ugly-oafs-invisiclues.htm

This looks like a mouthful, but let's break it down.

• name=the name of the project. So I can say zip-up.pl uo, zip-up.pl 14, or whichever, and the program runs.
• v=the version
• out=the output zip file name. You'll notice the %, which maps to the version number.
• >>soffice (etc): I recently downloaded LibreOffice, which allows you to convert documents to PDF on the command line. This is an example.
• >>pdftk (etc): this is another useful tool for merging and sorting PDFs. In this case, what I do is to take all but the past page of the manual, then insert two Trizbort-produced graphics before the last page, which is an appendix. Now, I'll have to adjust the numbers if another page is added--and maybe there's a way to specify 2nd-last pages. But for now, this works, and it's easily changeable.
• F=* the files to add to the ZIP. Again, % points the script to the current version number.
• The script ends with a blank/empty line

You may've noticed I used a lot of 3rd-party software. 7-zip is indispensible to me, to be able to create zip files from the command line. Mac/Linux users probably won't need it, but the reason I like it is because you can write a simple batch file to re-copy over critical files. Fiddling with the mouse takes energy.

"Control language" may seem like a 5-dollar word, but once you are able to parse one file, it becomes easier. I've used it for work and home projects, and each has bolstered the other. I can be as serious or detailed as I want, when I want, and it's not hard to add.

One side benefit of this was that I included some code-checking scripts in with the assembly, so that helped me detect big problems in my Stale Tales Slate. For instance, if any of the book names were wrong, or if punctuation in any of my random text was off. Having five checking scripts run at once with an easier mnemonic (zup.pl roil vs. typing the script names) has certainly made details way less.

If anyone is interested in this perl script, I would be glad to send it to them. It is under 2K, and it's great to have one less potential logistical nightmare in six mo--oh, geez, it's closer to five months already.