Sources for Object Organization/Structure in Games?

There is none that I know of. Though general OOP design will apply just as well to games. One thing that helped me in particular was learning the concept of data normalization (something I missed not having formal education). Though that tends to only be (informally) covered in database books.

I'm a big fan of Bilas' Dungeon Siege presentation.

Quote:

Original post by ltkerr0rYou can learn some implementations from open source games. The code usually has decent comments and sometimes it will come with an explanation of how things work.

While some games have good source, others have bad source. Without experience it may be hard to see what is easy or hard to maintain. Sometimes blocks of code may appear to be a good design, only to find after using it that the design is difficult to maintain.


Games are just another piece of computer software. Traditional software engineering principles still apply.

Quote:

Original post by Sean_Seanston Something covering things like how/why to make a main GameObject base class and how to use it and good ways of implementing the various different object types that are typical in a game (and presumably inherit from GameObject). When composition is usually more suitable than inheritance in a game etc. and proper ways to do it.

Sometimes it makes sense to derive renderables from a class named Renderables or something similar, and a Model object which is a Renderable, Particles which are a Renderable, and so on. For other engines, that could be a really bad idea but it would be better to have your objects contain the generic renderable things rather than inherit.

Sometimes it makes sense to have these classes as an actual inheritance tree, other times it makes sense to use the "Curiously Recurring Template Pattern" on them. Or your design may want both.


Ultimately you learn how to structure software well by having experience. You gain experience by doing it poorly.

The moral: Do something. The only "wrong" way to do it is to not do it. Even if your implementation has problems, you have learned something.

Quote:

Original post by Promit I'm a big fan of Bilas' Dungeon Siege presentation.

I read that briefly before... just had a better look at it.
Seems to very much favour composition.

On that subject though, I need a bit of clarification on composition. I suppose in a game you might have components like: HealthComp, RenderComp, MoveComp etc.

So for a movable enemy they'd need all 3 of those. In an actual implementation of that,I assume the enemy's health variable would be contained within HealthComp and then accessed by something like Enemy->Components->HealthComp->GetHealth(), but what about for motion and rendering components? The position would have to be accessed by both. Would you maybe put "int x, y" into RenderComp (since location is probably only needed at the earliest if you're drawing something unless it's invisible for some reason) and then use functions of RenderComp to access and change it from MotionComp? Or should position be an inherit part of the class anyway before components are added?

Unless I completely misunderstood how it works :p

Quote:

Original post by frobUltimately you learn how to structure software well by having experience. You gain experience by doing it poorly. The moral: Do something. The only "wrong" way to do it is to not do it. Even if your implementation has problems, you have learned something.

Yeah, I need to remember this whenever I'm tempted to go off on a tangent instead of work on something. It's just so tempting to plan too far ahead.

Everything I've read on object composition implies that the properties of an object are stored in its various behaviors. If this is true then what ends up happening is behaviors that use the same properties as other behaviors have to communicate changes in the properties in some method.

One method suggested is having components store references to other components that share the same properties and directly update those components when necessary. This gets ugly because there's a tight coupling between components now, also additional memory is needed to store the references per component per object. On top of that if you create a new component you have to go back through your other components and identify which properties it's going to affect in those components so this starts to resemble old spaghetti code.

Another method is to use a messaging system. When a component changes a property it sends a message to the object it is contained in with what the change was. The other components in the object then listen for the message and update themselves accordingly. This works fairly well although now you have to implement message sending and receiving methods within your components now. Chances are you've done or may do this for objects themselves so they can communicate between each other so there should be a template for you to follow.

And yet another possible method is to separate the properties from their behaviors and store each within two different tables within an object. The behaviors now each all reference the same object property table and can directly read and write to it accordingly without any knowledge of the object or other components. You eliminate redundant data between components(although redundant data isn't necessarily a bad thing especially when dealing with multi-threaded/core programming). Now the big question here is do the properties of an object define what behavior it has or do the behaviors define what properties an object has? I actually have not read anything particularly on this method and I am working on an implementation of it right now so all its true pro's and con's might not be apparent to me yet. I'm sure others here might be able to dissect those things.

If you can get a copy of AI Game Programming Wisdom 3 it has 3 good articles on object composition architecture, one is on general use and the other actually describe its use and a bit of implementation in A.I.

On a possibly unrelated note, would anyone recommend anything from the Game Programming Gems series?

Quote:

Original post by Edge Damodred And yet another possible method is to separate the properties from their behaviors and store each within two different tables within an object. The behaviors now each all reference the same object property table and can directly read and write to it accordingly without any knowledge of the object or other components.

Yeah... sounds interesting.

So would that involve maybe a component pushing x, y variables into some kind of container when it gets added to an object, but before it does that it would somehow check if they already existed? Which maybe could be done with some kind of map or something where a string is the identifier, "x" and "y" in this case.

I'll have a look at that book if I can, thanks.

Yeah that was pretty much the approach I was going. When you add a component it registers the properties it needs, if the property doesn't exist then it is added else move on with life.

Quote:

Original post by Sean_Seanston Quote: Original post by Edge Damodred And yet another possible method is to separate the properties from their behaviors and store each within two different tables within an object. The behaviors now each all reference the same object property table and can directly read and write to it accordingly without any knowledge of the object or other components. Yeah... sounds interesting. So would that involve maybe a component pushing x, y variables into some kind of container when it gets added to an object, but before it does that it would somehow check if they already existed? Which maybe could be done with some kind of map or something where a string is the identifier, "x" and "y" in this case.

Hmm, reminds me of this: Properties-based programming. It's a long read, but interesting.