Posts Tagged ‘contest’

Bourtange Postmortem (ILGE 2010)

Wednesday, August 11th, 2010

Bourtange @ github

Overall I’m satisfied with my lisp game. My major goals were to learn lisp (to a shallow yet useable degree), learn a little about functional programming and last but not least to end up with a playable game. I feel I hit those goals and as an added bonus I’ve enjoyed programming in lisp so much that I’m looking for another project to start working on. That said, here is an explanation of what went into the game, what went right and what went wrong.

Built with
I made the bulk of the game using sbcl with cl-opengl for graphics and TextMate for editing. I wrote some custom ‘build’ scripts to send my monolithic game file to the sbcl repl. The development cycle was similar to what you’d expect from programming in C, ‘write->compile->test’. Later on after my first version I got help from the guys at #lispgames (irc.freenode.net) (sykopomp, xristos, 3b) with setting up emacs and using slime-connect, as well as setting up a .asd for my game. Using the interactive dev env that emacs + slime enables is really a liberating way to program.

What went right
* My game is playable! More often than not I leave my game projects in an unplayable (sometimes not compilable) state. I’m proud to say that this game is playable.
* The difficulty of the game goes up over time.
* I tried to program in a very functional way, which worked most of the time. It enabled my program to easily reset, and should allow for a fairly easy save function, but I never got into file i/o to finish that.
* The colors are cool

What went wrong
* Writing in a functional way messed me up a little. I tried my best to make things functional, without really having a firm grasp on what that means. I would give up on writing functionally and go back to just making things work when the going got tough. This means that in the end, I feel the code is naive and dirty.
* Collision detection is very simple. This would be fine if things didn’t move very fast, but when using gravitational equations for motion, things get very fast when they get very close. In order to keep the collision detection simple I put limits on how fast things can move. It works, but it’s dirty.
* After something gets hit I recalculate 360 points of an arc to display the life left. Halfway through development I wanted to have all the circles be drawn using ONE list of points generated ONCE. I could draw some percentage of the points to represent life lost. When I tried to refactor for this, drawing became very, very broken. If I had more time to work this out I think the game would be much faster and much smoother.

All in all, I’m pleased. I hope you play my game, and I hope you have fun playing it!


Follow me on GitHub
Follow me on Google+
Follow me on Twitter