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