composition-based design

Quote:

Original post by Ozymandias43 I was playing around on the net today and found this old article called "Object-Oriented Game Design." It describes an interesting approach to game engines where actions are separated from objects. http://www.devmaster.net/articles/oo-game-design/ and another, similar article: http://gamearchitect.net/Articles/GameObjects1.html Since the article's a bit old, and since I'm not sure exactly what the technique is called, I'm having trouble finding out more information about it. It seems like a potentially good way to handle a game (at least a single-player game, I'm unconvinced for a multiplayer FPS), but I'm wondering whether anyone else has any feelings on this sort of approach? Edit: linkified (.ED)

Well, correct object oriented design is a very valid approach for any kind of software, including games [grin].

The gamearchitect.net article just present a design approach which is fairly standard in the software industry - some might call this "modern design" but that's a bit pretentious.

Composition is easier to handle than inheritance, is less prone to subtle bugs, respects encapsulation, and have many more pros that inheritance don't have. That's why you'll hear the "prefer composition over inheritance" stuff a lot. If you want to find more information about this subject, you don't have to focus only on the game programming field. The is no software design particularities in game, so any good software design/architecture book will do the trick. I'm currently reading a bunch of them, I will probably post more information about that later (let's say... next month? maybe [smile])

That looks to be similar to the command pattern, which can be useful in languages like C++ which do not support first-class functions or partial application.

I keep thinking about actions and states as objects, and it just seems kind of weird to me. How actions can be generic enough to cover everything from "run" to "emit particles" to "fire weapon" and at the same time be generic enough to be reusable is a mystery to me. I suppose you'd need to just document carefully what states an action is interested in, but still. I'll try constructing a design as a thought experiment here:

Suppose there are objects that represent entities, states, and actions. Entities contain a list of states and a list of actions. Actions and states have IDs of some sort. Actions know about their owning entity and therefore its states when they're invoked, but that's it. States can be integers or pointers to other entities (for example, a player's targeted enemy).

So, the player presses the up key. This triggers event upKeyDown on the world entity. The upKeyDown action knows about its parent, the world, and the world has a state object for the actively-controlled player, so upKeyDown can find out which entity should be updated. upKeyDown fires the upKeyDown action on the player-controlled entity, and that action fires the Accelerate action and the AddWhiteCloudParticle action. Accelerate action increases the velocity state by the acceleration state. AddWhiteCloudParticle action creates a new particle to create a jet stream sort of effect. How it asks to do this I have no idea. Perhaps world entity has a special ParticleSystem state.

Then the engine calls the Tick action on all the entities. The player's object listens for Tick, then updates its Position state by adding its Velocity state.

Then the renderer runs. It looks at each entity for position and orientation flags, and then renders the entity (whose model is perhaps some other kind of object attached to the entity like a state, like a Form object).

Does this sound more or less like how it would work?