MOPED Lessons: Modularity
Alright, let’s get this show on the road. This is the first of the detailed posts I’m going to do regarding MOPED (link to the outline/concept here). As the title suggests, we’re gonna be tackling the topic of modularity in games. To that end, I’ll be splitting this article in a few distinct sections, and all of the other MOPED articles are gonna follow the same layout.
So, without further ado, let’s get started.
Modularity – the quality of being composed of separate functionally-distinct parts/modules, which allows a modular system to easily scale and be modified with little issue.
Modularity in games, whether we’re talking tabletop or digital, is a concept that is completely independent of any specifics of the game. The main goal of designing a game in a modular way is to allow the designers to change things or add new content and/or systems to it without the risk of those actions creating large-scale cascading changes in other areas of the game. A modular game, like modular software, can have its parts changed without ‘damaging’ the other systems and ultimately reduces the amount of testing that needs to be (re)done after changes, additions, or removals have been made.
There are two sides to each coin, and modularity is no exception. To go further into details about the why and the how, it helps to divide it into 2 distinct types: Separation of concerns and Optionality.
Separation of concerns (SoC) is a concept borrowed from programming, but it’s general enough that it can be applied anywhere. Simply put, it states that each module should take care of one specific task. No more, no less. Modules can cooperate, but if that cooperation leads to overlap of concerns, they can be instead consolidated into a single, larger module in order to stay true to the concept. Separation of concerns is what grants modules most of their power. When each module has its own responsibilities in the context of the game, you don’t have to worry about it potentially causing havoc in parts of the game that it’s not concerned with. There can also be communication between modules, but make sure that it’s through specific mechanics that are designed strictly for that communication, rather than introducing additional overhead in the existing modules.
Now, absolute 100% SoC is neither achievable nor actually preferred most of the time, mostly due to the fact that systems in a game are a lot more interlinked through the rules than it might seem from a purely theoretical standpoint. As always, the gameplay itself will ultimately reveal how well a game holds together.
Optionality is the second part of the story of modularity in design. It is a lot more straightforward, but equally as important as SoC. The quality of a mechanic being optional is a very important one to consider when attempting to design a modular system. This is probably the primary thing people consider when the word modular is mentioned—being able to add or remove things from the whole, while still maintaining functionality across the board.
The key to designing optional modules is being aware of how the presence of that module in the larger scope of the game—or the lack of it—will affect the flow and feeling of the gameplay. The most obvious example of optionality is game expansions or alternate game modes. There, you already have the core game features, and the expansion is something you can use or skip, and the game will still work regardless of your choice.
Optionality in core mechanics is a lot more difficult to pull off, though there might be times where you want that. Remember that if something is optional, it doesn’t have to mean that it’s less important, especially if it’s an ‘enabled by default’ type of module—it’s still a part of the game. Also, be aware that players can get decision paralysis even on a meta-game level if there are too many optional parts to the game—it might feel incomplete, like the designers couldn’t decide what options they wanted to stick with.
- Easier development—modules can be tweaked separately
- Easier testing—the game can be tested with various setups, with any number of the different optional modules included or excluded; test only with the modules you actually modified
- Easier ‘debugging’—bugs in the game can be easier to find because they would more often than not originate from a single module
- Innately forces modules to be below some complexity threshold, when SoC is properly executed
- More design work is required to pull off properly
- Inter-module bugs can be very rough to take care of; there’s always the risk that you fix something in one module, only for things to become worse in another
- Innately forces modules to be below some complexity threshold, and going above that can mess with SoC
- Optionality is a double-edged sword—not everything that can be optional should be optional; things can break easily if something goes wrong with this
As far as modularity goes, the most direct example, and by far the most common one is regarding expansions in games. This is due to the fact that expansions are an explicitly modular context, both in optionality and separation of concerns (albeit the latter can vary in efficiency between games and expansions). The big takeaway from expansions is that—because they’re designed on top of existing full rulesets—there is rarely a possibility of them retroactively messing things up with the existing implementation.
For a second thing, I’m going to turn to my eternal source of design examples—card games, specifically Magic. Card games are insanely modular, which mostly boils down to mechanics being tied to individual cards or groups of cards. In a game with over 20 000 unique cards, the complexity of the game is maintained at about the same level, because the players are never concerned with card mechanics that aren’t currently active in the game.
As a specific thing, I’ll use the Storm mechanic. The important thing one needs to know about it is that cards with this mechanic care about the number of cards played before them in the turn. Unless you’re playing with or against cards with this mechanic, there’s (in the general case) no reason in the game to track that number. The same can be said for most mechanics in the game, which conveys the essence of modularity in both critical aspects of it.
Golden Hammer Rating
So, the final point I want to make before the conclusion is giving Modularity a Golden Hammer rating. Now, the name of this is taken from the law of the hammer, which simply put is ‘If all you have is a hammer, everything looks like a nail’. More specifically, the version of that which, paraphrased, is something like ‘When you have a shiny/golden new hammer, everything starts looking like a nail’.
This rating basically states how easy this principle is to overuse, either when you’ve just heard about it, or even afterwards. When you have a new tool at your disposal, it’s easy to start trying to apply it to every problem—regardless if it fits the job. The core with these things is to know how overuse looks like, and being able to stop yourself from reaching that point.
GOLDEN HAMMER RATING: 3/5
So, Modularity is halfway up the scale for this. It might be tempting to try and retroactively make things modular where they aren’t, or maybe trying to consider modularity first when starting a new project. But, there is a definite danger to overusing it. Separation of concerns is something that should be applied with caution, because a lot of times it’s gonna end up being (near) impossible to do by the book. If you have a system that works well as-is, even if it doesn’t score many points for modularity, you don’t want to potentially make things worse just to go after some arbitrary principle.
Remember, these are suggestions, not rules.
OK, so that’s M done. As far as OPED goes, we’ll get there in due time. Even though I have these principles and concepts outlined and mostly know what I want to talk about regarding each, game design is a never-ending process of learning more and more things. So, with that in mind, these articles are probably going to take a bit longer to write than others, and are also more prone to retroactive edits and additions, as I gain more insight about the individual parts of MOPED.
Next time, I’ll be doing a Sidequest related to taking and acting on player input, told mostly through personal anecdotes. After that, I expect at least another main series article before the next MOPED thing.
As always, stay safe out there, have fun, and take things easy. Here’s a tune to help with the last bit:
This is InvertedVertex, signing off.