#68686 - phantom-inker - Thu Jan 26, 2006 10:36 am
I'm head programmer of a small game development group dedicated to bringing our favorite webcomic, the Wotch, to the GBA. We're hobbyists, but we're shooting for professional quality.
We have released a small tech demo of the game in development to give some of the other fans of the comic a chance to see a little of what the game will be like. I thought folks around here might like to see the tech demo as well, so here's a link to our web site, where you can download the tech demo: game's official website
If you don't care to browse the site, here's the ROM itself: tech demo
This tech demo has been intentionally stripped down from the version we currently have in development. Most other rooms, the menus, save-game stuff, titles, full-screen art, and other music have all been removed to keep the download relatively small (although I left some stuff in to avoid having to change the engine too heavily). Our target ROM size for the final game is 64 megabits, although we may end up at 128 megabits by the time we're done, given how much full-screen artwork we'll be using in the storyline.
___________________________________________
I thought I'd also take a quick moment here to post a little about the way the engine works, since no doubt some of you are curious about that.
The sound is handled via Krawall; and Jennie composes our music while Thom records our sound effects.
The video is in mode 0, and all four layers are in 256-color mode; we use a unique tile-remapping algorithm to allow us to draw all our tiles in truecolor in our paint programs and let the engine (and toolchain) deal with all the nasty issues of dithering and palettes. As you can see, it works pretty well. Sprites are still 16-color, although we do use some dynamic allocation there as well. If you observe the sprite memory while the game is running, you'll see odd colors in the top corner of many of the tiles; these colors are actually pointers. The sprite memory itself serves dual purpose as both sprite storage and a simplified malloc for the sprite storage.
We use the usual GNU tools for compiling, and most of the code is written in C++; but we do not use new or delete or most of the OO stuff of C++, and instead just use C++ as "a better C." This keeps the engine more efficient than traditional C++ usage would. Static allocation is used when possible, and dynamic allocation is done using carefully-positioned memory blocks to avoid running out of memory. There are about 15,000 lines of C++ and about 3,000 lines of assembly as well, not counting the heavily-mangled crt0.s that we use. We do not use anyone else's code other than the GBA BIOS, Krawall, and crt0.s, and that includes not using libc.
The rest of our toolchain consists of our own map editor, our own data compressor, our own filesystem manager, and another half-dozen extractor and converter programs of one flavor or another. I wrote all of these, and the engine.
The map editor, Mud, allows us to draw up to 4 tile layers, as well as layers for actions (script to run when the player crosses it), surface classes (change behavior depending on where you're standing, as for water or a dusty road), objects, and blocks (various tile shapes that describe where players can and can't walk). Objects can be placed on any tile layer, which will allow us to do bridges and other multi-layer crossover tricks.
The filesystem manager, Lash, edits a .gba file itself (assuming it contains the necessary embedded headers), and can store a wide variety of debugging data with embedded files if need be. Embedded files may be stored raw or uncompressed, and rearranged in several ways. The filesystem manager is available as both a point-and-click version for our story author and level designer, Lilly, and as a command-line-friendly version so that I can embed it in scripts. All of our assets except the music and except for some of the sprites will eventually end up in the filesystem, since it's designed so that files can actually have O(1) lookup time, even though they're stored by name. Right now, only the tilesets, the maps, and the fullscreen artworks are stored in there.
The objects in the game are handled using quasi-3D: We use fixed-point 3-space and 2-space vector objects for most coordinate management throughout. Objects have mass, and we do factor in concepts like friction and velocity and acceleration separately. Objects are handled via a class-inheritance system that allows each one to act like a miniature thread in a shared threading environment.
We will be using a Lisp derivative to handle scripting and AI. Irene is working on this for us, and knows quite well that both time and space are at a premium on the GBA. But she's a compsci grad student, so that really isn't too hard for her ;-)
Collision-detection, when I finish the code on it, will use 2-D BSP trees for world collisions, sort of like a weird 2-D version of Quake's multiple hulls. The map editor will automatically generate this data from the blockmap layer. The same BSP trees will contain portal data and an all-points-shortest-paths table, which will allow our AI to perform pathfinding operations in O(1) time. Object-object collisions will be handled by maintaining sorted object arrays keyed on their coordinates, hopefully resulting in relatively minimal collision-detection time.
The opening iris trick is done with windows and raster-interrupt techniques. We don't use HDMA, but we do use HBLANK.
I'm trying to think what else is in there, but I'm at a loss for the moment, so I think I'll stop. If anyone has any questions, feel free to ask!
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.
We have released a small tech demo of the game in development to give some of the other fans of the comic a chance to see a little of what the game will be like. I thought folks around here might like to see the tech demo as well, so here's a link to our web site, where you can download the tech demo: game's official website
If you don't care to browse the site, here's the ROM itself: tech demo
This tech demo has been intentionally stripped down from the version we currently have in development. Most other rooms, the menus, save-game stuff, titles, full-screen art, and other music have all been removed to keep the download relatively small (although I left some stuff in to avoid having to change the engine too heavily). Our target ROM size for the final game is 64 megabits, although we may end up at 128 megabits by the time we're done, given how much full-screen artwork we'll be using in the storyline.
___________________________________________
I thought I'd also take a quick moment here to post a little about the way the engine works, since no doubt some of you are curious about that.
The sound is handled via Krawall; and Jennie composes our music while Thom records our sound effects.
The video is in mode 0, and all four layers are in 256-color mode; we use a unique tile-remapping algorithm to allow us to draw all our tiles in truecolor in our paint programs and let the engine (and toolchain) deal with all the nasty issues of dithering and palettes. As you can see, it works pretty well. Sprites are still 16-color, although we do use some dynamic allocation there as well. If you observe the sprite memory while the game is running, you'll see odd colors in the top corner of many of the tiles; these colors are actually pointers. The sprite memory itself serves dual purpose as both sprite storage and a simplified malloc for the sprite storage.
We use the usual GNU tools for compiling, and most of the code is written in C++; but we do not use new or delete or most of the OO stuff of C++, and instead just use C++ as "a better C." This keeps the engine more efficient than traditional C++ usage would. Static allocation is used when possible, and dynamic allocation is done using carefully-positioned memory blocks to avoid running out of memory. There are about 15,000 lines of C++ and about 3,000 lines of assembly as well, not counting the heavily-mangled crt0.s that we use. We do not use anyone else's code other than the GBA BIOS, Krawall, and crt0.s, and that includes not using libc.
The rest of our toolchain consists of our own map editor, our own data compressor, our own filesystem manager, and another half-dozen extractor and converter programs of one flavor or another. I wrote all of these, and the engine.
The map editor, Mud, allows us to draw up to 4 tile layers, as well as layers for actions (script to run when the player crosses it), surface classes (change behavior depending on where you're standing, as for water or a dusty road), objects, and blocks (various tile shapes that describe where players can and can't walk). Objects can be placed on any tile layer, which will allow us to do bridges and other multi-layer crossover tricks.
The filesystem manager, Lash, edits a .gba file itself (assuming it contains the necessary embedded headers), and can store a wide variety of debugging data with embedded files if need be. Embedded files may be stored raw or uncompressed, and rearranged in several ways. The filesystem manager is available as both a point-and-click version for our story author and level designer, Lilly, and as a command-line-friendly version so that I can embed it in scripts. All of our assets except the music and except for some of the sprites will eventually end up in the filesystem, since it's designed so that files can actually have O(1) lookup time, even though they're stored by name. Right now, only the tilesets, the maps, and the fullscreen artworks are stored in there.
The objects in the game are handled using quasi-3D: We use fixed-point 3-space and 2-space vector objects for most coordinate management throughout. Objects have mass, and we do factor in concepts like friction and velocity and acceleration separately. Objects are handled via a class-inheritance system that allows each one to act like a miniature thread in a shared threading environment.
We will be using a Lisp derivative to handle scripting and AI. Irene is working on this for us, and knows quite well that both time and space are at a premium on the GBA. But she's a compsci grad student, so that really isn't too hard for her ;-)
Collision-detection, when I finish the code on it, will use 2-D BSP trees for world collisions, sort of like a weird 2-D version of Quake's multiple hulls. The map editor will automatically generate this data from the blockmap layer. The same BSP trees will contain portal data and an all-points-shortest-paths table, which will allow our AI to perform pathfinding operations in O(1) time. Object-object collisions will be handled by maintaining sorted object arrays keyed on their coordinates, hopefully resulting in relatively minimal collision-detection time.
The opening iris trick is done with windows and raster-interrupt techniques. We don't use HDMA, but we do use HBLANK.
I'm trying to think what else is in there, but I'm at a loss for the moment, so I think I'll stop. If anyone has any questions, feel free to ask!
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.