This is the first of my articles comparing how I'm doing a thing in Martin's Hell Bash compared to how I did it in Martin's Dungeon Bash; it looks at the differences between struct obj (MPRDB's representation of an object in the game world) and class Obj (MPRHB's representation).
There are points in common between the two. For example, MPRDB never stores an actual pointer to one anywhere, and MPRHB only stores pointers to them in a single location (the master std::map used to convert from objtag (a 64-bit unique ID) to Obj *.
For the most part, functions that took a struct obj * in MPRDB are now member functions of Obj. This does produce a lot of member functions, but I can live with that.
MPRDB had a fixed pool of 100 object slots on the dungeon floor and 19 in the player's inventory. All allocation was in terms of one of these two types of slot.
MPRHB aims for more ambitious scope, including dungeon persistence, and one of the features I decided I absolutely had to have (to stop the deserialisation code from driving me completely mental) was unique IDs for each object that gets instantiated.
Obj are dynamically allocated from the heap, and once they've been populated and tagged, a pointer to the newly allocated Obj is stored in a std::map<objtag, Obj *> which is then used for converting the 64-bit IDs into pointers when someone wants to perform an operation on an Obj.
The unique ID is quite simply a 64-bit integer which counts upward with every Obj that gets created.
When stored in the dungeon level, an objtag goes into a std::map<libmrl::Coord, objtag> in the dungeon level structure; this is accessed via member functions of Dunlev. This is a bit slower than the 2D array lookup that MPRDB used, but the scope for expansion it gives me is worth it.
Martin's Hell Bash homepage.
This page is copyright © 2008 Martin Read.