Game Development Community

One large world limitation?

by Shawn Hyde · in Torque Game Engine Advanced · 12/14/2006 (1:35 pm) · 23 replies

Is there a way to do one large world with TSE, no zoning just one large world? I see that atlas has a limitation on size so how would that work. I'm looking for a world solution that works like lineage2 without having to do an overhaul on the code.
Page «Previous 1 2
#1
12/14/2006 (2:54 pm)
Atlas has a limitation on size but that does not matter too much because you can place multiple atlas terrains.
#2
12/14/2006 (7:38 pm)
Can you do a dynamic transition so it doesn't require you to load all of it at once?
#3
12/14/2006 (8:56 pm)
If the quality of your game content is good people won't care about zoning.

The public is hungry for good games and they might cry but that would spread more sales
if it was that good they had to get to the content even faster.
#4
12/15/2006 (11:01 am)
You could use the legacy terrain since it repeats infinately.
#5
12/15/2006 (3:25 pm)
Multiple zones is out of the question. I need a one world solution and a repeating terrain will not work for this project.
#6
12/15/2006 (4:09 pm)
Atlas is too small for your project?

What are you doing? Creating a planet as large as this solar system at one meter resolution?
#7
12/15/2006 (6:14 pm)
What are the current limitations of atlas, has it changed? so much conflicting information I don't know what is correct.
#8
12/15/2006 (6:41 pm)
I've made one that's 256 kilometers x 256 kilometers, but that was a long time ago. The limitations are more based on your hard-drive, terrain creation tools and how you texture it. The new method of texturing is more like the TGE way and isn't limited by the typical PNG / JPG size (which was originally the most limiting factor).

For an example, assume you have a 1 meter resolution. 1km x 1km would take (as little) as 1000 x 1000 x 4 (32 bits) just for the terrain (ignoring the textures and other Atlas overhead).

256 km x 256 km is roughly 256GB! But, making it 8 meter resolution reduces it to roughly over 1GB... but that's not counting texture nor Atlas paging overhead.

My math could be a bit wrong, but you get the idea... Atlas can handle more than you could imagine, but the raw data required to store a huge terrain is beyond the scope of most games.

Personally I wish you could do some manual chunking in Atlas, where certain areas are extremely high detail (< 1 meter resolution) and other areas are very low detail, like mountains off in the distance that could be 32 - 256 meter resolution.

My point is this: Atlas / TGEA can handle more terrain than you can throw at it.... the question to ask is more like "How much can you throw at it?"
#9
12/15/2006 (7:44 pm)
Don't forget that there's more than just terrain involved.

A full world includes DIFs, shapes, lights, and other things. You'll probably need to implement some form of paging in/out objects so that you don't overbind the CPU with 1,658,000 objects to track (in simpler terms, zone your in world content not the world as a whole).

But if you page the content you open up a whole new can of worms.

You've got lighting to worry about. Sure static DIF lighting will work, but dynamically adding DIFs isn't going to include shadows baked into the terrain, which will require a relight, which causes a stall unless you make some changes to the lighting code to get it to work with single items over periods of time (or some other hack such as painting the shadows before hand or using a large DTS to cast a shadow [neither of which will cause the shadow to be cast onto shapes in the shadow]). I would imagine that there would still be a decent hit on performance so you would probably want to look into instancing for abundant things and use every dirty trick you can to get the most out of the batching that is already there.

So yes you could, but to get it to run nicely you'd have to make quite a few optimizations.
#10
12/15/2006 (8:00 pm)
It also really depends on your resolution. I've gotten 64x64km to build with an 8 meter block size, but good luck making that look good for a first person game. Unique terrain will look horrible unless you make it a 16x resolution, in which case it will crash the engine at that size. Blended terrain will likewise look pretty blocky. If your doing a flight simulation or something of that nature then you can get away with a larger terrain anda larger tile size.

I really don't think much larger than that is an option currently. It takes too long, and will in my tests, just about always fail generating anything larger. Then if it does go through it often crashes on loading.

You can have multiple atlas instances though, and seperate them by continents, which would let you have a much larger world.
#11
12/15/2006 (9:49 pm)
How does hero engine do it? It's a bit beyond my budget at over $1 mil + royalties and thats not even including source code but it's very impressive for an mmo solution and can do all of this. I have money to put in the project but I'm not willing to spend that much on someone elses engine & tools I would rather build an engine for this project if I end up spending that kind of money on the core set.

This needs to be travel by land & air with high detail, people need to feel like they are right in the world. If TSE will be adding these features as add-ons or in a future release of TSE then I can wait as I won't be ready to go with this project for another year and I was hoping to start with some code base like what TSE has already put together.
#12
12/16/2006 (8:35 am)
Sorry, you're asking for the nearly impossible...

Quote:
I'm looking for a world solution that works like lineage2 without having to do an overhaul on the code.

Ok, an overhaul isn't necessary, but some decent sized changes are.

Quote:
It's a bit beyond my budget at over $1 mil + royalties

And again, a bit of an exaggeration, but...

The limitation for a game like this isn't the terrain. TGEA with Atlas and some custom code for seamless zoning is what you need, but seamless zoning isn't easy with Torque. If you can't code it yourself then you're going to need the equivalent of at least $100k - $500k to pay some programmers to do it for you. If you have a great team full of artists and already have a complete storyline, artwork, demo video, etc and the zones are finished but you're just lacking the seamless zoning code then you could probably get a programmer to do it for you for royalties.

For seamless zoning I've got the basics done for TGEA MS3 and I've started an adaptation of it on TGE, but the compiler for it alone cost me nearly $2500 (I'm using Intel's compiler + Cluster OpenMP + Cluster Toolkit), but zoning isn't the only thing problem you're going to encounter in making an MMO with TGE / TGEA.

My suggestion is that you stick to the non-seamless zoning for now. If you're bent on making a seamless zoning system later, use one terrain for all of your zones. It can be done using Torque with minor modifications on the client side, but for your zone servers you might think about using TNL + a lot of custom code.
#13
12/16/2006 (9:37 am)
You might want to look into the many resources out there on saving and loading games with Torque.

I believe Pat Wilson posted a really good one which required you to sepecify manually what needed to be loaded or saved. With some modifications you could probably whip up a zone object and link it to a file for saving and loading its information then distribute the save/load process over time instead of all at once (or make your zones fairly small and negate less important things such as cadavres). Throw in some NPC behavior/movement prediction and it won't seem so static.

Then you'd just have to whip up some zone management for calling certain zones to do their stuff. Again multiplayer makes it more complicated. I've written everything assuming that it was singleplayer. Single server multiplayer shouldn't be too difficult to adapt to, but if its MMO stuff that you're planning on then you've probably got more work ahead of you.
#14
12/16/2006 (2:22 pm)
@Tony

Much of the story concept, game mechanics and basic idea are in a refined stage and will I will be hiring programmers to do the rest including the things that I'm asking about when I put the project into full swing late next year but for the moment I'm doing research to see overall what the most cost effective solution will be for the project as far as a game platform. I would be interested in seeing an example of some seamless zoning you have done with TSE even if it's based of MS3 and in a generic form it would still help me to envision a final solution with TSE.
#15
12/17/2006 (11:51 am)
@ Tony

I believe, talking about creating a planet the size of the solar system at one meter resolution at this time is a little premature. In fact, creating a terrain larger than 32 kilometers x 32 kilometers at one meter resolution is beyond the limits of the Atlas file system. In my experience, any file positioning greater than 31 bits (or about 2.1 GB) will cause the engine to lock up. The file system currently uses 32 bit values, if the file system was reworked to make it 64 bits, then the atlas terrain will be truly limited only by disk size for a single terrain.
#16
12/18/2006 (8:35 am)
@Shawn - I wish I had more time right now to put something together. After my current project (end of Jan) I'll try to put together a short little demo that shows transparent server handoffs.

@Mary - I misspoke... you're correct in that you cannot have one Atlas terrain that size, but since Atlas allows multiple terrains then you're basically unlimited to the size if your HD.
#17
12/18/2006 (2:40 pm)
Besides how do you go to the bathroom and get snacks if you don't have zone loading?

Like people standing in the respawn tubes in Planetside or outside the bank in Plane of Knowledge while eating dinner.


Vote Yes for Zone Loading. It's good for you and your bladder.
#18
12/18/2006 (5:11 pm)
While it's a little OT and hopefully won't hijack the thread... Gonna hafta agree w/ Randy...

For our project we took a long hard look at seemless zoning. The ability to make a "round" world, with the ability to not use the teleportation system and fly from one continent to the other in real time was very attractive.

In the final analysis, we just had to ask "What does this gain us for all the effort/hardware/problems?"

When we stepped back and looked at our game without seemless zoning... it really didn't lose much, and the alterations required to account for forced teleporting were significantly less than adding in the seemless zoning itself.

As Tony mentioned, it's quite an undertaking not for the faint of heart... but it is possible if you are truly dedicated to the task.

Which is like most things in Torque. :)
#19
12/18/2006 (7:03 pm)
@Randy
The project will have an auto-pilot mode where you can go to work and make money or just go get food and use the privy.

@Bryce
If the Engine supports it and other then editing the net code to only send packets within a radius to each user it shouln't be that much work.
#20
12/18/2006 (8:34 pm)
Zoning is convenient for a lot of things as a programmer... and in most cases it's the easier way to do things and allows you to do some things you can't do with seamless worlds, instances are a lot easier for example. Having more varied areas is a lot easier without heavy texture hits. Switching from an indoor to outdoor renderer, is much easier.

In some cases though seamless worlds have a huge advantage, especially when your talking about Player vs. Player combat. Zoning is one of the largest problems that PVP games have. It's possible to do seamless zoning in Torque if your game needs it. It's not simple though, you'd still want to have multiple zones set up, but you'd have to set up a buffer region for each zone where the two servers communicate with one another, and try to minimize traffic on the seams. Each instance would also of course have to run the same large world, and you'd be switching between them on the time.

Possible? Definitely. Easy? Nope.
Page «Previous 1 2