Recently TribePlay Game Development started a new client game project using the MVC model in Actionscript, which is a software design model that has been widely accepted as the model that incorporates all software design’s best practices. It in short revolves around dividing code into a triad, Model voor data, View for anything you see on the screen and Control for controlling. Control can only be indirectly reached by sending messages. Yet one of our employees got me thinking as he asked, why not just program using interfaces instead of using MVC?

An interface in a way decouples the internals of a piece of code from other code needing to talk it. Thus also creating the decoupling the control tier creates.
Generally spoken data and control should not be together, which is what would happen when just using an interface. This way we cannot easily use any other data with our control code as it would be behind the same interface. Many projects don’t change their data that much, particularly game applications. So what else?

By sending messages instead of directly calling on the interface you enable other controllers to respond to these messages. This moves the responsibility of acting on certain events to the controllers themselves instead of the caller who simply requests something to happen (it could be just a button!).

Another important thing, benefits do not only come from reusability but also and probably more importantly from readability. The also an extended discussing on this topic on this webpage to the questions “Should you sacrifice code readability with how efficient code is?”. The model and control create a conceptual border between code related to data and code related to control; making the code much more readable.

The second thing he didn’t quite get was why bother with all this as it makes the program a whole lot heavier with all the events flying around to communicate between the M, V and C. Cairngorm uses a central event system to communicate between MVC.

In general the events will not slow down the application really, as in the places where you would need events you would otherwise use code to check for all the changes and notify others through normal function calls having also their overhead. Even if it does slow it down, you will generally not even notice it in client side programs as CPU power there is superfluous and the most time is spent rendering graphics and not processing your code. Even if it causes you problems in terms of performance you can easily adjust things to make it faster if really necessary.

I think this is a good moment to finish with a statement I think every programmer should take to heart. I use to tell it every new flash programmer at TribePlay game Development:

Quality of code largely lies in its readability. Performance is nothing if your code can not be (re)used by others or understood by others.

In addition to others:

Programs must be written for people to read, and only incidentally for machines to execute.-Abelson & Sussman, Structure and Interpretation of Computer Programs

Make it correct, make it clear, make it concise, make it fast. In that order.-Wes Dyer