data driven game objects

[drwbns]

Hello, I've been reading a lot on data-driven designs and component based designs with game objects and I tend to get confused about the topic because of all the different explanations for it. When it comes to a simple Player class and a Vehicle class, I want to design a controller for the player, but add the ability for a player to enter a drive a vehicle. Do I come up with 2 seperate controllers with a switch? Also, how do interfaces and behaviours come into play with a data-driven design? Does a player have a vehicle component? Or does a vehicle have a Player component that is derived from a Driver component that has a driving controller component? Can anyone provide some code examples or explanations on how or when components should connect or a guide on how to design the couplings? I'd ultimately like to be able to understand an overview of the design choices and why things should be coupled in one way or another and why. I've also read something that said logic and behaviours should be seperate. What does this actually mean when it comes to class designs? Also, should the term properties and the term components be thought of as 2 different things? Thanks for any help

[jacmoe]

This is the topic:
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=36015

And, no: you're not going to get a one comment answer to your question.

I think what you're mixing is (at least) three things: data driven design, component based design, Model View Controller (MVC) paradigm.

For the latter, which can help with datadriven component oriented design - mostly for desktop applications - you can look at the various Qt frameworks docs on MVC.
It's the best real world example of MVC for C++ I can think of.
You probably want to search for the documentation for custom tree views and their corresponding model adapter class(es) I think..

But, it does not lend itself to games/graphics.

Gamasutra has this article..
Here it is:
http://www.gamasutra.com/view/feature/2 ... e_code.php
It's a post-mortem on one of their games where they decided to let it be data-driven and using the MVC pattern.
Read it.

[Herb]

The topic jacmoe referenced is the big one. But I'll throw a link out that helped me figure out component systems HERE too.

[drwbns]

I've read both topics, or at least a big part of the BIG topic but I'll read it again. The thing I'm not really sure of is why people seem to want to duplicate position, orientation, etc.. Why not just keep it in the MeshPtr? I'm trying to figure out how using Ogre affects this type of system also.

[bstone]

I've read both topics, or at least a big part of the BIG topic but I'll read it again. The thing I'm not really sure of is why people seem to want to duplicate position, orientation, etc.. Why not just keep it in the MeshPtr? I'm trying to figure out how using Ogre affects this type of system also.

Let the seasoned drunk coder daub this thread as well: as long as you think that MeshPtr stores position and orientation you'll be posting the original question times and times again. Wait... is that why you were doing exactly that for so long?

[drwbns]

lol sorry I wrote that in a hurry, I meant why duplicate Position, orientation from the SceneNode. Shouldn't the SceneNode be a component of a GameObject?

[jacmoe]

Why are you asking those questions?

First, a component?

Or a composite element?

A SceneNode can't be a component in the 'component' sense, because it isn't a component.

It all depends on your design now, doesn't it?
How much coupling you want.
And whether or not your components/objects should contain data at all..

So, why not just clear the drawing board and grab some sketching paper and get to it?
Then you can ask specific questions.

[bstone]

No, it can't be a component of a GameObject in the common sense because SceneNode is an implementation detail of the Ogre's scene manager. You could however refer a SceneNode in the GameObject as a private implementation of your position/orientation storage but hide that behind a nice public interface of the GameObject itself that would pretend to own position/orientation data itself. It doesn't matter in the end who owns what. In OOP design data is somewhat secondary whereas the message protocols (i.e. interfaces) are what is the most important.

[bstone]

Why are you asking those questions?

I bet we're witnessing the birth of another book on OOP design. Something like Data Oriented Component MVC Whatever Design in Games: Common Methods and Whatnots

[drwbns]

Ok, thanks for the replies. I think I'm pretty much getting lost on interface designs. Any suggested reads to solve that problem?

[jacmoe]

Just do it. Try something, and then something else.

This is really hard - for me as well.
For most people, actually.
Even seasoned developers.
Or, perhaps I should say: especially seasoned developers..

Don't get stuck in the design phase - you might never get out of it. Ever.

Just make something which works - and tweak and fix and rewrite as you learn.

I think this is the most exasperating aspect of programming..

Of course, it's also really great to see a design taking off - I guess that's why we do it.

[crancran]

I can't stress enough what jacmoe is suggesting.
We've all been there and have an entire closet collection of the T-shirts .

When it comes to designing components, one of the things you should watch for is anemic or bloated components. You will find sometimes you have a few components that seem silly to have 1 or 2 float values in them and when you begin to profile your code, you will usually find that such components often cost more to manage that way than to merge those values into a bit more of a generalized component with other data. It often is game specific so you'll have to test the waters with whatever you're designing. Generally speaking, I prefer to start with something that is a bit bloated and refactor down rather than the other direction because it's a lot easier to detect, at least for me.

To answer some questions from your original post:

Hello, I've been reading a lot on data-driven designs and component based designs with game objects and I tend to get confused about the topic because of all the different explanations for it. When it comes to a simple Player class and a Vehicle class, I want to design a controller for the player, but add the ability for a player to enter a drive a vehicle. Do I come up with 2 seperate controllers with a switch? Also, how do interfaces and behaviours come into play with a data-driven design? Does a player have a vehicle component? Or does a vehicle have a Player component that is derived from a Driver component that has a driving controller component? Can anyone provide some code examples or explanations on how or when components should connect or a guide on how to design the couplings?

It's entirely up to you on how you want to approach it.

In the beginning, both the player & vehicle (tank for example) are entities with their own set of components. The tank could have a DriverComponent that has no entity reference until a player decides to jump inside. By jumping inside and interacting with the tank, the DriverComponent gets set with the player entity reference. This causes the input/controller to dispatch commands to the tank rather than the player itself. The player's animation may now be fixed to say "RidingAnimation" and there is some join point between the two entities to keep them physically connected while the tank moves around the landscape.

Another approach is that the Player receives a VehicleComponent when they interact with the tank. This causes all player input to be redirected to the Vehicle's Controller instead of the player. It also causes the Animation System to set the animation to "RidingAnimation" because the player has a VehicleComponent linked with it. Once the player ejects from the tank, the VehicleComponent is removed from the Player and this reverses all the wiring for input & animation back to the way it was before.

I'd ultimately like to be able to understand an overview of the design choices and why things should be coupled in one way or another and why. I've also read something that said logic and behaviours should be seperate. What does this actually mean when it comes to class designs? Also, should the term properties and the term components be thought of as 2 different things? Thanks for any help

The separation of logic & behavior implies whether you're approaching your component design either INBOARD or OUTBOARD.

The INBOARD design basically means that the components themselves do both the logic & behavior. In this scenario, this is where you often see an Update() call on the component itself. Generally we find that this type of approach leads to a massive for loop in the game loop logic update where each entity is iterated and each component is then iterated for each entity. While this works there are some pitfalls with this approach as you aren't making very good use of cache locality and thus speed & performance are impacted because you're not doing tightly coupled updates across batches of entities. This also doesn't lend itself well to parallelizing any tasks either due to dependencies between components.

The OUTBOARD design implies your components are nothing more than data containers (properies if you will). You have seperate systems (movement system, rendering system, vehicle system, combat system, etc) that are all responsible for some facet of gameplay. These systems operate on a finite set of components it needs to perform it's tasks. In this case, each system will iterate only over entities that contain the components of interest. Each iteration becomes a very tighly coupled piece of logic that makes good use of cache locality which improves performance. It also means that you could easily take advantage of multi-core parallelism here where you operate over a list of 100 entities, where core1 updates 1-25, core2 updates 26-50, core3 updates 51-75, and core4 updates 76-100 (assuming that whatever this task is can run in parrallel of course). Now that logic and behavior are separate, it also means that several systems can make use of the same component too with minimal coupling too, which is what you want.

The first approach is often easier for developers to understand compared to the latter of course.

[drwbns]

Speaking about the outboard design - is this in the style of using a generic component class, and then have entities registering themselves with a componentManager as having that component type or not?