Focus on content and develop tools

I believe those are the key points to take in consideration when building a social game.
The first time I developed a game for social networks I did not have knowledge of what the industry needed and I made two big mistakes:

1. Adding content to the game was HARD. That was because my focus was never the content but the functionality. We were in a hurry to deliver on time and we succeeded on that. We didn't have any problems until the production phase came. Adding content required a lot of effort and most of the times engineering work. We couldn't move into making cool new things for the users because we were stuck supporting the integration of content. Going into production should be a thing to celebrate, shouldn't it? Well... that was not the case, only because adding content was HARD.

The game is only an engine to run content configured by non-technical people.

2. The other mess was that everything had to be configured manually. Why should product team know about implementation stuff like XML files and edit it directly? Creating tools that expose only the information to be configured by product is crucial to make life easier for them (and for you unless you enjoy being asked for every little change needed). The tools are an asset of the company, and can be used in every project if they are generic enough. They can help defining an integration workflow and to assign specific responsibilities to the team members of the different areas.

Dedicate time for making tools to handle the content and educate people on using them.

- MR

Results so far

I joined the engineering team that is building the core commons library to be used in all the games of the company. That was my big chance to sell the idea of entity systems over normal OOP. I created some prototypes and proof of concepts and little by little I was able to demonstrate that this change was actually a very good idea. I understood how important it is to go one step at a time, developers accepted the change progressively, but you need to show results.

At first the design was simple and the benefits of making this change were not clear enough to justify using entity systems, but after a few iterations it was so easy to extend, modify and add new functionality that everyone were completely on favor of using it.We still have some architecture issues to resolve, but it is working really good so far.

At this point I was able to implement a good design thanks to open source projects and discussion forums:
- Game objects and Game components
- Entity managers
- Messaging system
- Shared properties
- Component families
- Deferred disposal

The biggest problem that we are facing right now is that we only implemented game objects for only a subsystem inside a bigger system, meaning that we are mixing architectures. Try to avoid that as much as possible, handling an entity system from outside could be extremely difficult if you don't provide a simple interface or a facade to simplify access.

It is not possible to completely decouple the components in the context of the game, but that is not that important as long as the library components do not depend on specific game implementations.

- MR

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