views:

87

answers:

2

I'm sure that there is a design pattern solution to my problem, but I can't seem to decide what a workable approach is. I know what I want, I'm just having trouble making the connections... I'll explain:

I'm working on a game. I have GameObjects. I have GameBehaviors. The properties of my GameObjects are defined in an XML file which has all of the details.

<type name="Object">
    <unit name="follower" behavior="followMouse" >
        ...other unit info here...
    </unit>
</type>

So as a gameObject is instantiated, based on the value of the behavior property in the XML, it somehow has the behavior attached to it. I need the behavior to be able to access all of the properties of it's parent, such that it can say move the object around and what not...

I don't have a lot of experience with design patterns... and a number of them seem like they're almost right but none of the examples that I've read seem to make it click for me.

I'm working with AS3, but feel free to make it bit more general.

A: 

I'd suggestion using composition, although your primary goal should be finding a good (reliable, extensible and maintainable) solution rather than using a named design pattern.

So your game object might have an initFromXML(xml) method, or maybe has a static factory method that takes xml as an argument. This parses the xml and looks for behaviors and then creates the appropriate behavior. Creating the behavior could be done with another factory.

You then add the behavior to the game objects behaviors list. Behaviors might all be objects descended from a common class, or they might all implement an IBehavior interface.

Behaviors can do their thing either by being called by game object, or by adding event listeners.

justkevin
A: 

I think I understand your approach.

This comes up a lot in games because you have an infinite number of effects, status, behaviors, etc, potentially.

What I see in your problem is you are dealing more with functional things like "does this follow this mouse", "does this respond to keyboard commands", etc...

In that case what you can do is create functional classes like "MouseFollower" or "KeyboardResponder" that generically accept a GameObject as the argument of their constructor.

Those objects can then apply event handlers directly to the GameObject such as eventlisteners.

You can store all of your functional objects in an array within the GameObject in case you need to remove them.

When they are in an array, you can also do cool still like create a functional class Interface with a uniform set of methods. So if, for example, the GameObject were rendered inactive or disabled, you could say

for each IFunctionalObject in GameObject.FunctionalObjects
IFunctionalObject.disable()

I guess this approach would be tolerable if you had a really huge variety of game objects, and I suppose an RPG would be a decent example where you are managing huge numbers of sprites of varying functionality.

Jasconius