Nightly builds and Inform 7: release builds

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.

A year of Github

So I made my first commit to GitHub a year ago. It wasn't much, but the daily streak eventually helped me to REALLY get going.

Since then, I've

* made documentation and code changes to Trizbort
* made repositories for my 2012-2015 IFComp games
* also merged in my 2013 Spring Thing game with 2012
* created a miscellaneous files archive for all kinds of things
* copied over some of my old RPG map creation files
* made 1000+ changes
* started an almost 5 month + daily streak

This is a lot, and I can't call myself a GIT wizard. I just know the basic commands. In fact, I have a cheat sheet for some of them below the cut.

So why am I posting this to planet-if?

Because many people I know have questions. They wonder how to get started. They think it'll be impossible.

But I think the way to start is to say, okay, I want some sort of backup so my files don't get lost. I'll push story.ni to it. I don't care about anything else. Maybe I'll report an issue. And then build from there. That's how I did it. Just pushing trivial changes, maybe even starting with something silly like an EctoComp entry where I needed to clear up typos.

The drawback is that I've neglected bitbucket, which doesn't have that small nudge. But I've done well with modifying my current Spring Thing game as well as my possible IFComp 2016 game.

My cheat-sheet is below. I'm not worried about too much else. Clone, commit and push are all you need to know. I even forget the difference between clone and fetch--but the nice thing is, you can't ruin too much. So go ahead. Make a blank project. Poke around. Start with small changes. You might be happy and impressed what you've come up with.

Spring Thing 2016! Go! Play! Enjoy! Judge!

It's good to see so many works in Spring Thing this year. I barely scraped by, and I'm grateful that Aaron allowed a bit of post-April 1 tweaking to shake out an embarrassing bug or two as well as (I hope) latitude for a post like this. (If not, I'll delete this.) Thanks to my testers for putting up with something that must've been frustrating.

I won't say much about my game, but chatter on Euphoria seems to indicate that some authors really love other authors' works. The IFDB already has game info and a few reviews.

So, this was meant to be a post-comp release post-mortem of Problems Compound, but that'll wait. Especially since I found a bug--and then, how I should've tested for it.

I'd like to post reviews post-Spring Thing of works I got to, but I don't feel comfortable doing so now, although Aaron Reed wants to be lenient about author commentary. Go play the games, and don't worry about (not) playing mine. I'm glad it's out of the way, and I think it's easier than Ugly Oafs.

I plan to submit a post-comp release of my game along with Threediopolis.