Would using MVC to write a serious game be good design and a smart move, or is there another Design Pattern that makes more sense when dealing with this kind of software. And has anyone done a non-casual game using MVC? What was your experience?
I’m designing a game engine in objective-c w/Cocoa and it won’t use any of the Cocoa UI components, other than extremely basic i.e. create a full screen window and get drawing contexts. In engine work I’ve done before using 3D or 2D, most of the software that draws is very much married to the software that describes what to draw etc. The reason for this tends to be optimization (or it could just be bad design).
Abstraction is a double edged sword, it makes development easier, but can hurt performance. However a lot of modern games are GPU bound due to the pretty graphics. If you think that is true than what you do on the CPU is of lesser consequence as you will be waiting on the GPU to render a frame anyway. However most solo projects don’t get to the pretty graphics to a high enough level for this to be true, so you will likely still need to be somewhat careful.
This does not mean you can’t at least go halfway. In fact most games are now done in a pseudo MVC style, specifically an Update/Draw cycle is used rather than a trivial loop. Basically you have all of your game code in a separate method than your drawing code. Your game code updates the state of the game, then the draw code renders it.
This is especially nice if you are rolling your own physics (or other frame based) engine, as it allows you to separate the FPS from your update cycles. For example you can code your game engine to run at 60 FPS, and simply update multiple times between draw calls if you need to.
To summarize, you should always separate your updating and drawing code in a game, it is a simple step with minimal overhead that provides a good portion of the simplicity of MVC without the costs often associated with complete MVC structures.