Jump to content
  • entries
    943
  • comments
    5,899
  • views
    923,700

Future Ideas


Josh

4,121 views

 Share

Here are some of my thoughts on how a future engine might look. I am not devoting any time to this, and it would not come to exist for several years, but it's fun to think about technology and design:

 

I've been fascinated with the game "Fuel". This game has an enormous playable area that is streamed from the hard drive. You can drive for hours and barely cover a fraction of the map. For some reason the game has been given bad reviews. I played Motorstorm on the PS3, and I think Fuel is a lot better than that game, not even considering the impressive technical features. Anyways, I love the large open world. Fully dynamic lighting was one holy grail of game development, and I think a continuous open world is another.

 

I would start this with a concept of "regions". Each region is a square on the grid, perhaps 1024x1024 units. The region has a terrain heightmap, terrain normal map, and an SBX file for all entities in the region. As you move around the world, regions are loaded from the hard drive in a square of playable area around you. Maybe there are 16 regions active at any given time. This number should be adjustable. Only physics and scripts of the entities within this active region are updated. When a region goes out of the playable area, it is saved to a file, and this new file is loaded if that region re-enters the playable area. So you aren't going to have enemies fighting and moving around when they are a million miles away. The engine just updates the regions nearby, because it would be simply impossible to update millions of entities. The AI in STALKER actually uses a technique similar to this, and I think they originally were planning on a huge continuous world but weren't able to pull it off. Each region can be culled on a separate thread, so this design lends itself to multithreading.

 

So far what I have described is a big challenge, but it seems feasible. The real nightmare begins when we talk about networking. If your friend walks ten miles away and interacts with a person who's attitude towards you changes based on the interaction, well the server needs to be running two simulations. One simulation is for you and everything around you. The other simulation is for your friend and everything around them. What your friend does will change the world outside your playable area, so that when you enter that region it will be different than when you left. Now consider physics. Due to the massive distances, there would need to be two separate physics simulations running. Then they would need to be merged together when you approached each other. :) Wow, no wonder no one has done this yet! Fuel has a multiplayer mode, but it's just a racing game. Your actions don't have any permanent consequences on the world around you. An FPS, adventure, or RPG game will be quite different. I'm not even sure this is technically possible, without severe restrictions in flexibility.

 

Fortunately, real-time rendering is not going to change much in the next ten years. We'll be able to do more as hardware advances, but I think we'll still be using the same basic techniques for a long time. That means that every feature and technique we add now will still be useful for a long time, even in a new engine.

 Share

16 Comments


Recommended Comments

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.

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment
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.

Link to comment
Guest Red Ocktober

Posted

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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?

Link to comment

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.

Link to comment

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).

Link to comment

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!

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...