27 replies to this topic

[chondee]

I am working on a scrolling shooter in C++ / SFML, and without knowing anything about component and inheritance based design, I have intuitively started designing my engine and game objects that mostly resembles to inheritance based design.

I have stumbled upon a discussion about this then did some further research, and got to the conclusion that mostly in the 90s Inheritance based design was used in game development, but later on due to several reasons the standard shifted towards component based design, most modern games use that, and that I should probably consider rewriting what I already have following that (since I am mostly doing this for learning).

1. First of all, I would like to ask those who have some experience in this, whether this is mostly true. So is component based design in game development preferable in most cases against inheritance based, or is it not that simple? Are there cases when the opposite is true?

2. Could some of you please recommend me some material about game development related component based design?
Probably the ideal and best thing is to read through some huge book, but for me that doesn't really work when I am introduced to a new idea. It would be much more helpful if I could look at some smaller working examples, a few-page article, perhaps some general rules of thumb, stuff to look out for, or some direct comparison with inheritance based design.

Any assistance / shared opinions, experiences on this subject will be much appreciated.
Thanks in advance!

[Hodgman]

Regarding #1 - This isn't just applicable to component-based game entity systems, this is a fundamental teaching of OOP!
There's a ton of writing on composition vs inheritance, and the general rule of thumb is that you should default to composition, and use inheritance only when you have to (and only where you satisfy the promises that an "is a" relationship implies, such as the LSP).
Game component/entity systems are just a fancy way of making use of the software engineering principle of composition.

Excessive inheritance usage was popular in games in the 90's because most people were new to OOP and/or misunderstood OOP in the 90's
When you're new to OOP, it feels very natural to use inheritance to solve every problem, but there's often an alternative.

N.B. many great games were/are made using this coding style, so while being wrong IMHO, it obviously still works.

[chondee]

I see, thanks for your input!

[Koobazaur]

I've been experimenting with both in my own game and noticed that the main difference is that inheritance-based system tends to be far more "hard-coded" whereas a component-based one tends towards being "soft-coded." As far as pure DATA it doesn't matter that much, but it plays into LOGIC and you need to ask yourself, who do you want designing it - the programmers or the designers? The latter approach is increasingly popular because, much like contemporary games that rely on what-you-see-is-what-you-get editors and visual script/material systems, are all about empowering the designers so they can make and prototype without having to go through the programmers.

While it may seem that a component, designer-friendly component system would be the better choice, it does come at a price. Firstly, you will actually need a framework for handling logic by designers somehow. After all, they may assing whatever properties they want to entity (PhysicalBody, PartOfAFaction, InventoryOwner etc.), which basically destroys the concept of a "class." Think about it. You no longer have a "class CLever" but merely an entity with some CAnimatedModelComponent and CUsable, which triggers the animation and opens some door.

Either you have some flexible scripting framework that you can attach to the OnUse Event, or you hardocde a CUsableDoorOpeningSwitch that also requires a CAnimatedModelComponent to be placed on the entity... but at that point it would have actually been easier to simply make a CLeverEntity with AnimatedModel and TargetDoor properties.

The second problem is that it basically becomes a "weakly typed entity system." So it's great for fast prototyping, but is VERY prone to bugs. Suddenly the designers need to make sure the entity has all the right components that interact properly or unexpected errors will pop up. Worse yet, it is much harder to debug or account for those edge-case scenarios, and many of them wont pop up unless you do a lot of QnA.

In my experience, a component system is far more flexible and faster when set up right; but setting it up requires a lot more work and maintenance, and lack of proper support results in hard-coding very specific components that only apply to very specific types of entities, in which case you would be better off with an inheritance base system from the start.

In a nutshell: Honestly, consider what kind of a game you have, and what kind of entities you need, and go from there. If you dont need too many, inheritance is better. If you need a lot of rapid prototyping, component is the way to go.

[chondee]

Thanks for sharing your experience regarding this, I think I understand what you mean. With what I have worked with so far I have actually liked dealing with inheritance based entities, knowing the strict properties and capabilities of each one and treating each differently based on their type. It feels very limiting how in component based design I cannot differentiate entities, or assume any properties one might have, all have to be treated the same from the outside. I assume after some getting used to time it gets more comfortable.

I think my game would actually work just fine with the inheritance based entity structure that I currently have, but I am trying to design my engine similarly to how most modern games are designed, to get relevant experience in game development in hopes of getting a job in the field once I graduate.

Assuming that component based design is more relevant nowadays, I am planning to rewrite that way.

EDIT:
I am wondering, in component based design, is inheritance ok to be used between components, or all components are (or should ideally be) unique, and inheritance in that design model is something to be avoided altogether?

[Jabzor]

I've currently been looking into both design structures myself. Like yourself, I found my first games automatically leaning towards inheritance. However after looking into component structure it seems the better way to go (allowing for dynamic creation/modification of game entities at run-time is a big plus for me). The way I see it, is that you should almost certainly use inheritance within a component system if it makes sense to do so. An example of this might be a 'Mover' component, you could have both a 'KeyboardMover' and 'AIMover' that would inherit from Mover and imo I can't see any immediate problems in doing that - I could be wrong on that though. That being said, I haven't had much experience in component design but I'm looking to make my next game using exactly that. If anyone has links to good articles on the subject I would greatly appreciate it.

[chondee]

Thanks for your reply.
I found a pretty nice ppt from GDC showing how the development team transitioned from Inheritance based design (that they used for Hulk: Ultimate Destruction) to component based design (that they used for Prototype), and showing how component based design seems superior.

http://www.gdcvault.com/play/1911/Theory-and-Practice-of-the

It doesn't really go into specifics however.
Does anyone know of a good tutorial or project with some sample code that is built on composition?

[Jabzor]

No problem, that powerpoint sounds interesting might give it a read. You might also find this video helpful:
They explain some pros/cons of both designs. Their original engine used an inheritance structure but they've now moved over to a component one.

[Koobazaur]

Interesting links, the GDC and the video. I think there's also room for a mixed approach, especially when it comes to performance. You could do it by distinguishing between "engine" components (graphics, audio, physics etc.) and "gameplay" components (Usable, Inventory, Health, etc.) since the former often require greater optimizations and are less likely to be be rapidly prototyped by designers, whereas "gameplay" components will be constantly swapped around and readjusted.

The GDC mentions that RenderBehavior and PhysicsBehavior as attachable to GameObjects, right next to MoverBehavior or probably things like TriggerBehavior or InventoryBehavior. But what if, instead, you hard-coded that all GameObjects must have the Render/Physics/Audio components (or NULLs) and keep a free list of Gameplay Components? This way you can use direct function calls and make assumptions when it comes to rendering, physics and AI (as it relies on world visible/physical data), but still allow for flexible gameplay prototyping with messages/attributes between components.

You could even go ahead and make a few "base" GameObjects that force certain components; so a CCharacter would always have a RenderableBehavior and CRagDoll, a CProp would always have a CRenderalbe and CPhysics etc. While this does bring back some of the inheritance issues, if you design it right, it could potentially make engine-code much more cleanly separated from Gameplay/AI/Scripting code, and allow for necessary optimizations.

[chondee]

In my inheritance based structure, I could have my ship entity that owns 2 wing entities that move and emit particles based on the ships velocity, and can own weapon entities, that are also animated, and can use auto targeting (turn toward and target the closest enemy).

With component based design how is this implemented? Should the ship, wings, weapons be separate entities (each with its own set of components) that are tied together somehow, or I should just have my ship entity and the wings, ship weapons, wing weapons be components?

[jischneider]

You can read about components in the chapter 14 of the Jason Gregory's book Game Engine Architecture (third time in two weeks that I recommend this book, I am not Jason )

Component based model could be complemented with data oriented design: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

[chondee]

Thanks, I have actually just read this a few days ago, someone recommended it (DOD) to me as a better alternative to OOP design in game development. Definitely interesing, but I am starting to feel I have too much on my plate.

Could anyone please answer my previous question? I'd really appreciate it.

[jischneider]

Another one from DICE: http://publications.dice.se/attachments/AStepTowardsDataOrientation.ppt

And another good one:
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=0CCYQFjAA&url=http%3A%2F%2Fwww.gdcvault.com%2Fplay%2F1911%2FTheory-and-Practice-of-the&ei=QqiIT6uIFZKy8ATCsenhCQ&usg=AFQjCNGVTFg3QbWsg62Hqimepl-bQB1LaQ

[jischneider]

In my inheritance based structure, I could have my ship entity that owns 2 wing entities that move and emit particles based on the ships velocity, and can own weapon entities, that are also animated, and can use auto targeting (turn toward and target the closest enemy).

With component based design how is this implemented? Should the ship, wings, weapons be separate entities (each with its own set of components) that are tied together somehow, or I should just have my ship entity and the wings, ship weapons, wing weapons be components?

They are different entities with different components. But the entities are in a hierarchy (not inherence).
You should have something like this:
Ship = new GameObject();
// Fill Components
Wings = new GameObject();
// Fill Components
Wings.Father = Ship;

Then, when you move the ship the wings will move equally.

[chondee]

Thanks!

In this kind of hierarchy, should the parent and child know about each other's components in general, and work accordingly?

I am just having trouble thinking out a general design that obeys the most important concepts of component based design:
- Ideally all entities should be treated exactly the same (on the outside nothing knows or can know what components does the entity have)
- Each component is capable of working completely independently without the assumption or knowledge of any other component within the same entity
- Each component should still somehow be able to communicate with one another (or provide information that another entity if exists might make advantage of)

For the communication, the way I picture it huge switch-case blocks will need to be used for the "just in case there is a xyz component in this entity". Is that how it should be?

For the custom hierachy, when an entity is in Father-Child relationship, how does that affect the general operation? Does each component have to have a different set of switch-case statements in case the holding entity is a Child, or is a Father?

Or should I use more specific single-purpose components, so I could use one that is making the assumption that the entity in which it will be used is a child or father to something? Wouldn't that however beat the purpose of the whole concept of nothing makes any assumptions?

[jischneider]

Thanks!

In this kind of hierarchy, should the parent and child knows about each other's components in general, and work accordingly?

Depends how you interpreted “knowing each other”. The child only need to know the father world matrix and nothing more. It is possible that some custom script could also read some information from the father.

- Ideally all entities should be treated exactly the same (on the outside nothing knows or can know what components does the entity have)

Yes. The entity does not have an update, only the components.

- Each component is capable of working completely independently without the assumption or knowledge of any other component within the same entity

This is tricky. For example, a renderer component needs the world matrix from the transform component and the model from the model component. You just can’t avoid not knowing anything.
That said, yes, the component update has to be isolated. The only exception is the transform component; a physic component for instance could modify the entity’s transformation.

For the communication, the way I picture it huge switch-case blocks will need to be used for the "just in case there is a xyz component in this entity". Is that how it should be?

No, messages or events are the best. The component that needs information asks for the information, not the other way around. Read Jason book, read Unity3D reference, or look at my engine.

For the custom hierachy, when an entity is in Father-Child relationship, how does that affect the general operation? Does each component have to have a different set of switch-case statements in case the holding entity is a Child, or is a Father?

The components normally are very simple. Transformation components (a maybe physics components, I don’t know) are the only that needs to know the entity father. And actually, in the actual implementation the transform component is the only that holds the father (not even the entity). This is intended for data oriented optimizations and because is somehow logical.

[jischneider]

Please, press F5. I edited the text.

[chondee]

Thank you very much for your detailed answer and explanations. I think I have enough information now to start redesigning what I have, and when specific issues would arise I would come back for help.

I'll also read through the relevant part of the book you suggested, and look through your engine and Unity 3D. I'll also keep DOD in mind, but I'm probably just going to focus on one thing at a time (transitioning and adapting to composition).

[Jabzor]

Thanks for all the links, I've found this thread pretty useful. The way I use game states now seems to be vastly different to when I had an inheritance model. Because with that model it would be that each state updates and draws everything relevant to that state. But with the component system, it seems that the 'component managers' will just update every component every loop (independent of the game state), removing the need for separate 'event', 'update' and 'draw' virtual functions per state. It seems the only use for states now is just for loading and unloading game elements into the 'entity manager' every new state. I'm guessing each state should have it's own entity managers and component managers? Does this sounds like the best approach? Thanks.

[jischneider]

What do you call game states?