Sign in to follow this  

Composition vs. Inheritance for Game Objects/Entities in a Game World

This topic is 2851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by dmreichard
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.
I'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).

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.

Share this post


Link to post
Share on other sites
I think the solution your looking for is:

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.

Share this post


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

Share this post


Link to post
Share on other sites

This topic is 2851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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