May 27, 2011

MVC and Games

It has certainly been a busy time for myself over the last few weeks. Changing jobs, moving in and out of the house, helping out some others with some work, starting a new job, working on a few hardware reviews, getting rid of people from my life, getting new friends, catching up with old friends, doing some work for my internship, taking care of a friends dog while they are away,... I could keep going. The point is, I've had time to take a step back and think about my whole approach. I've come to the conclusion that the great and wondrous MVC pattern is really bad for game development. I had a guy convinced it was the best way, but really, the V in MVC is only a small portion of the game which isn't very good. It just makes for a very bloated M and a reasonably large C.

MVC is great when the components are proportional, but is absolutely horrible when they are not. MVC is very good for action-response orientated systems. An interactive program or web interface is perfect for this as it is user driven. A game on the other hand is only partly driven by the user but for the most part a lot goes on the back-end and is based off of a clock. This difference means that you could use MVC, but it is becomes very messy because of the large number of uncertain situations of having multiple objects needing to know about others to figure out if they should be doing something or they shouldn't be. Games, for the most part, also have a global state. Are you playing? Is it paused? Title screen? In some menus? Etc. This really comes to me as you should have an overarching Singleton for the state of the entire game. Very rarely you will be in multiple states (I'm not talking about sub-menus).

Singleton abuse. It really is a bad thing, but for keeping track of the global state of a game, it is actually better to have than to neglect. Does it make testing harder? Only slightly because you can very easily use interfaces as a way to mask parts of a Singleton that your code should not have access too. Interfaces being the mechanism for accessing a Singleton are very power and drastically reduces the coupling. In tests you only need a set of mock classes which can easily be reused, since the Singleton is really only meant for keeping states and handling the construction/take down of states it makes it very effective for tasks that normally would require multiple loosely connected classes. Having the Singleton perform actions by calling Abstract Factories through a Facade for construction is very effective for 'loading'. 

With more time on my hands opening up... I think I might start investigation this idea. I'm setting up a few servers to use for source control and maybe I can get some people to work on something with me once I've figured out the basic ground work.

No comments :

Post a Comment