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