• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
chondee

Component based >? Inheritance based design

27 posts in this topic

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).

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

[b]2. [/b]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 [u]smaller working examples, a few-page article, perhaps some general rules of thumb[/u], stuff to look out for, or some direct [u]comparison with inheritance based design[/u].

Any assistance / shared opinions, experiences on this subject will be much appreciated.
Thanks in advance! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
0

Share this post


Link to post
Share on other sites
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.

[b]I[/b]n 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.

[b]In a nutshell: [/b]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.
1

Share this post


Link to post
Share on other sites
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.

[b]EDIT:[/b]
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?
0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
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.

[url="http://www.gdcvault.com/play/1911/Theory-and-Practice-of-the"]http://www.gdcvault.com/play/1911/Theory-and-Practice-of-the[/url]

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?
1

Share this post


Link to post
Share on other sites
No problem, that powerpoint sounds interesting might give it a read. You might also find this video helpful: [media]http://youtu.be/eNfXs51uflI[/media]
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.
1

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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 [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img])

Component based model could be complemented with data oriented design: [url="http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf"]http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf[/url]
1

Share this post


Link to post
Share on other sites
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. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

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

Share this post


Link to post
Share on other sites
Another one from DICE: [url="http://publications.dice.se/attachments/AStepTowardsDataOrientation.ppt"]http://publications.dice.se/attachments/AStepTowardsDataOrientation.ppt[/url]

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
1

Share this post


Link to post
Share on other sites
[quote name='chondee' timestamp='1334354101' post='4931068']
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?
[/quote]

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.
1

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
[quote name='chondee' timestamp='1334358011' post='4931084']
Thanks!

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

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.

[quote name='chondee' timestamp='1334358011' post='4931084']
- Ideally all entities should be treated exactly the same (on the outside nothing knows or can know what components does the entity have)

[/quote]

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

[quote name='chondee' timestamp='1334358011' post='4931084']
- Each component is capable of working completely independently without the assumption or knowledge of any other component within the same entity
[/quote]

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.

[quote name='chondee' timestamp='1334358011' post='4931084']
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?
[/quote]

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.

[quote name='chondee' timestamp='1334358011' post='4931084']
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?
[/quote]

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.
1

Share this post


Link to post
Share on other sites
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).
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
Usually, I'll have something like: title_state, menu, level1, level2, pause_menu, for example. But if each component is updating every loop (via the component managers) then surely having a state class with event/update/render functions (which mine have always had) wouldn't be needed since the component managers are being called every loop independently? The only role I can see for my game states now is just to load/remove any game entities relevant for that state. I guess it'll just take a bit of tweaking.
0

Share this post


Link to post
Share on other sites
[quote name='Jabzor' timestamp='1334411394' post='4931189']
Then surely having a state class with event/update/render functions (which mine have always had) wouldn't be needed.
[/quote]

Yes and no. Yes, because the game objects are renderered and updated by thyself. However, you should need to update your logic somewhere. One possibility is to associate scripts components to game objects. The scripts have custom update functions (the only component with an update method that is called by the script manager) and know the entity (the entity could be an empty entity with just the script). Another alternative is to manage the logic partial or totally in a higher level.
It’s up to you. But yes, the components are managed only by their manager, you only modified their data.
1

Share this post


Link to post
Share on other sites
[quote name='Jabzor' timestamp='1334411394' post='4931189']
Usually, I'll have something like: title_state, menu, level1, level2, pause_menu, for example. But if each component is updating every loop (via the component managers) then surely having a state class with event/update/render functions (which mine have always had) wouldn't be needed since the component managers are being called every loop independently? The only role I can see for my game states now is just to load/remove any game entities relevant for that state. I guess it'll just take a bit of tweaking.
[/quote]

Your game states should also respond to the event system as well.

For example, you may want your Level state to shift to the Game Menu state after the player hits the ESCAPE button. Depending on the current state (avatar has a target or has no target) would drive whether you progress to the new state or not but the Level State would need to subscribe to the E_STATE_CHANGE event that gets triggered if a state change was needed.

Steps:
1. Keyboard Component receives ESC
2. Keyboard Component checks if entity has Target
3. If Target, dispatch E_TARGET_BLUR event to deselect target then end.
4. If No Target, dispatch E_STATE_CHANGE event with state id "GameMenu" then end.
0

Share this post


Link to post
Share on other sites
A keyboard Component? IMO, the input should not be managed with components. The input in games is normally managed with states (like XNA), not events.

Events are double edged weapons, an event call could generate garbage (it can be avoided of course), events are slower than states, you could forget to eliminate a reference with disposing the listener and more important, the code execution order could be lost. But it’s true that they are very useful in several scenarios; I use them like a message system in my engine.

EDIT: I forget that I am in a C++ thread. Some disadvantages are more for C# than C++.
0

Share this post


Link to post
Share on other sites
So in your design you'd have the Level State receive the ESCAPE keyboard input, query the target system using the current player as a parameter to determine if that entity had a target. If it did have a target, you'd clear the target for the next game loop update. If no target existed or if the player hit ESCAPE twice (first doing the former, second falling into this scenario), you'd then instruct the Level State to push the Game Menu state onto the state stack. Does that sound appropriate?
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0