tepples wrote:
It might be more difficult if your engine spawns entire formations of enemies, as I seem to remember Super Mario Bros. doing for double and triple Goombas. (
Citation: DahrkDaiz's level format doc) I would imagine that objects representing formations of coins, rings, golden arches, or whatever would have the same problem.
In my current game, each level can have up to 256 objects, and there is a bit for each one (for a total of 32 bytes). Should special objects need more than a bit (which is the case with formations), there are 128 bytes of RAM available to them, and the "parameter byte" in their definitions (my object definitions have 4 elements: X coord, Y coord, type and parameter, which is used differently for each type) is a pointer to which part of this memory it uses (they can use as many bytes as they want, as long as it all fits in). It's the best I could do without extra RAM.
The ideal thing would probably be keeping the object definitions themselves in RAM, so that you could modify whatever you wanted about the objects, even their positions (although this might require some sorting if the object-loading code expects a sorted list). This is only possible with extra RAM though, as object definitions can take up a lot of space.
I don't know if 256 objects is a good limit for levels as big as I want, I hope it'll be enough. This limitation is not RAM-related, as it would be easy to get, say, 32 more bytes for object bits, it's more related to ROM (I don't have much for definitions) and the code that loads objects (which is easier to code and runs faster if objects can be indexed by a single byte). Although now that I think of it, it should be easy to trigger an event in the middle of the level to switch to another table of object definitions, if I really needed more than 256.
BTW, why split from my post? You and Celius mentioned respawning before I did. Not that I'm complaining, I'm just curious.