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.

Definition

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 or add new content/systems to the game, 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.

Details

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 either consolidated into a single, larger module, or the overlapping concern can be cut out and put into a new, separate module.

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—if players always have to decide which modules to play with, the game might feel unfinished, like the designers couldn’t decide what options they wanted to put as defaults.

Volatility

When discussing a system’s modularity and components, it helps a lot to mention a quality/metric that helps us reason about how modular something actually is: volatility. A component’s volatility describes how many other components are coupled* to it, therefore giving us insight into how much work is required to change it.

*Here, coupling between two components means that at least one of them depends on the other in order to work correctly. With tightly-coupled components, changes to one require changes to the other in order to keep things working as they should. Loosely-coupled components, on the other hand, can be modified a lot more before related components need to be updated.

When a highly volatile component changes, it causes a chain reaction, requiring other components that depend on it to be changed as well. This is very bad for modularity: it means that changes cascade and propagate throughout the system, which not only violates separation of concerns, but is generally a big pain to deal with.

While high volatility is potentially dangerous, it’s not always fully avoidable. Often, a system will have some ‘core’ component that is tightly coupled to most—if not all—other components. The core system of a game is volatile by nature, since all other components are built around or on top of it. Changing the core leads to pretty much changing the game itself, so it makes sense that even small changes will take a lot of work and cleanup to implement properly.

Generally, if you want to keep your system as modular as possible, try to keep volatile rules and mechanics down to a minimum. If the intent for the system is for it to be easy to expand (e.g. card games), then volatility can both limit design space, and make testing more difficult. On the other hand, if the game has a pretty stable/fixed set of features that won’t really be changed or expanded upon, volatility becomes a lot less important once the design is firmly set in place.

Benefits

• 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’—errors and inconsistencies 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

Costs

• 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

Examples

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.

That’s not to say that the possibility is completely gone, however. An important thing to take note of with expansions is how much they expand the core game as opposed to how much they try to change things from it. Now, since physical games can’t really be updated the same as digital games, fixes really only come in the form of errata, re-releases, or through expansions. Expansions like this can cause the core rules to become tightly coupled to the newly-added fixes, and the game+expansion basically becomes the core game from then onward. This is something to keep in mind when trying to push some core rule updates with an expansion.

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 more-or-less constant due to SoC, because the players are never concerned with card mechanics that aren’t currently active in the match they’re playing.

As a specific example, I’ll use the Storm mechanic. The important thing one needs to know about it is that cards with Storm 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 ‘storm count’ rule is contained within its own optional module that the game (and more importantly, the players) cares about only when cards that are part of that module are used. 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.

Conclusion

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.