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.