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