Maybe I'm late to the party, but a friend of mine recently recommended the PushButton Engine for the flash projects that I'm working on. While I'm not 100% sold on the engine yet (still playing around) the component based architecture is really interesting compared to the object oriented way I've been doing other (mainly Java) projects.

http://www.youtube.com/watch?v=auaqZzcjl-Y

Looks like an interesting solution to problems that I have had crop up in the past. Would take some getting used to as well.

As I only really know about this from an engine that is selling it as the best thing since sliced bread I'm sure there are pros and cons to this approach as well. Anyone know much about this and have thoughts to share? Not just in regard to the push button engine but to taking this approach for engine or game development in general.

_________________
www.littlemonkey.co.nz

The high level overview certainly seems to make sense. Not sure about the nitty gritty of implementation though, I can't see how it'd work in code.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

The presentation was a reasonable overview but I would have preferred a bit more meat and details.

Someone posted an article on gpwiki a while back about the "super pattern" of using composition. I've tried googling and searching my favourites to unearth it but haven't had any luck. It was a cool essay about using composition instead of inheritance and went into more detail than the video does.

edit: Ok, I found it http://steve-yegge.blogspot.com/2008/10 ... ttern.html

and more about the topic:

http://www.delicious.com/portable_bookmarks/components

_________________
Whatever the mind can conceive and believe, it can achieve

I think it is just the decorator pattern.

It seems to be or at least very similar to. Any thoughts on the pros and cons of using the decorator pattern to flatten the inheritance hierarchy? Or as codehead is hinting is it so complicated to implement that its not solving any problems anyway.

Then engine itself obviously works, its made games
http://www.playdom.com/games/socialcity

Just wondering whether is a good approach for things outside of that particular engine...

I'll keep playing around and reading lengthy articles and see what I come up with

_________________
www.littlemonkey.co.nz

It's not really the decorator pattern. It's even more basic than that. It's just an appropriate use of an OO feature, i.e. composition. You can compose one class out of many other classes, all it takes is that it's declared as a member variable. You do this all the time in OO. The only way to bring in functionality from another class is by inheritance or composition. Inheritance implies heirarchy though, which is sometimes a hinderance.

The idea here is that it's better to use composition than inheritance in a game engine because of the problem of designing a heirarchy that has no overlaps. The idea is extended by creating a generic way to add components to a game object, which is by making all components inherit from a base component class. This is all still just the very basic OO thing of composition. A game object has a list of components as a member variable. By adding components, the game object gains functionality.

The decorator pattern works in the opposite direction and uses inheritance. You have a base class Drawable and some object X. You want to add functionality Y to X. You create a class Y which inherits from Drawable and will contain a Drawable component. Now to decorate X with Y you create a Y object and place X inside it. When you call y.draw() then Y will call x.draw() and afterwards do whatever decorations it wants to do on top of that. So the idea is then that code that used to operate on X can now operate on Y in exactly the same way, as if it were just an X - but you get the extra Y functionality. This way, you end up with a chain or linked list, which is not going to be efficient.

In terms of implementation you have your GameObject with a list of Components. Each update of the GameObject will call each Component's update function. GameObject should also have a function along the lines of bool hasComponent(string c) so that other objects can check its functionality. You would probably want components to have access to their owners, so update should maybe be along the lines of void update(GameObject* g).

_________________
Whatever the mind can conceive and believe, it can achieve

That's kind of how my GUI system worked. Very flexible but I ended up with chains of child objects. However, the problem I had with deriving everything from 'Component' was that I ended up having to use a message passing system to get wildly different information in and out of the controls. It got messy very quickly.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10