Question about big worlds

[grubert]

Gekido,

How GameCore will behave if I make a game that has only one big world. Like, supposing my game units are in meters, and I have characters with real world proportions (1.60m to 1.90m tall, more or less), and my world is a square with 500 x 500km ... Will the objects matrices and the physics objects behave nicely?
What would be the other solution if this one lead to physics bugs and inaccuracies caused by decimal numbers etc?
If my level is mainly made of sea, a sea plane... Should I load each island (or chunk of neighbour islands) as a separate world, dynamically? How should I do this?
But if I have a vast terrain of, let?s say, 300 km side. How?s the best way to handle this?
If things get to 1/10th of this (a level with 50 x 50km), will it make any difference, as to avoiding strange behaviours?

A lot of questions. But these are the first of a series I?ll do that focus on a very serious project I have in mind.
It?ll make more sense later.


Thanks in advance.

[Squat]

So far I've noticed that the larger the physics primitives get, the better they behave and that going too small with any collision objects leads to glitches.

I have the same question about the world size and dynamicly loading content. My entire game takes place in one house, including the yard. The whole world is scaled up huge and built that way from scratch. Things aren't being scaled in-game. Each room of the house is going to represent an entire level and I want to know if it's best for me to load the entire world and occlude by each room or if I should load a new world when going through a doorway...or if there's a way to dynamically do that so it's smooth both online and off.

Older games like Everquest and WoW use zones where you get to the end and there's usually a canyon or doorway or something you pass through and it goes to the loading screen. I wonder if there's a way to retain an interim portal area where elements are live from both worlds that gets loaded dynamically. Basically you drop out all but what's in that passage area and start loading the next world. Is it possible to be loading a new world while the game is still running and active?

[hikmayan]

Well,I have first hand experienced the end results of a really large scene with the Engine(including BV);I was quickly reminded the limitations plus issues in terms of general performance and what not. I am looking forwarde to the official release of GC to try the similar  scene I used years ago.I am atm working on other Level Designs to test the Engine as far as large scenes and performance in general.

[gekido]

if you have a world that is a bunch of seperate 'zones' like the island structure you mentioned, the best way to do it would be to dynamically load each island as a seperate world, either done on the fly or simply as seperate 'levels' that are loaded when the player reaches the zone boundary.

Each room of the house is going to represent an entire level and I want to know if it's best for me to load the entire world and occlude by each room or if I should load a new world when going through a doorway...or if there's a way to dynamically do that so it's smooth both online and off.

You could do it either way.  I'm not sure what you mean by 'online and off' - if you mean tracking where a user is in an online game, then you would need to have some kind of tracking system done on the server that manages where a user is located and so on, but it could be done either way.

I wonder if there's a way to retain an interim portal area where elements are live from both worlds that gets loaded dynamically. Basically you drop out all but what's in that passage area and start loading the next world.

Simply design your connecting worlds so that they have the geometry / objects for both ends of the connection in both worlds. Half-life 1 did this however many years ago - you would simply design your worlds the same way to do this kind of 'portal' system.

Is it possible to be loading a new world while the game is still running and active?

You CAN import worlds dynamically into other worlds using the StartImportWorld() function - which behaves the same as StartLoadingWorld() except doesn't clear / empty the currently loaded world prior.

The engine doesn't do automatic 'streaming of content' for you (yet) but you can potentially break the world into zones and dynamically load / unload content for each zone on the fly as required.

Now, getting into the 'massive-scale worlds' concept (and 300km on a side is extremely large and not what the engine is designed to handle), there are definitely situations where you will run into issues with extremely large numbers - due to the floating point nature of the engine, there are rounding errors and other fun that would need to be taken into consideration.

Note that the current terrain system simply is not designed for that size of terrains.  You would need / want to break your terrain up into multiple pieces to do this.  We're looking into alternate ways to manage large-scale terrains, but the current system we're using for terrains just doesn't scale that well (for massive terrains like that).

[grubert]

Gekido, which are more reasonable numbers, in regard to GameCore current design? Maybe 30km? 15km maximum? 5km?
I need to know this to define better the "geography" of a prototype I?m going to do. Islands (enough to have a village inside it), main space being sea.

[gekido]

that's pretty much an impossible question to answer without a LOT more information about what you are trying to do.

What kind of detail are you planning on having in a single scene? 
How dense are you planning on having your terrain mesh (this is a bigger concern)? 
How big of a farclip are you planning on having?

What I would do for that kind of thing (water / islands) is simply use smaller terrain pieces and use a bunch of them at varying levels of density / detail.

Each island is it's own terrain, the water in between would be it's own etc.  You could use larger terrains with much less detail for the water pieces in between and things should be ok.  For example a huge terrain with only 4x4 poly density will be handled much better than the same size terrain with a 128x128 density.  The larger the terrain, the less detail the terrain will have as well, simply because the mesh gets 'stretched' - so breaking it up into smaller terrain pieces is in your best interest (each being only as detailed as it needs to be).

Rendering accuracy is 100% dependent on how big your farclip is - a 10k view distance gives you much less accuracy in the zbuffer than a 100m view distance - by a huge factor.  Somewhere in between is probably a good medium.

The ideal way to implement something like this would be to use dynamic loading / unloading of content - this way only the content that is actually needed / used at that time is loaded into the world - which will help alot to keep the size of the physics simulation manageable as well as the internal managing of the world and all of it's objects.  I'll be writing up a few examples of how to do this kind of dynamic content management in the near future.

[grubert]

Thanks for the info.
I have a Game Treatment here and I'm writing a Game Outline, more detailed, and some technical docs. But I don't want to give too much detailed information here, becaused it will be a comercial game.
But first, I'm going to do a prototype with only 3 islands or 2 islands. 1 bigger, with a village, and too desert islands, smaller ones. The main purpose of the prototype is to gather a publisher.

For this prototype I intend to have:
- an intro cinematics. Simple, main thing being narration, camera movement and soundtrack.
- 2 types of vehicles (with simple movement and simple physics, much simpler than a car)
- 3 to 6 types/classes of characters
- NPCs with a limited AI (walk on paths, wandering, stop and talk with player if player press "interact", enemies that attack the player,
soldiers that reach the player and start dialog/interrogate). I'd like the NPCs to look at player if he?s close and have some blendshapes/morph targets for angry, smile and lip synch (at least these).
- some NPC animals, like sharks, seagulls, dogs etc.
- a simple dialog system (maybe with voices played along with text, but probably not)
- a simple inventory system and pickup items in some places.
- some break-able objects
- some collision callbacks for different audio: depending on terrain for steps, for weapons shocking with metal or stone etc
- a character parts customization screen, simple I hope
- 3 types of weapon (2 of long range, 1 for melee)
- one simple quest (mainly centered in the dialogs), some combats and some "flag" variables in script that unlock the next events/places.
- a good amount of vegetation (with weaving animation, I hope)
- characters with specular, normal and diffuse textures.
- A somewhat complex melee combat system. This will be the hard part, I think. But I'll start it simple but fully functional, then I'll improve it to make it more complete if the time allows.
- If the final FPS rate permit, specular and normal textures in most buildings (loaded at close distance only) and props geometry, and in the trees trunks.
- bloom, maybe HDR, horizon haze/fog
- Maybe I'm wrong, but I believe a far clip of 1 km or 2km will suffice.
- A huge use of LOD (with smooth fading, as GameCore allows now), imposters, and LOD in the characters also.
- I'll use instancing every time it is possible. For NPC characters, props etc.
- If possible for me and the team (considering time restraints) multiplayer. The idea for the final game is to allow more than 100 people to play (MMO allowing more than 1.000 being awesome, if it doesn't force us to degrade the graphics too much), but for the prototype, any maximum size will suffice, up to 32 players. Don't think we'll actually have an occasion with 32 people or more testing the prototype. Only if we put it online as a demo. But I don?t plan to. The demo will be the demo of the final game, with its final specs.

I calculate to take more or less six month to put the prototype together. Me and a team, that up until now has: two 3d artists, 1 animator (me) and probably one more, one producer and one real programmer (graduated in computer science college etc).

The idea now is that the bigger islands have an average of 5km length in its longest side (I've scaled it all to 1/10th the original idea after your answers).
But later, for the complete game, I'll have country land also. I was planning to make them 1/10th also, but even this were going to be big: most part coastal lands where you go some 5km to the country lands, but a peninsulae was needed to have 20km in its longest side. Do you think this size could be reasonable?

Procedural vegetation would be good, but I fear the terrain object of GameCore's terrain system won?t be as flexible as I want it to. To make hills, carved stones, stone archs, caves etc.


My idea was that you would navigate from island to island actually in the ship, without changing to a map screen for "teleporting" to other area. So that the player feels like navigating large distances in open sea before reaching an island. And that the islands and coastal lands were "open worlds", even if the player walked for some kilometers without finding any landmarks other than rocks, vegetation and rivers.
But if this can't be possible/feasible, I change this feature of the game and make it with "areas", with much narrower limits where the player can go, and when it get too far from an island (or bunch of neighbour islands), the level unloads and the player gets a map screen. Then when he choose another island, he loads in its vecinity, but at a distance.

I already have a lot of questions to do that all relate to this prototype (I?m gonna focus completely on it from now on - no more tests), but I'll first finish the first complete version of the game outline so that later I can ask all of them together and hopefully they'll make more sense.
How could be the better means to send the game treatment, the technical specs I want for it and the questions? A support request?

Thanks in advance.

[grubert]

Bump.

[Squat]

For melee combat, would a collision box attached to a sword-bone actually be able to track its own velocity based on the animation and scale the impact damage to an outside collision object? If that's the case, melee could work properly. How reliable is setting a collision object to "independent"?.

[DPF]

I'm building a 70 km2 map using 1m satellite imagery. I've used up to 4096 sized tiles, but I think that 2048 should be safe for this map and be compatible with most GPUs.

It would be nice to be able to set up an image tile sequence for GC terrain. For example, say you have 25 image tiles in sequence order, then in GC terrain editor, choose the number of tiles across and the number down, 5 x 5 in this case, and the size of the image tiles.

Then enter the file name of the image sequence, and terrain editor loads them in sequence, image0001.dds -> image0025.dds, left to right, and Z+ to Z-

Somethng like this could turn into a GIS tool.

I'm making my own terrain object, but the benefits of using the GC terrain texture features are obvious.

[gekido]

Grubert, everything that you've mentioned seems very doable (at least from the technical standpoint) in the engine.  The number of people that you can support in the multiplayer will depend on what kind of gameplay you are looking for and how often you want to do the network timestep (ie how often you want to update the network state per second).

The current network implementation that GameCore provides uses pure TCP networking, which is fine for LAN games, but we're in the progress of rewriting the entire network stack to support proper UDP (with NAT traversal etc) which will allow more 'twitch-action' type networking like most FPS games require.

One of our internal projects currently is a 100% online networked game (which we'll hopefully be able to announce more news about shortly), which should hopefully demonstrate some of what you can do with the engine in a networked environment.

[grubert]

Thanks for the reply.
I?ve already made the first pass on the game outline, including techincal specs and some concept art studies.
I hope to begin working more time on it in february.

Cheers.

[zknack]

Grubert-

I think I've figured out how to get an incredibly large world- earth sized even, into the engine.

Things that would make this much easier than my more cobbled method currently being tested
are as follows:

#1*The world streaming errors need fixing.
#2*I'm not sure that there's a way to use imposters and/or LOD objects in the world editor that will then show up properly in-game.


#2 is importantish, as without #1 working fully, I'm doing it all in one window.

Basic run-down of the method:
*Using (1) infinite water plane.
*Imported GIS data into a 3rd party terrain tool.
*Created a (albeit flat) world
*Broke down GIS data to 512 tiles of terrain.
*Generated LOD from 2 poly's (flat plane) on up.
*Textured in terrain tool, exported textured tiles.
*Imported in GameCore, as 1 detailed terrain, and 511 very low (2 poly) polygon ones. Far from perfect- but 'working'.

Downside, I'm limited (i THINK) to mostly non-engine tools this way.. I'm planning if I can get #2 at least, that I can create
bones/nodes on the terrain to load the town blocks on...

I have roughly well above 1000 or so objects I think on screen right now, and hence my far from perfect state... I think If I
had # 2 working I could get it fairly smooth, and if I had #1 *****and***** number 2 working, I'd be in heaven.

Upside of #2 vs #1 is alignment issues- for something like a nautical game, with #2 I can sail world-wide.

At the moment it looks horrible- due to the only loading 1 'detailed' terrain, but if those are do-able somehow, then maybe
No retarded arbitrary limitations of modern games- more of the 'worlds your oyster' of old school Uncharted Waters New
Horizons style.

I'll see what I can do about getting shots up, but if Gekido or Co can answer status of development for issue #1 and 2, that'd
be awesome.

[DPF]

Saw a great demo in person for a GIS app that uses ECW compressed geo imagery files for terrain textures.

The example I saw was for the entire island of Oahu, in Hawaii.

A single 1GB ecw image file is used to texture the entire island with sub meter color imagery.

As you do a fly-thru, the image resolution compresses and decompresses on the fly real-time at 60Hhz.

This means is that you can work with very large compressed files instead of hundreds of tiles to get great flight sim views, and nice detail when close to the on the ground.

The decompression wasn't noticeable at all, very smooth. It's expensive though atm.