I have decided to keep a diary of the Treasure Tomb development for posterity, like the Alien Flux one before it somewhere on the java-gaming.org forums. It might be an amusing read for you, or enlightening. Mostly though, it’s my public trail of shame. Can’t quit on this game if you have to see a daily progress, eh?
28th June 2007
So: where are we with development for starters?
With the guts of Monster Mash ripped out and a quick package name refactor, I’ve got a basic game framework set up in Eclipse that launches and has a title screen, register screen, nag screen, hiscores screen, options screen, help screen, and credits screen. Of course all of the graphics and layouts are from Monster Mash (I just scribble over the top of the title with “TREASURE TOMB” using the Gimp) and it’s for Chaz to sort out later. But there we have it - the cradle in which a game sits.
Currently tapping M on the title screen brings us to the Map Editor. I’ve decided to do the editor completely before I do any game development, as it’s by far and away the most work involved in this project.
The map in this game is rather big. 1024x1024 tiles, to be precise, which is a lot to fit in memory at any one time when you also consider that each tile may also have an item on it (like a munchable dot, or a jewel, or monster spawner). Not only that but some of the map squares have special actions associated with them: teleports have a destination; script tiles fire off a “script”; and switches fire off a sequence of changes to the map. Furthermore, in the editor, we want to be able to turn switches on and off and see which tiles have been affected on the screen with some sort of indicator.
Were I to implement that naively and have each coordinate on the map represented by, say, some TileInfo class which contained the floor tile, item tile, any special action, and a flag, I’d need to create an array of 1,048,576 of them, and each one would take up 8 bytes overhead and 16 bytes of object data. That’s 24 megs! Not to mention the 4mb just for the array pointing at them. I don’t really fancy using half of my entire heap just to store the ingame map - not to mention the fact it’d make serialization slow and probably very bulky - so I’ve already decided to optimise this data structure.
The map now consists of two short[] arrays which point at indexed Tile instances; that’s the floor and item layers. Now it only takes 4 megs for the entire tile storage. There’s another 4 megs that points at optional ExtendedInfo instances - so mostly null. An ExtendedInfo, when present, is where I can bung everything else when necessary, like tile actions, flags, etc. So that’s more or less got map storage down to just over 8 megs, much better. And serialization will be lightning fast.
The editor is proving extremely difficult to write because I’m doing it properly - one of the most important things I’ve implemented is a multiple undo feature. This is quite tricky to implement especially when drawing one tile can affect its four neighbours (the wall tiles automatically adjust to get the edges right). But it works! Hurrah.
Also implemented is setting Teleports and destinations - just to test that part was working ok.
Tomorrow comes the much more extremely difficult design and implementation of the switch editor. Why so difficult, you ask? Well, firstly, because I want to be able to undo switch edits. And secondly because I want to be able to flip switches in the editor - both on and off. In the game, they cannot be flipped off. However, they can be flipped in any order, and the bit which recalculates walls has to be able to cope. And Undo. Gah. It’s making my brain hurt just thinking about it.
Cas