Final Scene Manager Design

Jan 21, 2008 at 2:31 PM
We need to finalize this design before we go much further with development. I know this has been brought up several times in the past and many great ideas were generated, but we need to come to a consensus.

Here's the basis of what we have so far:
  • SceneManager class with one or more children Scene classes. Are we still sold on this idea of having multiple Scene instances per SceneManager instance? This is not a simple "it'd be nice, so why not" decision. There are definite issues with physics and other systems with having multiple independent scenes. I would propose simplifying this down to one SceneManager, period. See my comments below.
  • Abstract SceneManager/Scene. SceneManager (and Scene if we keep it) should be abstract with virtual methods. Users should be free to code their own, and this also allows us to create several of our own to fit different needs (simple outdoor, vast outdoor, indoor, etc.)
  • SceneManager will talk directly to the physics layer without messaging.
  • We still need a final decision on camera management.
  • We still need to discuss interfacing with game logic.
  • We still need to discuss serialization.
  • We still need to discuss editor integration.


Elimination of Scene:

Like I mentioned in the bullet points above, I propose to get rid of Scene completely and just keep SceneManager. All of the existing functionality will be rolled up in SceneManager. So how do we handle vast streaming terrains? We can still maintain several Terrain instances in the SceneManager as root nodes. The main difference here is that there is still one logical scene, not multiple independent scenes. The terrain chunks can be dynamically loaded and unloaded, but all physics, AI, and scripting would be performed on just one scene. This will simplify things a lot, and I don't see any loss of functionality.


Please posts your comments here and then we can start reaching some design decisions.
Jan 21, 2008 at 5:49 PM
Editor integration should only be discussed after a final scene manager. Right now, I am parsing everything inside a xml scene and passing into a scene, just like on QuickStartSampleGame_Windows project. But we will talk about this later.
Jan 21, 2008 at 7:52 PM

shawmishrak wrote:
  • SceneManager class with one or more children Scene classes. Are we still sold on this idea of having multiple Scene instances per SceneManager instance? This is not a simple "it'd be nice, so why not" decision. There are definite issues with physics and other systems with having multiple independent scenes. I would propose simplifying this down to one SceneManager, period. See my comments below.


I have to agree, I do not see the scenarios which facilitates this. If we later get in situations where this is needed, we this we will have the knowledge at that time to implement it, anything we do now would most likely need rework. Also there in one design guideline which rules them all
  • Don't implement what you don't need!


shawmishrak wrote:
  • Abstract SceneManager/Scene. SceneManager (and Scene if we keep it) should be abstract with virtual methods. Users should be free to code their own, and this also allows us to create several of our own to fit different needs (simple outdoor, vast outdoor, indoor, etc.)


Yes, it must be extensible allowing developers to extend the tree. It would be good if these changes could be propergated to the editor as well. But this is not a hard requirement.


shawmishrak wrote:
  • SceneManager will talk directly to the physics layer without messaging.


I would say that the chat goes both ways the physics engine needs to update the scene elements and they need to update the physics data base on game rules.


shawmishrak wrote:
  • We still need a final decision on camera management.


Yup, I still think we need a centralized collection of cameras as the cameras needs to be updated before traversing the rendering tree


shawmishrak wrote:
  • We still need to discuss interfacing with game logic.


I think that scripting, though challaing, will be a benefit here.


shawmishrak wrote:
  • We still need to discuss serialization.


Everything should be serializable :)


shawmishrak wrote:
  • We still need to discuss editor integration.


Lets settle the scenemanager issues first and then have a look at the requirements, xnasorcerer can keep and eye on the development and prob object if we are heading in the wrong direction.
Coordinator
Jan 21, 2008 at 9:25 PM
Imagine this scenario:

We have 3 scenes, all running at once. We treat them as one however, physics, rendering, (maybe terrain). But the main feature of the scenes would be knowing what to load and unload as you move in and out of them.

Basically without scenes we'd need to devise an efficient way to buffer things in and out, and know which things needed to be buffered in and out. I think it'd be much easier to have the scenes as their own files, and you could simply load a scene when you were close enough. Same with unloading, you would know which things to unload.

The biggest difference if you'd be loading and unloading entire sections and groups of things based on a commonality (in this case, which scene they belong to), versus unloading based on something else, like distance.
Jan 21, 2008 at 9:50 PM
Each terrain chunk can have it's own file, that's perfectly fine. Game code can specify load distances and draw distances. So, if terrain chunk A gets to within X units of the player (or camera or whatever), then the SceneManager will spawn a background thread and begin loading terrain chunk A into memory. Once the player gets to within Y < X units of terrain chunk A, it'll start being rendered using whatever resources have currently been loaded so far and continue loading the resources until everything is loaded. The same method would apply for unloading. Once terrain chunk B gets farthur than Z units from the player, it's unloaded, and all entites within B's planar area are paged out to disc or unloaded to a lowest common memory footprint needed to serialize in case the game is saved.

I'm not saying we can't have separate scene description files, they should just all be handled by a central SceneManager that pages in and out the terrain chunks and entities in one unified scene instance.

For example, you could have a 4x4 grid of terrain chunks:

    +---+---+---+---+
    |   |   |   |   |
    +---+---+---+---+
    |   |   |   |   |
    +---+---+---+---+
    |   |   |   |   |
    +---+---+---+---+
    |   |   |   |   |
    +---+---+---+---+

Each chunk would be specified by a heightmap, texture data, and whatever else you need. They may even contain a "default" set of entities to populate when the chunk is loaded for the first time. To the SceneManager class, it sees an array of terrain chunks with sizes and world offsets. It will know the player position and view distance, and be able to stream in and out the terrain chunks as necessary. At the same time, one unified tree of entites will be maintained and a single physics world will exist. As part of the streaming, the SceneManager will create and destroy the appropriate physics actors for the terrain chunks.


Now this does bring up an interesting point with network interaction. I'm not sure how we can handle a client/server game over a vast terrain. To do server validation, you may need to keep all terrain chunks in memory. This would drive our memory requirements through the roof and essentially require dedicated server hardware for anyone wanting to host a game. In the example above, if you have 4 players, each at one of the corner chunks, you may potentially need to keep all 16 chunks in memory on the server. That's a scary thought, I need to think through that some more.
Coordinator
Jan 21, 2008 at 10:34 PM
I agree, a large terrain, with multiplayer, does mean a dedicated server or multiple servers. I don't see any other way.

If the game were singleplayer it wouldn't be an issue, but we cannot impose that limitation.
Jan 21, 2008 at 10:54 PM
So that means we need to make a decision here. We either go large and single-player or smaller and multi-player. You could always go both ways and only allow vast terrains in a single-player mode, and allow smaller terrains for multi-player mode.
Jan 22, 2008 at 5:42 AM
Wohaa, hold your horses here, while I do admire the scope of the feature, I do think that we initially have to implement at a much smaller scope. I mean, think about it, you are basically describing systems like WoW or Eve, which are so out of scope.

Initially we should just aim for a single map (might be repeated) and being able to handle about 100-200 entities. Because we made both the terrain and scene extensible we can later look at extending this, but honestly I really doupt that that will be before V1.
Jan 22, 2008 at 12:33 PM
Yeah, that's what I was thinking. Streaming terrains by themselves aren't all that difficult, you just run into potential memory issues. The big roadblock comes in when you start thinking multi-player. Everyone else seems to really want multi-player, so that leaves us with a small, managable area.