MVC and Games
This is a little bit random, but since I’ve been getting into making my own games lately, and since Miguel mentioned he was using “model-view-controller” (MVC) the other day, and since as a “trained software engineer” I should have known what that actually mean, I’ve been looking into the MVC approach to software creation.
In short, it’s a way of developing your software in a kind of modular way that separates out the core concerns. Specifically, you keep separate the underlying model (e.g. how the simulated world of a game runs, the numbers etc.), the view (the aesthetics of the game, how it represents the underlying model on the screen), and the controller (the input to the game, how the player is able to influence the model). It’s all very orderly and sensible and not something I’ve ever given much thought to.
But since it got mentioned, I’ve found it quite compelling. Specifically, it serves as the jumping off point for two game design ideas I’ve always found quite appealing. Both the View and Controller components in MVC are meant to be essentially swappable and independent – you can plug different views into the same model (essentially serving as different visualisations of the same thing) and different controllers into the same model (essentially serving as different ways of manipulating the same thing). This idea of interchangeability is really intriguing.
If you make a game premised on multiple Controller components (as I’ve started doing over the last couple of days) you’re essentially producing something which can be played with multiple forms of input. This already exists to a certain extent, of course, with mouse input, keyboard input, joystick input, etc., but if you make this the central premise of the game you can do something interesting, I think. The same game can feel radically different if your mode of control varies, and the profusion of interesting game input modes (from Mavis Beacon to Canabalt to Track and Field and so on) suggests that there’s a lot of choose from. This is the line I’m pursuing right now – more on that when I actually get a prototype running that doesn’t look like a glorified bar-chart.
If you make a game premised on multiple View components (as I also want to do), you’re producing an underlying game engine/system which can be seen in different ways. This relates to Ye Olde Ludology argument revolving around the idea that changing the aesthetics of a game doesn’t actually change the game itself – it doesn’t matter if Pacman is yellow or pink, it doesn’t matter if Nico Bellic is a nicely-rendered dude or a floating rectangle, the game remains the same. If you make a game that literally plays with this, then you can test this theory and potentially do some really interesting things in terms of continuously recontextualising a player’s inputs as they play. It could be as triviailsing as Mary Flanagan’s lay-off game that essentially reskins Bejeweled, or, hopefully, much more.
Anyway! Those are some of the thoughts that have been occupying me post GuruQuest. Impressive, since I’m not even living in a post GuruQuest world, given that I haven’t released it yet. But that day is only slightly over the horizon.