We’re gonna talk about video games.
Imagine you’re playing Mario Kart on a four person split screen. There are four Yoshis on the screen for each player. How many Yoshis should we model?
The obvious answer is four: there are four Yoshis on the screen, so there must be four Yoshis. The problem is that this answer misses something important, and fails to answer a critical question: what if there were no Yoshis on anyone’s screen right now? Does that mean there should be zero Yoshis? No, of course not, Yoshi can fall behind in the race and should still exist.
The real answer is there is only one Yoshi – one source of truth that dictates where Yoshi is, how fast he’s going, what items he has, and what he’s about to do. Fundamentally, all this means is that Yoshi exists separate from his representation to the user. We can organize our code to represent this by grouping our data about Yoshi in a single location.
Models as the source of truth
Models are used to encapsulate data. A Model stores data properties and serves as the ultimate reference in other parts of our game. In our example Yoshi, Mario, Bowser are all Models – they have a single state and source of truth that’s associated with them. With this distinction we avoid searching for information on multiple Yoshis or creating logic to determine which copy of Yoshi is the most updated version of our racer.
Models are isolated from the code that displays the screen to the user so while Yoshi may turn a corner and disappear from the screen, our game logic continues figuring out how fast and far Yoshi has gone. We decide what to show users through building Views.
Views as Lakitu
Views decide what to show the user. Each View is associated with a model, and decides exactly how that model should be shown on screen. We wouldn’t want to just show the user all the stats about Yoshi, we want to make it a cute green dinosaur in a cart that you can see and aim at – View’s make that happen.
You can have lots of Views for a single model. For instance, even though there’s one Yoshi there’s actually up to four Views associated with him! In regards to Views, four is actually the right answer. Our Model for Yoshi has only one location and one speed, but our View shows him in four different places on each screen and renders him going in different directions depending on where you
If we began to store information about Yoshi in the graphic, we run the risk of creating data inconsistent with our original source of truth. What if there are multiple Yoshi graphics? By separating the storage of data from the representation of data we ensure that all players see the same Yoshi.
Events as a Blue Shell
When Bowser grabs a blue shell and throws it, this is a global event that every racer wants to know about. A smart group of Views will have event listeners on its respective Models. Smart Views can listen to events from the Model such as a ‘change’ or ‘add’ event. As our Models pass these event notifications to our Views, the screen responds by showing the player a blue shell rushing towards first place.
Our method of drawing data becomes increasingly more important as we add online players to the race from Mario Karts game servers. Having one source of data ensures that every player has a uniform experience. As there is only one Yoshi, there should only be one tweet, wall post and chat message that our Views are listening to.
Libraries and Frameworks
Concise code lends itself to become more reusable and testable. Our clear sense of separation and organization allows us to write modular code that is focused on clearly defined tasks. Every library and framework implements this differently and it will take some exploring to find the right fit.