This probably applies more to Inform 7 than anything else, but I like the idea of having a nightly build with tests that report success or failure. This came about as a result of me finally wanting to nail down a few things in some old projects. But I know a big trouble fellow writers have had is...they build a debug version of their story okay for months, then ... the release version throws a bug! Usually it's pretty easy to fix, but it's still a bit of panic on September 20th or so.
Now it started as just checking stuff not related to compiling.
# my source code had no [??] annotations -- shorthand for something I should get around to understanding
# test chapters/volumes were minimally annotated e.g.
volume x
book skip
[* this tests ways to skip to certain puzzles. Usage is SKIP NUMBER]
# for the -opolis, making sure the walkthroughs I wrote correspond to the entries in the tables of things to find. This only tests that what we've found so far is accurate.
# for the Stale Tales Slate, checking the viability of certain random entries and also checking for duplicate entries, as well as sorting the tables in alphabetical order etc.
## verifying that the random text is capitalized properly
This is all stuff I ran by hand but it piled up. Finally I put it all into a nightly build and--well, there were a lot of errors! But they were finally organized and helped me see other details. And I knocked things off quickly.
For instance,the capitalization I was able to break down into ALL CAPS, Title Case, Sentence case, lower case needed, and any case being okay. Maybe you have other tests you can run. Apparently linux lets you run tests on a blorb from the command line somehow & that would be the next part of my nightly builds, to make sure nothing breaks.
So, the moral? It may feel silly making a nightly build to track your projects that are "just games" but it helped me take care of a bunch of details I'd let sit for a long time.
Now, how to do this? For those with Windows you can have your Task Scheduler send output to a log file, or even reparse it to an HTML file, every day. Then you can see if release or debug builds work okay. (I don't use the IDE for when I'm writing narrative stuff. I just check what's changed with Git and then test that all in one bunch.)
You'll have to change the name of the project, obviously. And if you are using zcode, you'll want to see the different flags in the "progress" tab of "errors." The below compiles for glulx.
"erase c:\games\inform\fourdiopolis.inform\Build\output.ulx"
"erase c:\games\inform\fourdiopolis.inform\Build\output.gblorb"
This is so yesterday's built binary doesn't pretend it's the result of today's failed build.
"C:\Program Files (x86)\Inform 7\Compilers\ni" -release -rules "C:\Program Files (x86)\Inform 7\Inform7\Extensions" -package "C:\games\inform\fourdiopolis.inform" -extension=ulx
This may throw an "unable to open directory" warning but it creates an auto.inf (Inform 6 code) in ..\Build, where (etc)\Source is where story.ni is.
"C:\Program Files (x86)\Inform 7\Compilers\inform-633" -kw~S~DG +include_path=c:\games\inform\fourdiopolis.inform\Source,c:\games\inform\fourdiopolis.inform c:\games\inform\fourdiopolis.inform\Build\auto.inf c:\games\inform\fourdiopolis.inform\Build\output.ulx
This compiles into an actual ULX file. If you use 6G65 as I do, you may only have inform compiler 632, but I recommend 633. It has more helpful error messages. If necessary, download 633 and rename it to 632.
"C:\Program Files (x86)\Inform 7\Compilers\cblorb" -windows c:\games\inform\fourdiopolis.inform\Release.blurb c:\games\inform\fourdiopolis.inform\Build\output.gblorb
##note you can/should probably not use a batch file, but the general idea works, here.
if EXIST c:\games\inform\fourdiopolis.inform\Build\output.gblorb (
echo SUCCESS
)
if NOT EXIST c:\games\inform\fourdiopolis.inform\Build\output.gblorb (
echo FAILURE
)
No comments:
Post a Comment