I want to ask a question about how the information exchange between game engine parts should be implemented.
The engine is separated in four parts: logic, data, UI, graphics. In the beginning I made this exchange through the flags. For example if the new object is added in the data, the flag isNew
in a object's class will be set as true
. And after that the graphics part of the engine will check this flag, and will add the object into the game world.
Though, with this approach I was to write much code to process every flag of each kind of object.
I thought of using some event system, but I don't have enough experience to know whether this would be the right solution.
Is the event system the only appropriate approach, or should I use something else?
I’m using Ogre as the graphics engine, if that matters.
My favorite game engine structure is the interface and object<->component model using messaging for communication between almost all parts.
You have multiple interfaces for main engine parts such as your scene manager, resource loader, audio, renderer, physics, etc.
I have the scene manager in charge of all objects in the 3D scene/world.
Object is a very atomic class, containing only a few things that are common to almost everything in your scene, in my engine the object class holds only position, rotation, a list of components, and a unique ID. Every object's ID is generated by a static int, so that no two objects will every have the same ID, this allows you to send messages to an object by its ID, rather than having to have a pointer to the object.
The list of components on the object is what gives that objects is main properties. For example, for something that you can see in the 3D world, you would give your object a render component that contains the information about the render mesh. If you want an object to have physics you would give it a physics component. If you want something to act as a camera, give it a camera component. The list of components can go on and on.
Communication between interfaces, objects, and components is key. In my engine I have a generic message class that contains only a unique ID, and a message type ID. The unique ID is the ID of the object you want the message to go to, and the message type ID is used by the object receiving the message so it knows what type of message it is.
Objects can handle the message if they need, and they can pass the message on to each of their components, and components will often do important things with the message. For example, if you want to change and object's position you send the object a SetPosition message, the object may update its position variable when it gets the message, but the render component may need to message to update the position of the render mesh, and the physics component may need the message to update the physics body's position.
Here is a very simple layout of scene manager, object, and component, and message flow, that I whipped up in about an hour, written in C++. When run it sets the position on an object, and the message passes through the render component, then retrieves the position from the object. Enjoy!
Also, I've written a C# version and Scala version of the below code for anyone that might be fluent in those rather than C++.
#include
#include
#include
#include
No comments:
Post a Comment