[lisp-game-dev] LGDC010 entrant questionnaire

[Alastair Bridgewater]

A postmortem, huh?

What I have is about 970 lines of code over nine files, imaginatively
named "game-stuff". There is possibly the beginnings of a classic
dungeon crawl (such as Wizardry or Shining in the Darkness) in there,
but it would need at least another few days of work to bring it out.

1. What I learned:

 * The heart of a UI toolkit is event and redraw management, and is
easier to build than I had thought.

 * Not being able to create game art is a serious handicap for a game
developer, and leads to using more "abstract" visuals ("The pentagon
hath smote thy shoulder for five damage."). This is fine as a
stylistic choice, to a point, but it is far better to not be virtually
forced into it.

 * Not running your game loop in its own thread adversely impacts
SLIME behavior.

 * Running your game loop in its own thread makes use of
*standard-output* for information gathering more annoying.

 * Model-view-controller, or at least view-controller, is still king.

 * Text rendering is still annoying at best.

 * For short-timescale development, such as a 7-day compo, it helps to
have an idea of what you're going to do when you start, actual
practice using the libraries and tools before you start, and to be
able to leverage existing code. I expect that the next time I try one
of these events I'll be better prepared, simply from having a better
idea of what I'm doing, from the code that I produced this time
already written, and possibly from having improved the code in the
interim.

 * As a unit-test library SB-RT is lame. It might be a tolerable
starting point, but it desperately needs some utilities layered over
the top.

2. What went right:

 * Small files and one package per file. This has a number of effects,
mostly promoting the definition of small, close-to-explicitly defined
protocols between parts of the system. Small files applies a certain
"pressure" towards each file doing just one thing. One package per
file leads to explicitly defining what that one thing is and how to
make it happen. On the whole, it's API and protocol design in the
small. I'm not sure how well this scales, but I'm interested in
finding out.

 * Being able to discuss problems on IRC. Especially if it's a problem
with an unfamiliar library (such as OpenGL), or a problem with common
tools such as SLIME, or how to structure some part of your system,
feedback and suggestions from other people can help immensely.

 * Using OpenGL for 2d rendering. I don't know if this went right, or
simply didn't go wrong, but I'll give it the benefit of the doubt.

 * Swiping ideas from other people and code from my own copious
archives (though there's not much -game- code in my archives).

3. What went wrong:

 * The GLX implementation I used is still more than a little rough
around the edges (incomplete, not well documented, and has an awful
tendency to ignore commands if the parameters are of the "wrong"
type).

 * I was badly distracted in several different directions over the
course of the event, including attempting to get a video capture
device working properly in one of my computers.

 * The tool support for working with lots of small packages instead of
few large packages is either non-obvious or non-existent. This was
most noticeable when "splitting" a package, moving some of its
functionality to a new package.

 * I have no mouth texture image, and I must scream.

4. What was lispy:

 * I used SBCL, CLX, and the GLX implementation in CLX.

 * Redefining input handling and redraw completely while the main loop
was still running.

 * Using generic functions for output redraw control.

 * Using first-class functions for input handling.

5. What interesting algorithms or designs were involved:

 * I swiped the pseudo-3d maze bits from an old X program I wrote back
in 2004 that used line-drawing primitives to lay out the maze views
(much as the original Apple ][ Wizardry did).

 * In order to issue a glCallLists request for drawing text on the
screen, I copy the string to be output and smash up the type and
length bits of the copy to be consistent with an octet vector, then
ship the octet vector off to the server. This is horribly
SBCL-specific, but it gets the job done.

 * All visual output ended up being performed in terms of "widget"
objects that were on a global list. This list was set up via
defparameter, so I ended up being able to experiment with new widgets
and widget parameters by simply reevaluating a variable initialization
instead of involving the main redraw function or reinitializing the
entire main loop.

 6. What I believe I need to do going forward.

 * Start working on producing decent 2d game art. This is one of my
major handicaps, and I'd like it to be at least partly compensated
for.

 * The input model in game-stuff is lame, and needs a rewrite. Just as
soon as I figure out what wouldn't be lame.

 * My current text-message widget is static-text only. Being able to
treat it as an output stream, or at least to be able to write new
messages into it without recompiling it, would make it actually
-useful-.

 * Fix some of the outstanding issues with the GLX I'm using.

 * Learn more about the OpenGL rendering model, especially the matrix
stack and various glEnable options.

 * Produce an actual, end-to-end, full game. Even if the plot is
basically "go down to the bottom of the dungeon, kill the evil wizard
Riatsala and recover his Book of Primary Aspiration" it would at least
be a full game, and that would be a first for me.

 * Sink some effort into improving my tools, both in terms of
development environment and in terms of available libraries and
documentation. Note that this expressly does -not- mean
compiler-backend hacks (my usual playground).

I think that's basically it, and I'm looking forward to the next LGDC.

-- Alastair Bridgewater