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.

May 2, 2011


After brushing up on some multi-threading I feel pretty good about it now. It's always interesting to find out more about it from looking at Java concurrency package. I also had to brush up on my C++ the other day too, I haven't had to seriously use it for a few months and its surprising how quickly it can slip on you if you don't use it all the time. With everything changing over for me I haven't had much time to work on the project, but after this week I should be able to work out some more. Currently, in the process of setting up a local git server, but haven't a few hick ups with the old laptop I'm putting to use. I have to say though, a server with 80GB of disk space just doesn't seem right. It is like saying I bought a new sports car, but without an engine. Either way once I sort out those issues all should be good to actually focusing back onto the project.