I recently gave a talk at lispvan about using PLT scheme for game development. You can grab the videos from Bill Clementson’s blog http://bc.tech.coop/blog/080620.html. The audio is a little dirty, but that’s what happens when you go to a bar to talk with friends. I’d like thank everyone at lispvan for putting up with my mad ramblings. In this talk I describe a system that lets me develop the heart of a game engine’s functionality:
resize, is for system (re)initialization. It lets you setup the viewing plane, and long lived information.
draw, is for a single update of the canvas. It must be stateless in itself and completely data driven. You should be able to regain any view by providing the correct scene data.
update, is were you manipulate scene data. In my simple example it’s where I placed orbit cam update code.
Using this division, it’s possible to develop your game engine in bits and stitch them together later. AI can be developed within the update code with a simple draw representation. Fancy graphics can be developed within a static or controlled scene. Particles are developed parametrically and providing a “video” scrubber in the update function will be of use.
You can see how using this division a protocol between update and draw gets built up. This protocol is what is generally referred to as a scene graph. It’s normally saved as a single global object/tree/array of lists that sub-functions of update or draw can directly access (whether global is correct or not is debatable).
Prior development has focused on a generic scene graph for all occasions. This has lead to brittle or overly complex scene graph systems for the task at hand.
If you can remember that a scene graph sits between the update and draw (update ==> scene graph ==> draw) you will save yourself a boat load of development pain.