How do you usualy use Ogre in your projects? [Architecture]

[SanityAssassin]

Hi guys and girls,

I have some experience with Ogre3d, programming in general and C/C++. Had successfully built Ogre from source, went through the tutorials and samples, even done some shader stuff... anyway, I have decided to try to make "Red Alert" clone, just to get my hands dirty, learn litle more about Ogre, game development in general and have fun doing it above all.

Already implemented some "game engine" classes for "World", "Buildings", "Items", "Players", etc. Now, I wonder how to add Ogre3D to it, more specifically, how to relate e.g. Ogre scene nodes to my engine classes, e.g. for buildings?
What is in your oppinion best way to do it, integrate Ogre3d into your projects? Does your classes just extend Ogre's SceneNode class? I would like to maintain layers, so I have posibility one day to replace Ogre3d with Irrlicht or some other graphics engine if neccessary without much fuss.

Graphics Engine (Ogre3D)
Physics Engine (Bullet Physics maybe)
Game Engine ( My silly implementation )

I am not asking for any implementation, just advices, philosophy and theory.

Hope my question is clear and I am also aware that my questions may be better for some game development forum instead.

Thanks in advance,
Cheers,
Bojan

[al2950]

That is a very simple question with a very long answer! There is quite a lot of info in the wiki, and this question has been asked a few times in the forum, but I can appreciate design philosophy in the game engine world can change quite quickly!

Anyway my current engine is ok, and it is partially component based, but it still relies too heavily on inheritance. Here are some notes that may help

- Never inherit from Ogre::SceneNode, that will only cause you pain!

- Like everything in the world, inheritance is great but only in moderation. You mention layers and that would concern me, depending on what mean. You should look at component based systems,...

- I would create a VisualComponent, this would contain a SceneNode (which may have many children), but I would not make it directly accessible by anything using your engine. Some people go mad with component based systems, and have components for simple things like transform, but it can get complex quickly!

- After you have your components defined, you need keep them in some form of container. What I have is a behaviour associated with each of these containers which control the components it owns. What I quite like is to split the behaviour up into events and updates. IE there is a 'script' that gets called by all registered events, which in turn will do some logic and set some local variables. Then have another 'script' which is basically run on each frame which will update the state of the components based on the variables set in the event script. This splits things up quite nicely, and also makes networking easier

As I said before there is no one answer to your question and the answers are very long. My answer is extremely short with huge gaps but I hope that it might help! I would also be interested in seeing what other people have done recently

[SanityAssassin]

Thanks for reply!

I understand your point. Component based design gives more flexibility if done properly. Did some research on the topic and found out it is quite popular design approach in game industry.

In regards to events, how do you dispatch them among the Entites and Components? Simple method calls or multithreaded message bus? What are your favorites?

[al2950]

Well to be honest thats an area I dont like in my current engine, it is effectively the containers responsibility but it does it in poor way!

There is a lot of text about setting up a messaging system so components can send messages and affect other components, but I really did not like that, and I am probably wrong but I plan to go about it in a slightly different way. I think its important to keep components at a high level so you would have something like a Screen component that has the following properties
- Graphics Mesh + texuters, etc
- Physics mesh + physics properties
- Transform, ie SceneNode

You add a Screen component to the container, and then instead of having Screen component send and receive events you have a 'behaviour' class which receives events and updates its components. So the behaviour can register with certain global events, eg mouse input. But you may also want to it to be affected by other entites in your system. This is where I would have another component called Trigger or something which has a bounding box, and when one entity enters into a bounding box of a trigger it can receive certain events.

Other components you may have
- Sound
- AI Agent (This may also have similar concepts to the trigger component)
- .....

Please note I have not implemented the above idea yet, just bits of it, so it might be utter rubbish! One other thing I want to do is have the behaviour classes all implemented in C# as thats were most of the logic will sit but does not have to be as performance sensitive as other parts of the system. As much as I love C++, from a production point of C# is a great language and reduces production time and bugs dramatically, at least for an average development team!!

**EDIT** As for how to implement the events, thats an implementation detail. But I would say I would not use a multithreaded message bus unless that was an obvious bottleneck that I could not live with

[SanityAssassin]

So far I have came up with something like this:

Engine (Consists of multiple Systems, main loop, which updates every system on each iteration)
- Graphics system ( Ogre Rendering Integration )
- IO System ( OIS mouse and keyboard input integration )
- Resources System ( Ogre Resources loading integration )
- Overlay System ( Ogre Overlay integration )
- Physics System
...

Next steps are following:
- GameObject container implementation
- Each GameObject conststs of multiple Components which add properties or behaviour to he game object
- e.g. Components would be MeshComponent, PhysicsComponent, AudioComponent, TransformComponent, etc.
- Components will react to events created either by other Components or GameObjects, even Systems
- Event mechanism implementation
- for the start this would be static method like EventBus::broadcast() and event would be "broadcasted" to all systems, game objects and components. I would be happy if this would work like this for the startand worry about speed and optimization later.

WIll try to implement this way, and add Ogre Head (something like Ogre Basic Tutorial I) as a game object with belonging components just as an example and to measure "performance" if engine behaves as planned.
Will add source to the github, and add repo link here once I'm done with planned, so you guys can check, get involved or give comments.

[TheOnlyJoey]

Most of the time I am for a GameObject - ObjectManager pattern.

Normally my GameObject is a general object which contains or inherits a Ogre::Node (depending on the further structure of my project) and will be the base object to build from.
When I work with objects that require a tick (for logic) I most of the time introduce a GameObject::Tick() or a GameObject::Logic::Tick() that I add to a list which gets updated every frame.
Other more specific objects that require custom ticks, I inherit from this object and overload the functions, virtual can be quite handy in these cases.

I also do my own management of these object with a ObjectManager which has a list of all object, in total or per scene (scenes I usually do per resource group, which is a different concept all together). Each GameObject has its own Type identifier (ENUM) which is used to cast the GameObject to its inherited type when deleting/creating a object in the ObjectManager.

Designing other systems, I try to do something similar to this method.

For GUI I personally would recommend using MyGUI and for Physics using Bullet, these libraries have proven themselves over the years, and since Ogre Overlay is quite basic, a more advanced GUI library would make more sense.

[WilliamKappler]

This really depends a lot on your situation; different games/projects will have different options for how to handle it. Something like a simple arcade game can probably do with directly linking Ogre objects to game logic. Something involving networking, or more complex game object management, will need greater separation between Ogre and the game logic, and more complex systems to handle the relationship.

Since the above is basically what other people said, let me give you the case of my project, which is on the extreme side of game-to-Ogre abstraction.

In Onathacar, I have game data which itself is largely abstracted. There are real instances of game objects and data-only copies of game objects, with the goal being to essentially have every planet in the game have its own map of the galaxy (representing what is known, currently, about the galaxy on that one planet). Fog of war to the next level.

This system doesn't allow Ogre to be directly interfaced with the game logic, since the player might move between planets, you have the real vs. copies of game data, and some other complexity. As such, I have a class which handles all I/O, that binds to a given planet (+ faction), and upon binding, generates a set of XRepresentation classes (where XActual or XIntel are the real/copied objects, and X is whatever type of object it is - a planet, a ship, a character, etc.). Those classes then bind softly to the game data, and create Ogre classes as necessary to represent the game data.

This is probably way too complex for your situation (it's indeed more complex than any game I know of), but I think it serves as a good example of how Ogre/data can be organized in a very convoluted situation with a ton of special requirements.