Best way to handle gameobjects and sceneobjects?

[odenter]

First of all my english in writing isn't perfect.
I'm a professional developer but no professional game developer. Developing games is more like a hobby.

So now my question.
What's the best way to handle gameobjects and their corresponding sceneobjects? Sounds a bit general? I'll give an example.

I'm developing a small 4x space game. Basically a 3D realtime version of Master of Orion or StarDrive for example.
I've got a Galaxy object which holds a list of stars, each star holds a list of planets and each planet holds a list of moons. After trying some things I saw (for example) that I've hold every position twice (in my custom object and in the sceneobject).
And then I began to thought that I need to link my gameobjects to my scenenodes, to save some memory. No one needs a irr::core::vector3df twice.
The result was such a map std::map<irr::scene::ISceneNode*, IGameObject*>.

But then I asked me: "Do I need my custom object graph?". Because I've the same structure in my scenegraph?!

Which is a better solution?
1) Create a gameobject and a custom gameobject graph where each gameobject is linked in some way to a scenenode?
OR
2) Create one custom scenenode for every gameobject?

That's why I ask here. How do you solve this issue?
Any advice?

[CuteAlien]

You have gameobjects, think about those classes first. Some (maybe most) of them have a SceneNode. So probably a pointer to it inside the gameobject class. Sometimes you need the other way around as well (you click a scenenode and want to find the corresponding gameobject) - using a map for that is a good solution (thought using an array with a std::pair often is faster as std::map is rather slow).

[polylux]

(thought using an array with a std::pair often is faster as std::map is rather slow).

Sorry to pop in OT here, how should traversing an (unsorted) array be faster than a lookup in a sorted structure?
Aside from that I too would recommend to keep pointers to the related scene nodes of your game entities. I have found for myself that it's best to keep game logic and visualization as separated as possible.

[AReichl]

This is interesting, because i have the same "problem" for some time now (without achiving anything).
I am not talking about map or vector, but about "Gameobjects". If you begin with these, you end with
thinking about Entyties, Components and all that stuff, specially when integrating other libraries like
sound, physics and AI (artificial intelligence). Specially the "sequence" of operations gives me headaches.
Does the AI tell the physics engine to steer the spacecraft OR does it first inform the Gameobject (Entity?)
and then the physics engine and how is that new position given to the graphics engine?

[polylux]

This is interesting, because i have the same "problem" for some time now (without achiving anything).
I am not talking about map or vector, but about "Gameobjects". If you begin with these, you end with
thinking about Entyties, Components and all that stuff, specially when integrating other libraries like
sound, physics and AI (artificial intelligence). Specially the "sequence" of operations gives me headaches.
Does the AI tell the physics engine to steer the spacecraft OR does it first inform the Gameobject (Entity?)
and then the physics engine and how is that new position given to the graphics engine?

How about that: Your spacecraft class wraps the scene node and its representation in the physics engine. The vessel has accessors for its engines (e.g. thrustLeft, thrustRight, thrustMain) to be used by its pilot. Calling these results in the respective force applications to the physics engine that'll in turn move the rigid body. During update, apply the rigid body's transformation to the scene node (set the scene node to where the physics engine tells you). If you code your AI right, it'll know how to steer the ship, just as a real pilot would do (or in other words: it doesn't matter to the vessel what sort of pilot steers it).

[AReichl]

> ... spacecraft class wraps the scene node and its representation in the physics engine.

Yes- these are "components" then of my spacecraft class, which would be something like an "entity".

But with a gameobject (entity) like this i would have to loop over all gameobjects myself, check input
or AI, apply the forces to the physics engine AND THEN WHAT? The result of the physics engine IN THIS
step would be from the LAST step (i think we all can live with that). Do i then set the position for the
scene node directly here in my gameobject or do i wait until the scenemanager of Irrlicht updates the
scene node and fetch the position of the physics engine there?

Meanwhile i came to the conclusion that MAYBE it would make more sense to avoid additional wrappers
but use the possibilities of the engine directly - meaning writing your own extensions of scene nodes,
use the light manager ( even if you don't use it for light calculations, hehe, but it gives you finer control
over the different update steps ) and apply all "logic" (sound,AI,physics,...) inside your extension (which
in a sense would be something like an entity, only bound and updated by the scenemanger.

[CuteAlien]

(thought using an array with a std::pair often is faster as std::map is rather slow).

Sorry to pop in OT here, how should traversing an (unsorted) array be faster than a lookup in a sorted structure?
Aside from that I too would recommend to keep pointers to the related scene nodes of your game entities. I have found for myself that it's best to keep game logic and visualization as separated as possible.

Sort the array and do a binary search for lookup.I know sorting on insert sounds like it should be slower, but often it's faster because moving arrays around is so fast. While std::map internally works basically like a list and allocates memory for each element. Which makes traversal also very slow in it. In most cases it doesn't matter anyway - but if it is an area that matters (and gameobject access sometimes is) then it's at least worth comparing it and profiling both options.

[CuteAlien]

I just realized that I do have the position twice in my racer. Reason is that physics in my case uses fixed-size time-steps, so the scenenode position was updated after the physics with an interpolation between the last 2 physics positions. Meaning all objects were a little bit behind their real position (maximal 1 physics time-step which was maybe 16 or 20 ms), but had the advantage to move smoothly.

[polylux]

But with a gameobject (entity) like this i would have to loop over all gameobjects myself, check input
or AI, apply the forces to the physics engine AND THEN WHAT?

No necessity for that if you use an event-based mechanism. E.g. map a key event to a thruster.

The result of the physics engine IN THIS step would be from the LAST step (i think we all can live with that).

Step your physics sim before anything gets drawn and it'll be from the current frame.

Do i then set the position for the scene node directly here in my gameobject or do i wait until the scenemanager of Irrlicht updates the
scene node and fetch the position of the physics engine there?

See as I do it in my mini Bullet wrapper. Maybe it's of use for you anyways.

Meanwhile i came to the conclusion that MAYBE it would make more sense to avoid additional wrappers
but use the possibilities of the engine directly - meaning writing your own extensions of scene nodes,
use the light manager ( even if you don't use it for light calculations, hehe, but it gives you finer control
over the different update steps ) and apply all "logic" (sound,AI,physics,...) inside your extension (which
in a sense would be something like an entity, only bound and updated by the scenemanger.

I disagree personally as I think logic and drawing should stay loosely bound from many perspectives (would get lengthy). But that's just my opinion.

[odenter]

Thank's for you replies.
Looks like that my decision to create a std::map<ISceneNode*, IGameObject*> was a good way. The only thing I added now is a pointer of ISceneNode to my IGameObject to access all objects easily.

[Seven]

I think it goes back to the old question of whether, in your game, your game objects ARE a scenenode or whether your game objects HAVE a scenenode.
In my method, game objects can exist without a scenenode which auto determines the answer for me.

it's kinda like asking if, in a racecar game, whether the game object is the car which has an engine or whether the game object is an engine which has a car.
either will work, it just matters how you see it is all.

for my implementation, the game object has everything, AI, sounds, input, and the scenenode (or 10 scenenodes for that matter)
( for example, a torch has a meshscenenode, a lightscenenode, a crackling 3d position'd sound, and can damage any game object it comes into contact with )

game objects communicate with each other and with subsystems through messages and events.
I sort on insert and use an LOD system to run the objects in a time based scenario using distance from the camera to determine update frequency.

[AReichl]

> After I asked how to handle GameObjects and their SceneNodes, i've got a new problem.

SO - what's the solution???

[polylux]

Seven already gives quite a good insight in how GOs can be handled, I do it pretty much the same way.

[odenter]

> After I asked how to handle GameObjects and their SceneNodes, i've got a new problem.

SO - what's the solution???

To which problem? This question here or the question in the other thread?
Regarding the qustion in this thread I've given my GameObject a Pointer to a scenenode.

[AReichl]

> To which problem? This question here or the question in the other thread?
THIS problem.

> I've given my GameObject a Pointer to a scenenode.
Yes - of course. I have done the same. But what THEN?

You see, i read a lot about entity-component-actor-... systems and i have
looked into other engines to get an idea how they do it ( Delta3D is a good
example ), but my problem is how to combine all this theory with Irrlicht.

What i would like to see is a simple example as a starting point.
A gameobject ( call it entity or actor or whatever ) with pointers to
"components" ( scenenode, physics, sound, ... ), a list ( or vector ) of
gameobjects and THEN WHAT?