Design Goals II: Modularity

This article originally appeared on The Next Generation blog at Simtropolis.com

Following on from the previous post, I'd like to begin introducing some more specific goals for the game's design. I want to look at these goals from a holistic rather than a technical point of view: Rather than trying to decide on an implementation at this point, I think we need to set some guidelines for what the game should be, or what qualities it will have. As I said before, I don't think any of these are too controversial; but it's important to make clear what the highest priorities are when the game is designed, and let the rest of the decisions follow from those.

So, let's start with modularity. It's important to strike a distinction here between saying the game is "modular" and the similar-sounding and related "moddable". "Moddable" merely implies the degree to which a game can be modified; as an open source project, the game will automatically be infinitely moddable, so that doesn't really apply here. Modularity, on the other hand, is being designed for moddability. Software with modular design isn't created like a sculpture carved out of a single stone, but like a Lego building, with discrete pieces snapped together to make a whole. The sculpture can be altered, but it's going to be messy and difficult; with the Lego building you can take off the roof and switch in a new one quickly and painlessly. A widely familiar software example would be a program that uses plugins; such software is able to add and remove discrete functionalities easily without re-writing the entire program.

To look at some more game-specific examples, adding or removing custom buildings would be a basic kind of modularity (SC4 already has this, of course). Or, it could apply to the simulation: If someone wanted the crime/police simulation to work differently, they could simply replace the relevant module without having to alter the basic engine. Or, if someone wanted to add an entirely new layer of simulation, they could do so without breaking the existing game.

As I said, I don't think there's any argument that this is an important feature for a new community game; but I wanted to start with this one because I believe it's actually the most important design goal, which, if done well, will enable almost all the other design goals to be accomplished. If modularity is a first principle for every aspect of the base game's design, the software will retain the flexibility to adapt in any direction the community wants to take it.