Modeling game data

MVC, or “Model-View-Controller” is a pretty hot buzz word in object-oriented programming circles. It’s widely hailed as a solid and robust application design pattern; however, like anything else in the programming world, its really only as good as its execution. If you build a good MVC, it turns into a solid framework to run your game on. But if you just hack something together, then you only make a mess. So, the best approach is just to understand some foundation principals behind the MVC pattern… the most central of which would be the data model.

So, The Model. First, what IS it? Simply put, it is a large structure of objects that organizes and stores all data within your game. Notice that I said “objects” and not “display objects”. One of the most common mistakes that I see made in Flash development is when a program is built utilizing the display as its core. By that I mean that pieces of data are assigned to various display objects, and then those display objects are arranged into a visual hierarchy that may or may not resemble the real structural hierarchy of the data that it represents. What happens then? All these pieces of potentially interconnected data –each attached to a display object– are isolated from  one another by forks in the display list. If one data element wants to work with another, then it needs to chart a path through the display list, or else use some hack solution like a static class accessor.

The best possible rule to observe while building a data model is: keep it entirely disconnected from the display. Think of the display like the skin of an apple. You can always peel the skin off to get at the real body of the fruit. However, when you sprinkle your data into your display list, you’ve essentially just made apple sauce. There’s no way that you’re going to cleanly get your fruit body out of there without bringing skin with it. This makes your core application dependent on the display list, which in turns hurts the scalability, flexibility, and reliability of your application. I note reliability because you’re really shooting yourself in the foot on debugging when you mix your model and your display. Both data and display will have their own unique errors, though a problem will not necessarily be obvious when you can’t tell if the problem is with the data or the display. Quote The Offspring: “You gotta keep em’ separated”.

When starting a new project, the best favor you can do for yourself is to build out your model without ever touching the display. When I kicked off the AS3 Lassie Player, it was a solid month of just building object structures that defined data holders, accessors, and organizers. In that time I never put a single graphic on stage. It’s kind of a backward way of approaching Flash as a technology – given that Flash has gained a huge amount of its popularity through the instant gratification standpoint of immediately getting to see pretty graphics do tricks. However, that temptation to go straight for graphics tends to be a drag in the long run given that your application suddenly seems to collapse under its own weight when it gets to a certain size and complexity (I speak from experience).  When taking the isolated model approach, I’m consistently amazed later at just how easy it is to build the display. All the data is just… well… there! Making graphics behave intelligently with game behavior becomes really easy when you have all of your data laid out nicely in an easy to access configuration.

Now let’s shift gears and talk a little bit technical. I find that the model is best served using EventDispatcher objects as the core class that is extended with custom data elements. Subclass EventDispatcher and build out a unique object with public members for every field of data that you want to store. I’d highly recommend defining all public properties using getter and setter methods, because that allows you to dispatch an event whenever a setter changes a data element… Again, this makes building your display simple: just have each display object subscribe itself to its corresponding data model, and have it update itself whenever its model changes. Suddenly, making things happen within your game becomes easy, because it’s just a matter of setting properties within your centralized model and your display magically reflects the update.


2 comments so far

  1. Double Dee on

    Still super excited about the progress of Lassie Adventure Studio. I’m glad you’re taking the time to build the core right.

    I can’t wait to get my hands on the new software!

  2. Michiel on

    I hope you can explain the controller setup and not in the way a oreilly does but from your own experience!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: