Jump to content
  • Advertisement
Sign in to follow this  
Maze Master

engine for big big map

This topic is 3213 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 interested in combining around 100+ half-life 1 maps into a truly gigantic map with corridors connecting the various parts. Keep the average polycount, textures, render quality, etc at 1998 levels, but just bump up size of the world, the associated planes maximum, leafs, texturedata, etc. Given increases in hardware and the complexity of levels in modern games, this seems like it should be technically possible, but outside the realm of what people have tried to do. Are there any engines currently out there that could handle such a monstrosity with only minor modification, or if not, any suggestions? Would I have to abandon quake-style BSP entirely?

Share this post


Link to post
Share on other sites
Advertisement
Have you looked at the Quake engines? While I haven't verified it myself, I've heard they're all available under the GPL license these days. I'm not sure how much modification you would need, but perhaps as little as changing a few numbers in some header file.. This is pure speculation though, I have no experience with those engines whatsoever.

With that said, why do you want to do this? In a multiplayer game, chances are players would run around for hours without ever seeing eachother..?

Share this post


Link to post
Share on other sites
I don't think any modern engines would have a problem with this however two conditions would need to be satisfied. One would be that the map is well designed is such a fashion that you're not trying to render the whole world at once, an octree would take care of this. The other would be that a level of that size would have trouble fitting in the RAM of most computers.

Share this post


Link to post
Share on other sites
+1 for Boredom_Inc's answer.

Rendering should be fine. Quake and other engines use sets of possibly visible nodes to keep rendering times down. You can add a whole bunch of maps and it won't matter, since for a given player only a small set of the map is visible at any one time. By adding 100s of maps you're just adding more stuff that won't get drawn.

Fitting everything into RAM could be a big problem. Within a map, level designers tend to re-use textures etc. That gives the level a consistent feel and reduces the texture overhead. With lots of maps you may have a large number of additional assets (textures, sounds, etc.) to keep in memory.

Also, depending on what you're doing, client-to-server communication may become a chokepoint. Most engines should also handle this gracefully: just as a client won't render what the player can't see, the client and server shouldn't spend too much bandwidth coordinating objects that aren't visible.

Another possible chokepoint: both the client and server may have to run physics and AI calculations over the whole large map. With 100x moving objects, the physics/AI engines may require that much more time.

Share this post


Link to post
Share on other sites
Rendering it like a Quake-derived engine (assuming you can fit it in RAM etc) wouldn't be the problem because you're only rendering a small subset of the world at any one time. Your level editor is more likely going to choke on it, because it'll probably show more of the level at once.

A more subtle but serious limitation you'd run into is what the size of the world does to floating point accuracy. As you get further from the origin, floating point coordinates get more and more "quantized" which results in strange artifacts. To keep this under control, the Quake engine limited world coordinates to +/- 4096 units, ie. a cube about 200 meters across. Source allows world sizes up to 800m (+/- 16384 units) which is probably very close to the threshold where the errors become visible. This is sizable for a first-person shooter but not huge in absolute terms, and won't be enough to hold a level as large as you're describing.

One solution to this world size issue is using local coordinate systems within sections of the level. There's a very nice paper on the Dungeon Siege engine that describes how they created a continuous, detailed world of immense size like you're planning to do. I could only find a link to a powerpoint presentation of it in a hurry, but a bit of googling should find the more detailed article. It also touches on other helpful subjects like streaming (only keeping the part of the world in memory that the player can see/interact with).

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!