The ObjectShell and how it saves the world
Woahwoahwoah, what's that? An ObjectShell? What the hell does that mean? Sit down, and let me tell.
If you read my last post, you know that I was thinking about reworking my gameobjects. So far I had a monolithic structure, which I didn't really like. So I went and started studying my pacman implementation again. First thing I saw there: I made it way more complicated then needed for such a game.
Second thing that I saw was a very neat way to control an object. I thought to myself, why the hell didn't I build that system in my new engine? After a few slaps to my face, I started recoding my gameobjects.
There I came up with my ObjectShell. The term shell is really descriptive, I think. You could also say hull or casing, but I like shell more.
The ObjectShell basically looks like this:
class ObjectShell { private ControllerComponent controllerComponent; private GraphicComponent graphicComponent; private PhysicComponent physicComponent; private EventComponent eventComponent; }
As you can see, it's composed of four different components.
The ControllerComponent controlls the (desired) movement of an object. Behind that could be a user controller (Keyboard, Gamepad), a network controller (proxy object) or an AI controller.
The GraphicsComponent represents the object on-screen. It could be as simple as displaying a simple 2D texture or a complete ragdoll.
The PhysicsComponent is used for simulating the object in a physics world and keeping track of the position of the object. It could be empty or very complicated with constraints and such
The EventComponent manages all the events raised and received by and for the current object. It registers itself with other EventComponents and sends them events when they occur.
This pretty much follows the concept explained in Game Engine Architecture, with some modifications. The complicated part isn't coding the individual components but rather to get them communicating between each other, which is equally important. For example, the GraphicsComponent needs to know the position to where it should draw from the PhysicsComponent. This, in return, needs to know the size of the object. The ControllerComponent maybe need to know some collisions in order to make decisions from physics and, of course, the PhysicsComponent needs to know the input from the Controller.
As you can see, this is non-trivial. There are a few options to choose from:
Define distinct communication interfaces This would be the broadest approach. It would mean that any component can talk to any other component, without knowledge of what this component does. It's pretty similar to an event driven system. However, this would mean a whole lot of error handeling and generic programming, which isn't really that good either, because you can use that power somewhere else.
Let the ObjectShell do the communication The ObjectShell is the only thing that knows exactly how its components should work together. It knows what comes out of one component and what should go into another component. This is my favourite approach right now. It's flexible and gives me precise control over each object. The flipside is that I have to keep my monolithic design. It's not as bad as my previous approach, since I can easily switch components without breaking other parts of my implementation.
Make the components talk to eachother directly This is the last approach I can think of. One Component has a reference to another component and tweaks its settings as it sees necesary. This is simple but also dangerous.
As said, I like the second option best. It's the mix between my other two approaches, and I think that's always the best.
Going to code that stuff now!
