My personal post-mortem

Posted by
May 18th, 2013 7:21 pm

Well, this has been a great ride.  Pixel Dust was a great first (complete-able) LD and the following are some notes, especially to myself, for the next round:

  • Do not bother with an editor (yes, there is one, but it’s obfuscated).  Use static, static, static files or better yet internal data structures instead.  PD started with internal data only but ended up wasting time with an editor half-way through — though it reused a lot of the code from the player.
    Screenshot from 2013-05-18 22:14:51
  • Focus on instructions and user hand-holding more.  PD has them, but they could have used a lot more attention.  In fact, in future make sure to write them as early on as possible (after getting some prototype working) as a test of the game design.
  • Don’t add scoring/win condition stuff too close to the end of the project.  One reason PD is so unbeatable on some screens is partially due to a bug whose fix I’m holding until after the LD compo.  That bug stems from trying to add a scoring mechanic right at the end of development.  Try to get all game-mechanic related stuff done by the mid-way checkpoint.
  • More UI drawings should be made immediately following basic analysis.
  • Save more time for “flair”.  A simple score update animation would have made a world of difference — we’ll see after the post-compo update.  also animations relating to the “dust” in Pixel Dust might have been good.
  • Spend more time on the release message.  Just copying the journal doesn’t cut it.
  • Possibly be more willing to adjust issues after the compo.  The rules for this are a bit hazy, but I’m thinking I could have fixed my scoring bug following submission.
  • Get all hosting/repo stuff out of the way ahead of time.
  • Need to add a place to gather issues right on the web interface (even if a link back to github).
  • GAE was a mixed bag.  Got things going quickly, but did have to spend a little time working through GAE issues/idiosyncrasies as well (especially in the process of storing/retrieving boards from the DB — see point 1 though).

Some things that worked well:

  • Brainstorming/analysis phase — that first 1-2 hours of analyzing the options was a clear help.
  • HTML — worked fine for this type of project and make most of it cross-compatible.  I suspect that faster games might require too much tuning though to keep fast.
  • Web server from the start — if using HTML, why not?
  • Use of TODO file instead of standard bug/issue tracker to develop initial features.  This ties the results nicely with the version control and is very quick to manage.  Consider adding a trigger to make sure the file changes on every merge, especially to master.
  • Avoiding graphics saved a lot of time, but that was partially because of the theme.  May not be so lucky next time, but definitely avoiding making pictures is a time saver.
  • Making the site look and feel flow reasonably well with the game.

And most importantly — make sure to have fun; if you don’t, likely no one else will either!

And I did with Pixel Dust.  Hopefully others will too as the post-compo updates are deployed.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]