Component-based systems (part 2)

Next thing is how the components will interact with each other, defining that beforehand is important to have a consistent model. Usually, they should not do that, but what happens when there is a render component that depends on information kept in a spatial component, like the position.
It is quite clear to me that everything should go through the game object in a generic way, but some kind of dependency could not be avoided.

There seems to be two different ways:

1. Dependency on component.

 A component requests the game object for another component in its collection and access it directly.
The component dependent on the other should do nothing if it can't be found.

gameObject.getComponent(OtherComponent)

2. Dependency on property.

A game object is a property container and each component added to its collection registers a reference to where it holds the information. If the module is unloaded the properties should be unregistered too.
The names inside the reference class are going to have unique identifiers, to avoid name collision between similar properties registered by different components. "ComponentName.PropertyName".

gameObject.registerProperty(PropertyReference)

gameObject.getProperty(Identifier)

At the end I feel that both options are valid and are almost the same, the second adding a little more and maybe unnecessary complexity though.

- MR

Component-based systems (part 1)

As I previously described, the use of complex and big inheritances does not work for me, I need the system to be easy to change and not resistant to it, and that is what happens when you have everything tightly coupled (that is exactly what occurs with unmanageable class hierarchies). Extend classes when there is a good reason for it and to be honest, I believe in most scenarios functionality can be added through composition or aggregation.

The approach that I will try to apply in the game we are building is based on components, creating reusable modules that can be changed on the fly altering behavior of specific objects. Not to mention that each node in an external file could be mapped directly to a component, creating the best possible solution for games, a completely data-driven application.

Basically, the idea is to have a GameObject that acts like an empty shell and is only a collection of GameComponents. These components could be anything from rendering, controllers, pyshics, state machines... what the object needs to work.

I remember a great document I read some time ago from the GDC Canada that explained this in a very descriptive and accurate way. It also says that it is not easy to see the benefits right from the start.

At the end I think it is worth it and I will try to demonstrate that is the case.

- MR

At some point it always ends being composition over inheritance

Some days ago we realized that after a few months of development it started to be very hard to extend our game system to support the post-production and always changing requirements. We are using an MVC architecture, therefore we keep the concerns separated in a very efficient way, but there is a class explosion caused by a heavy use of inheritance for our core objects. We then decided to move static hierarchies to a more flexible functionality composition model, but keeping backward compatibility with the previous system is going to be a little tricky.

I believe we are going to end having two systems:
1. The current one, each time a new functionality was added, classes were extended and implemented using polymorphism to change behavior. Following MVC means adding a few more classes for each change.

2. The new one, the objects will be composed by behaviors that can be modified on runtime as needed. This approach adds more complexity and makes the code dynamic, also there are new things to consider, like data manipulation and message passing. My biggest worry is how this is going to fit withing an MVC architecture, but this is a lot more data driven and at the end we are making a content oriented game.

If we had time we could refactor existing functionality to new behaviors and clean up the hierarchies, but like always, that is very unlikely to happen ;)

All this stuff led me to the component-based approach very common in new engines like Unity and PushButton. That is the way I will go and I will post about that soon.

- MR

New blog about social gaming

Hello, my name is Martin and two years ago I started working in the game industry thanks to Globant´s  game studio called Luminous.
I was able to be part of the staff of Electronic Arts that developed the new version of the EA Download Manager and an internal DRM product shipped with games like Mass Effect and Dragon Age: Origins.
Then I moved into social gaming with Playdom,  building a store simulation game called Market Street on top of a flash engine created from scratch. The game is a big success in Facebook with more than 4 million users.
Two months ago I decided to join Vostu (a social game company that targets the Orkut platform) to gain more experience in game architectures and scalability amongst other things. 
We were able to successfully launch PetMania and we are starting to get viral traffic at a very fast rate!
In my current project I am having the pleasure of working with a highly talented team of professionals, learning new things all the time but better than that, I am enjoying it!

These blog was created to keep track of my investigations and hopefully It will help someone to solve particular problem domains in social game development.

-MR