MOPED Lessons: Introduction
Last post I mentioned something called ‘my MOPED design principles’, and I intend for this article to be a brief overview and introduction to each of them. I’ll be doing a full article on each of the five principles, going in detail and with examples from games I’ve played or have worked on.
Talking about MOPED is gonna take some context, though. I do software development as my day job, and MOPED is inspired by a set of principles from software design, called SOLID. I think the inspiration for the acronym is clear. SOLID is a set of design principles for writing code that is easy to change, maintain or expand. It’s a catchy mnemonic, and it works well generally, but it’s in no way foolproof. As with any set of guidelines/principles, it should always be looked at in context and applied within reason.
MOPED is a set of design principles I created for game design, and like SOLID, it’s meant to help with designing your games in a way that focuses on modularity and ease of change. So, without further ado, let’s look at what MOPED stands for:
Like I said, I’ll be doing individual articles on each of these principles, but for now I’ll only give a short overview of each.
Making games modular is very important for the extensibility and ease of modification of games. This is similar to the S and O of SOLID, which are the ‘Single Responsibility’ and ‘Open-Closed’ principles. Modularity is most often defined as having your system be composed of modules which are independent from each other developmentally, but work together in unison in the scope of the entire system. Having a reasonably-modular game allows one to develop the different modules in isolation without being worried about dependencies between them. It also means you can easily add or remove modules with very little to no ill effects on the rest of the system.
How do you optimize a board game? As opposed to software, there isn’t really any real ‘performance’ you can take into account, right? Well, the way I look at things, board game optimization is done through the rules. An optimized game is one that uses only as many rules and mechanics as it needs to function. And even within rules and mechanics, one can take care that there is no redundancy, and that the capabilities of the design are used to their full potential.
Basically, you want your game to expand out only as it needs to, and design it in a way that you either regularly cull the least used rules or edge cases, or take care that those don’t appear in the first place. And exactly like with software, don’t do premature optimizations, i.e. don’t try to optimize before you have any actual data (through playtesting) on whether something actually needs optimization changes at all.
Parameterization is a very simple, but very important principle to remember, since it especially gains more meaning during the development/balance part of your work on a game. Simply put, you want to have your game’s mechanics provide multiple parameters by which you could change things around. Those parameters can be anything, and are most usually numbers (e.g. cost, damage, value, etc.) or some kind of class (factions, suits…).
The key with parameterization is that while you should aim to do it, you should care not to overdo it. Too many parameters can make things too unwieldy when it comes to changes, and especially since parameters on the same game object are more often than not dependent on each other. Making a change in one could affect the rest, and also affect the overall quality of that object, be it cards, characters, game boards or anything else that can be parameterized.
Emergence is a key aspect of every single game. It is at the core of why games work to begin with. Emergence, i.e. emergent behavior is pretty much everything that comes as a result of a game’s rules and mechanics, but is not strictly dictated by the game.
Think about it like this: in chess, you have rules regarding how each of the pieces are allowed to move. But, nowhere in the rules of chess is any specific board state described, aside from the starting one. Every single state of the game emerges from following the game’s rules and mechanics, but those states aren’t explicitly defined everywhere. For example, if—like in chess—you have a rule in the game that dictates what the game’s starting board state is supposed to be, that state isn’t emergent behavior. However, the board after 3 turns of player activity tells a completely different story, one that is created solely by the players interacting with the game’s mechanics and interaction.
In MOPED, a game having high emergence means that the game is designed in a way that a lot of unique gameplay situations can arise from the existing rules. In essence, it is a check to see if your games are repetitive and if they allow the players enough creative freedom with the tools they’re given. Just as with optimization, try not to prematurely force emergence. It’s easy to add new mechanics to try and increase it, but those mechanics—and the overhead they create—can come back and bite you later on in development.
Finally, we have direction. And this is something that can do damage to designs quickly, if you’re not considering it as the project progresses. Simply put, this is about the direction you want to take the game in, the game’s scope, and more specifically, how well you can adhere to both.
Changing a game’s direction halfway through its development is fine when it’s intentional. Increasing or decreasing the scope is also fine, when it’s intentional. Starting to see the pattern here? The dangerous aspect comes when, for whatever reason, the game starts to slip away from the intended plan. It can be as simple as settling for a solution to an edge case that changes some aspect of the gameplay just enough, and then that can propagate to other parts of the game over time.
One of my projects, BossRush, which I mentioned in the relevant Sidequest, had a major direction issue. While the systems and mechanics worked eventually, and satisfied M, O, P, and E, none of the versions of that game ended up following the originally established direction. The game worked, but it felt wrong. And when dealing with games, which by definition work by invoking specific emotions in people, something feeling off might just break the deal. If you say you designed a game where the selling point is that you play as a leader of a giant naval trade empire, but the focus of the gameplay is on micromanaging the individual ships rather than the empire management itself, chances are the game’s losing (or lost) its direction.
Well, that’s pretty much it for the basic overview of MOPED. I don’t think I’ll start going into detail on these from the next article, but you can expect the deep dives soon enough. My goal for MOPED is to be something that people read, maybe remember what the acronym stands for, and serve as a sort of mental checklist during the design process.
Next time, I’ll talk about… something. Haven’t decided yet.
Still, nothing’s more certain than death, taxes, and me ending an article with a song. Enjoy!
This is InvertedVertex, signing off.