Structuring a game

My finals are over, waiting for the results now. Vacation has started, so here comes the game making.

The biggest problem I had starting development of my game is the software structure. Every time I programmed something of decent size I found myself stuck in a corner, unable to manage all the classes and variables that were made so far.

When asking my cousin, a student in computer science and electrical engineering, he came up with the Model-View-Controller (MVC) design. In MVC you divide your program in three types of components, each having seperate tasks. The model holds data, the view observes the data and changes when the data changes, the controller allows manipulation of the data. However, using the classical form of MVC requires that your model objects are observable. This means that every change of data sets off an event. The C# library doesn't have an implementation for observable objects and it didn't seem like using observables would give that much advantage in the first place.

Then I thought up a bastard son of the MVC design. Instead of using observables, I divided my program as follows: The model still held the data, the view draws whatever data there is, and the controller manipulates data in the model again. Though implementing this design smelled an awful lot of needless complexity, as Robert C. Martin tends to say. What I learned from reading his book about agile software design, you shouldn't abstract a function or class before you find yourself repeating the same piece of code (at least, something in that direction).

In the end, deviating from pattern to pattern did teach me a lot, so at least it was time well spent. I'll just stick to building monolithic classes for now.