• Advertisement
Sign in to follow this  

Game Engine - Scenes

This topic is 3460 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey all, I am currently making a terrain renderer and I am wondering how I should put all the components together. I keep reading about people using scenes but I have been unable to find any more details than this. So this is what I was planning on doing: I was planning on having a scene class that has a number of pointers, one to the terrain, and one to the list of enemies, one to the player and one to the other objects in the world such as buildings and vehicles. When the game has to update, it will call the scene to update and then the scene will look at each of these pointers and tell them to update. The same with drawing. So my question is: Is this how a game engine works or dose it use some other method? Thanks

Share this post


Link to post
Share on other sites
Advertisement
A renderer does not care about whether it's rendering a player, an enemy, or whatever. It usually contains data for a piece of static world geometry (in your case, this would be the terrain), for a large amount of small static geometry (for instance, rocks and trees) and a large amount of small dynamic geometry (your enemies and player).

The program (and not the scene manager) then matches in-game entities with their scene representation.

Share this post


Link to post
Share on other sites
Thanks for the reply ToohrVyk.
The reason I was thinking of having several list was basically for height calculations. If we want to get the height on the terrain for the placement of another object and it is mixed in a tree/vector/list structure with other object that do not return height values, you will need to find the type of object that you are looking at when iterating, and if it is the terrain object (Used loosely to describe the whole terrain), then get the height of the terrain at the point you are looking at.
If we put them into a separate list, then when adding other objects, you can call ‘terrain->getheight()’ and not have to worry about the type of the object or casting.

Share this post


Link to post
Share on other sites
Quote:
Original post by ManixReaper
Thanks for the reply ToohrVyk.
The reason I was thinking of having several list was basically for height calculations. If we want to get the height on the terrain for the placement of another object and it is mixed in a tree/vector/list structure with other object that do not return height values, you will need to find the type of object that you are looking at when iterating, and if it is the terrain object (Used loosely to describe the whole terrain), then get the height of the terrain at the point you are looking at.
If we put them into a separate list, then when adding other objects, you can call ‘terrain->getheight()’ and not have to worry about the type of the object or casting.


You're mixing 'renderer' with 'game logic'. The renderer doesn't care WHAT it's rendering - all it wants is some vertex/face and texture data. Your game logic should figure out terrain heights and object placement and whatnot.

A brief of how I go about it (and I'm not saying this is definitive, just my way): I have a class called CPlaceable, which contains position/rotation vectors and the matrix and such, and derived from it I have CGeometry, which contains mesh and material data, and derived from THAT I have things like CPlayer, CEnemy etc.

My octree class organises what is currently in view and builds a vector of pointers of CGeometry objects, i.e., if a CPlayer is in view, it is dynamic_cast<CGeometry>'d and placed into the vector. This vector gets sent to the renderer which draws it all.

Any game logic is performed in the CPlayer/CEnemy/CTerrain objects, complately separate from the renderer.

I'm not a great programmer to say the least, so I'm damn sure someone else has a prettier method.

Share this post


Link to post
Share on other sites
Hi

I am not an expert in Game Engine design but I am reading a book about XNA and the author uses the same style you are using.
There is a GameScene class which includes GameComponents (Player, Enemies,....) and when GameScene Update method is called, then the Update method of all GameComponents in this Scene are also called.
I am not sure if this is exactly what you mean but hope this helps.

Share this post


Link to post
Share on other sites
Awwwwwwww. That makes sense. Just have to figure out how to write it now :)

Thanks for your timely replies

Share this post


Link to post
Share on other sites
Hello,

right now I am venturing into the same territory as ManixReaper, so I will add to the discussion. [smile]

It is my understanding that a Scene Graph is a type of structure or format that manages animation, and updating of scenes.

Something that might work would be to have a class called "GameWorld." In game you have a vector list of of pointers to "GameObjects" which are pointers to your specific class such as terrain, sky, etc.

In each class you have a render function. The job of the GameWorld is to iterate through the vector list of GameObjects and render them each frame.

I know verily little on the subject of engine management when it comes to objects such as terrain, and sky, etc. and how to manage their interactions, so do not take my ideas and interpret them as _good_. [wink]

A scene graph would be for management for something such as trees, or people since there would many people/trees/whatever in a scene at one time. This list of objects would constantly be changing and need updating since the objects would quite often come in and out of view, and most likely require some form of animation.

Looking forward to more feedback from those with more experience on such subjects. [smile]

--Jonathan Janevski

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement