Sunday, 19 March 2017

Object storage re-design

In the current engine game objects are stored in "raw" lists on Level class, a list per each object type. 2D maps have pointers to these objects. There are other ways to do it, like concentrating everything on a tile which means the tile owns all objects on it. The reason why I have a list for each object type is that when I was designing the system I had difficulties to understand how a base class list would work, but of course it's pretty trivial.

I'm planning to re-design the system with a container class that "hides" the base class list of objects and then has everything needed to work with the list. Then I could create an array of those classes each with a type of game object. I could even try tile-based approach or possibly a mix of both with stationary objects owned by tiles.

I know this is one of the things that people may get right the first time, but I wasn't that lucky. Even so, the re-design is not very big actually, because all it has to do is add and remove objects in the list, with couple of other routines. These days I'm quite careful not to reprogram things just because, but this one seems to be quite important to get rid of the object id confusion I'm having at the moment. If there is anything I have learned about programming it's to break large pieces of code to smaller pieces that then can be managed.


  1. Why not simply have an array the same size as your map that has a pointer to the first object in that tile? Each object would have at least a Next-> pointer for more objects that could be in the same tile.

    I would think this would trivialize object management and display?

    1. It's not that easy. Objects don't have pointers to other objects, it's old school (unsafe) C way to handle object lists. A tile object could have lists for every object type, but it makes the map quite heavy in memory management, because STL containers are heavy. Also, you would still need some kind of list when you check out monsters for example. I don't know, maybe I'm making this more complex than it has to be.