Development Blog

Nice thoughts, didn't think Fuel had you so interested.

 

Talking about networking, you first have to consider that physics aren't usually used in network games. Also, according to the system, only the SBX part of the region that has been interacted with would have to be saved, and since these are mostly (only) objects, they could be given an identifier and run as objects on the server part, while the player, when loading a region, would fetch the data from the specified object identifiers from the server.

I think you need a way to allow us to have every region loaded at once. Something like a server mode. The servers for online games generally has everything loaded (which is why they need some heavy stats).

 

If you think about an MMO server, it has to have everything loaded because anybody could be anywhere at anytime. If the server has everything loaded then the client doesn't need to worry about anything. The server would send the updates to the client when they get a certain scene loaded.

 

So if your friend changes something on a scene you don't have loaded the server knows about it because it has it loaded, and the next time you load that scene it would update your machine with the current state of things.

 

In short I think the server needs to know everything all the time. It must have every zone loaded at once.

You don't need regions at all. You should make a game streaming all objects from a SQLite database, based on their distance. Terrain would not work how it works now, but you could just build the terrain from meshes which connect to eachother. Editor should also use SQLite databases instead of sbx files. They are just as easy to edit as text files with the free SQLite client: http://sqlitetool.googlepages.com

You don't need regions at all. You should make a game streaming all objects from a SQLite database, based on their distance

 

I think the thought is that looping through every single object in a huge world to find the distance of that object to the player could get expensive. With unlimited terrains you could have a million + objects and every cycle looping through them to see if they are within a range is way to expensive.

 

By breaking down into zones you help reduce the amount of looping to check distances to know what zone to load, which will in turn load all the objects in that zone. If you had 100 zones of the max size terrain full of stuff, it's cheaper to loop 100 times to figure out what zone to load (and the objects in that zone), than looping through the million some objects in the entire game world.

No, a SQL database handles queries to lookup only the records which are close enough by its XYZ coordinates (the SQL engine needs to support exclusive greater/smaller than queries which perform like indexes), so you don't need to loop through all records. You don't also need to check the entities in each frame, but only every 10th-30th frame. You can see that kind of behaviour in MMORPGs like AO, but also in Crysis where objects are first loaded and painted with an average texture color, and then textured later on.

That's an interesting way of doing it. I wonder if every model in the game is like this though. I was under the impression that static objects weren't listed in the DB. I'd be interested in seeing the query performance with this also, but it sounds like a decent idea.

I think you need a way to allow us to have every region loaded at once. Something like a server mode. The servers for online games generally has everything loaded (which is why they need some heavy stats).

 

If you think about an MMO server, it has to have everything loaded because anybody could be anywhere at anytime. If the server has everything loaded then the client doesn't need to worry about anything. The server would send the updates to the client when they get a certain scene loaded.

 

So if your friend changes something on a scene you don't have loaded the server knows about it because it has it loaded, and the next time you load that scene it would update your machine with the current state of things.

 

In short I think the server needs to know everything all the time. It must have every zone loaded at once.

That's probably accurate. It's probably impossible to make a networked system with the problems I described.

this is very interesting... i've had doing something this in the back of my mind for a lil while now (flight sim/game with expansive terrain)...

 

my approach would be different than those suggested above... and i'm just thinking out loud here, as i've done nothing of this sort in LW...

 

i think that i would base things on a large image which represented the terain elevation and the structures on the terrain...

 

this 'super' image would represent a compressed heightmap from which a small square section of the world of the terrain immediately surrounding where the view is located would derive it's contours...

 

i would use my old 3x3 treadmill logic to update the terrain as the view moved, getting data from the super heightmap...

 

this would require terrain sections that would allow the vertices to be deformed on the fly (to sculpt the square grids)...

 

the structures could (might) also be able to be read from this heightmap, or might require a different 'map' with greater fidelity for locations...

 

hey... just thinking aloud...

 

 

--Mike

I'm kind of digging Lumooja's idea about SQL db holding the information of object placement. This could actually be done right now by the community. A process could take an sbx file and parse it out to store the data in a SQLLite db. Then a new load process could read this db to make the scene.

How can mysql perform a fast query for an object within a range of an X/Z position? Y position can be ignored, since most games don't have much of a vertical component. I have tried for a long time to think of a way to sort objects in two dimensions, but it doesn't seem possible without putting them into some kind of grid structure.

Your grid structure would be a database table. Every object would need to be stored inside a table that has an X and Z column. These 2 columns would be indexed for fast searching.

 

You know the player position, so that would be used as one point. In your where clause you run the pathogram theorem to get the distance between your player X & Z and the columns X & Z and check it for < a certain range. This will return all objects that are within that range and need to be shown.

 

I would think this would be faster than looping through a million objects and seeing the distance on each one. Because of the indexing this should be faster, BUT I would think this would work best on static objects only.

Well I'm with, Josh. I don't see how using a database is going to be any faster than using a grid.

 

Or do databases run on a magic algorithms these days?

If it's the same speed I would rather use the DB because then you don't have to define grids and what objects belong to what grid. Just add objects and their position & rotation to the table and you're done. Much easier than having to grid stuff out.

Yeah, the whole grid thing could (should) be transparent to the user.

Lumooja is correct. You need to to throw out this whole notion of regions or cells or whatever you want to call them. It just doesn't work out the way you want, and you can go see Oblivion for another live example.

Everything needs to be streamed. Josh you might want to look into how RAGE is doing its texture streaming as a point of inspiration (See: Oct-trees).

How can mysql perform a fast query for an object within a range of an X/Z position? Y position can be ignored, since most games don't have much of a vertical component. I have tried for a long time to think of a way to sort objects in two dimensions, but it doesn't seem possible without putting them into some kind of grid structure.

 

One way may be to perform two queries

 

1. fast, simple query to eliminate impossible objects where

 

x_any_object - x_ref > range

 

and

 

z_any_object - z_ref > range

 

The results of this can be stored in a temporary, in memory table and then used to run the second query

 

2. Of the smaller set of objects that are left perform

 

((x_any_object - x_ref) * (x_any_object - x_ref) +

(z_any_object - z_ref) * (z_any_object - z_ref)) < range * range

 

 

A custom, hand optimized implementation of data structures and implementation will always be faster than something built on a general abstraction like a database layer.

 

The question is the amount of time available for data structure specific optimization versus the general features brought in by a DB layer like sqlite

 

---------------------

 

3. Of course if these are common functions, one would eventually expect custom hardware to support this function. Wait this is what graphics cards do. :-) Maybe a better chipset/GPU architecture might help these sort of computations!