I'm currently working on a new concept for creating game maps (3D). I have the world map divided in sectors. The reason for this is to be able to load a sector quickly and smoothly without hogging the memory with the entire world map, while you are only interested in a small part of it. Each sector would be populated with map objects. These range from simple structures to complex stuff such as a complete sub-sector (think dungeon / instance etc.) These Map objects have themselves a list of attributes which they need to function, for a tree this would be nothing more then the model and the texture needed to draw it on the map, but for a planet this could be the model, the texture and the rotation speed for instance. Besides a list of attributes a map object also has a list of properties. A property itself also contains a list of attributes. Properties are behaviours you can assign to the object, for instance if your map object is a house, a possible property could be enter, which would enable you to enter the house. Since Enter will be a property which you can assign to any object you want, you get a very flexible map system, you could for instance give the Tree object the enter attribute and suddenly it is possible to enter the tree.... The combinations you can think up are endless. I'm planning on using this system for a game I'm currently designing (nowhere near well enough designed to show here though). But I would like to know what you think of a map setup like this. As you can see it;s a very flexible system, it could even incorporate a pluggable architecture where you can build your own extensions.

Yeah, you described a basic map structure. Most games employ general action types, then cause those action types to mean similar things for each object type. There's also the open/close, push/pull, turn on/off system, where actions can often lead to nothing but the player character complaining about confusion.

As far as partitioning, the biggest headache for me is transitioning. Getting from one segment of the world that's floating in empty space to another. Also, figuring out how to (or whether to) update objects that are in current, adjacent, nearby, and distant segments.

For example, one idea I've considered was implementing a simple simulation for each object type when it goes into an invisible/background sector. Basically, it dumps all of the complexity and updates via a completely different system. Picture a complex 3D character walking around the corner, then turning into an Atari blip. Both can achieve similar cause/effect, but the simplified version is much easier on the CPU. This will allow me to have actual background combat, where your allies are engaging battle in a building across the city from you. But the whole system will also be a pain in the ass to implement. Every character action or feature will need to consider a dumbed down version.

Why do you need a dumped down version when it's not visible any more?
The part hardest on the CPU, the actual 3D model is no longer visible, so it costs only memory and no CPU. The rest is just an object containing numbers. How is that heavier then your dumbed down version?

As for the basic map structure. I know this, what I was thinking of was taking it a step further and making the object types and properties etc. more abstract. The map makers I used up until now usually have an object library with predefined objects. with each object being relatively static in which properties is has or which properties you can assign. My goal is to have a map maker with a list of objects and a list of properties, which you can combine any way you choose while making the actual map. Instead of when making the object library.

Besides, I'm also working on designing a separate library (which will use this one) which will create random maps with this system. But that's still in the early design stages. First I need a basic map system to work with.

Quote:Original post by ractoc
Why do you need a dumped down version when it's not visible any more?

To have a real-time simulation of large scale coordinated battles without bogging down the smoothness of gameplay.

Quote:The part hardest on the CPU, the actual 3D model is no longer visible, so it costs only memory and no CPU. The rest is just an object containing numbers. How is that heavier then your dumbed down version?

The hardest thing on the CPU in my game is AI and character animation. The rendering is done by the GPU. The character animation doesn't just animate bones, though. It interacts with objects, launches attacks, reloads, opens doors, aims ranged weapons, causes recoil offsets, changes the speed of skill based actions, etc, etc. All of those things need decent relative simulation.

Not for use by others no, but this way, I can use the same extension mechanism myself. Just have a core engine and then plugin the parts that I need. Instead of having to go back the the actual code and alter it, I would just be adding more extensions, leaving the actual map system code intact.

and that's where listeners come into view. Each plugin registers a listener with the object. So in your example, the health property would register a listener to let the light know it wants to know if the light is being shot at. Then, when you shoot at the light, it checks if there are any extensions have registered the shoot listener and it notifies those extensions. These can then handle the shoot event any way they see fit.

The actual event properties are irrelevant at this point, but I would suspect you would need some way to notify the original object if it is destroyed. That's the easy part though.

This you can do for all the various events the object can handle. Seeing how the object itself would use these same listeners to listen for events from the control layer.