LGDC 2010/Summer / ILGE 2010 entry postmortem

Ran out of energy before getting much more done than the last progress report, so the actual '7-day game' part didn't go too well.

Final results after 7 days (+ a few minutes extra to make it use more than just 2 sprites), move with arrow keys/wasd/hjkl:

What went wrong?

• Working on non-game stuff:

  I spent a few days of the scheduled 7 working on slime/parenscript stuff, which while probably more useful long-term, didn't really do much towards getting a game done in 7 days.

  Another chunk of time was eaten by working on my blog software, I probably would have been better off just using some hosted blog service somewhere, and only worry about maintaining my own software for things that need it (mostly presenting code nicely, and even that might have been better handled at the editor level)

• R&D instead of getting work done:

  The next big chunk of wasted time was spent on messing with some ideas for generating infinite ground tiles, which probably wouldn't have matched the pixel art sprites I was using even if it had worked.

• Not knowing JS well enough:

  In particular, I still haven't figured out a good way to handle OO stuff, and most of what I could find on the subject only agreed to the extent of disliking the built-in new Foo() idiom.

• Scope:

  While I hadn't really planned in enough detail to say that the scope was too large, a more focused plan might have helped avoid getting sidetracked onto the random terrain texture generation stuff.

• Deployment:

  One small downside of working on browser code from SLIME is that doesn't lead quite as naturally to having a set of files ready to put on a website. Probably will want some combination of telling ASDF to compile the parenscript files to .js, and writing out the .js files when compiling a file from SLIME.

What went right?

• SLIME + Parenscript:

  Being able to use SLIME while working on code running in the browser is much nicer than having to constantly reload the browser(s) after every change. It takes fewer keystrokes to see the results of a change, and maintaining state makes it much easier to test things incrementally.

• Free art:

  While I like the idea of procedural content, a short project like this doesn't really have time to spend on developing experimental tools. Having art available with a nice license makes it much easier to get started quickly, and seeing little people wandering around is much more motivating than little boxes or other "programmer art" would be.

• <canvas>:

  Aside from some minor annoyances like not being able to portably stretch the sprites without smoothing, the HTML canvas seems reasonably easy to use, and seemed to perform fairly well.