[lisp-game-dev] bourtange postmortem

[Schell Scivally]

This is a repost from my blog:

BOURTANGE POSTMORTEM

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!

--
Schell Scivally
schell at efnx.com (efsubenovex at gmail.com)
http://blog.efnx.com
http://github.com/efnx