Composition vs. Inheritance for Game Objects/Entities in a Game World
Hello all,
As a side tinkering project I've been working on designing a MUD and how I want to represent individual entities. For those who are unaware of what a MUD is, please see the Wikipedia entry.
After reading several articles and threads on the theory behind composite design for game entities, this one caught my interest. Unfortunately I felt as if it didn't have much of a closure and wanted to bring it back up. What I am mainly interested in is if anyone can provide links to or implementation details (preferably in C#) of a basic composite/component based design for game entities in order to hopefully help further my understanding of how it may work.
From what I am understanding, a game object/entity class is composed of other classes which define characteristics and behavior. The concept seems simple enough, however my question(stemming from my current lack of experience in design) is how to make the objects communicate with each other in a "proper" way. Is communication handled by implementing an event system in which each behavior subclass would override some methods, such as: UnderAttack(), OnMove(), etc?
I would greatly appreciate if anyone could provide further clarification on this , thank you!
Don't worry about "communication" until normal methods don't seem to be working. Event systems are for handling situations where there are actual "events".
An object provides an interface via its member functions. Member functions are functions: they get input ("communication" directed inwards) via their parameters, and report output (if any) by returning a value (or reference to an existing value).
An object provides an interface via its member functions. Member functions are functions: they get input ("communication" directed inwards) via their parameters, and report output (if any) by returning a value (or reference to an existing value).
Sorry, perhaps I worded my post incorrectly. My main question was if anyone could provide an example or links to an example of a system where instead of entities having a deep inheritance tree they instead have an instance of a "behavior" class. In other words, instead of knife is-a blade is-a weapon, you have an instance of Entity, which has-a instance of a "knife" behavior which inherits a "behavior" base class. Hopefully I'm putting this out correctly. Forgive any typos as I'm posting this from my cell phone.
Thanks!
Thanks!
Would anyone like me to clarify further in order to receive a response? Perhaps I'm not getting the point across clearly but I will need to know what the confusion is.
Quote:Original post by dmreichardI'd recommend searching the forum archives for 'component entity system', and just reading through all of the threads that you find. It may take a while, but I think you'll probably find what you're looking for in previous threads on the topic (of which there have been quite a few).
Would anyone like me to clarify further in order to receive a response? Perhaps I'm not getting the point across clearly but I will need to know what the confusion is.
As for your question, I'd recommend sticking with simple function calls until/unless you find that that doesn't meet your needs (like Zahlman said). As for how to facilitate this, a fairly common approach is to allow components to acquire (via their parent entity) references to 'sibling' components, through which they can communicate with said components directly.
For a working example of this type of system, check out the Unity game engine.
I think the solution your looking for is:
This relationship is inheritance
This is composition:
I hope this helps.
This relationship is inheritance
class Entity // derived from object behind the scenes{ //Name //Etc.}class Knife : Entity // Knife inherits Entity { //doDamage() etc...}
This is composition:
public class Behaviour{ . . . }public class Knife{ Behaviour b = new Behaviour(); .......}
I hope this helps.
I have been looking at the difference between deep inheritance hierachies and component based systems. A good example of a component based system is the Unity game engine. Everything is a component, physics, graphics, scripts etc... I know it has very little to do with MUDS, but you might be able to appreciate its architecture. It is a really nicely written system and free. In terms of objects communicating with each other, that, in my opinion, is largely dependant on the scenario. Again have a look at Unity, they do lots of architectural stuff pretty cleanly.
Also there is a blog site gamearchitect.net which talks about some of this stuff.
Also there is a blog site gamearchitect.net which talks about some of this stuff.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement