Jump to content
  • Advertisement
Sign in to follow this  
ractoc

Flexible map making

This topic is 3559 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by ractoc
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....
Supposing we're taking the idea at the high-level only. Obviously this isn't going to happen in a nice way by itself!

It's just ok, where's the problem?

I'll give one: compatibility with unrecognized extensions. Having worked with one of those formats I can tell managing them is far from trivial as discarding them isn't always possible without impacting the experience.

Share this post


Link to post
Share on other sites
I have no idea what Krohm is talking about...

ractoc, so what is new here? What you're talking about is pretty common place with map construction.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by ractoc
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.
What I'm trying to say is that those "extensions" are unlikely to pay in the short run. Either nobody uses them or they become a pain. No, I don't think it's a good idea in the short run.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
You forget to mention that those extension doesn't work by themselves.

You either have to change some subsystem anyway (in which case this is not an extension but becomes an optional attribute) or provide a way to plug in code (which takes some efforts: DLLs are considered generally bad for this, the alternative, is a proprietary VM, have phun with it).

For example, I can put an "health" attribute in a light in Quake1-2-3-4, this doesn't make the light shootable for example (at least, it didn't on q1,q2 and q3, maybe it could on q4 when associated to a bmodel, I've never tried but I don't think it works).
The map format isn't changed and it keeps working exactly as before.

The point isn't in embedding arbitrary blobs but actually in the machinery needed to use them.

If you already plan to use them alone then most of the rationale in calling them "extensions" is going away. Are you really thinking about providing the necessary glue to support arbitrary blobs at "engine" level for your personal use? You could just make the changes you require and continue live happily!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!