Drawing Board X: Moddability, Modularity and Backward Compatibility

Today's article was a little hard to categorize; I was thinking a bit more about modularity (which, if you've been paying attention, you'll be aware I never shut up about.) More specifically, I had some thoughts I felt I should record on how the kind of modularity we want to achieve could be accomplished from a technical standpoint. So, while I did eventually decide to file this under "Drawing Board," since the actual implementation is open to change, I also want to note that the underlying principles here are important; namely, that the game should be modular, that it should be easily moddable, and that it should be easy to upgrade without breaking older modules (in other words, backward compatible). One other caveat: In addition to the standard Drawing Board disclaimer, I want to add a further one that I'm not a by any means a software designer and what I'm talking about here might be laughably naive to a professional; If that's you, please chime in and set me straight, I'd love to hear some technical insights! Oh, and speaking of the Disclaimer:

IMPORTANT DISCLAIMER

This series of posts are not to be read as "official" ideas for the Metropolis Project, they are simply my personal thoughts about what some cool game features might be.  The final feature set for the game will be decided by the community and the development team contracted to build the game, and may not include any of these things. More details about the purpose of the Drawing Board articles can be found here.

There are two principles we want to satisfy when designing Metropolis. First, we want it to be composed of discrete modules that can be activated, deactivated, and replaced with ease. As a non-programmer, I find the easiest way to picture this is to think of each module as a kind of "black box"; a module reads some number of variables as inputs, runs them through the appropriate algorithms inside the "box", and spits out one or more variables as an output. But this doesn't happen in isolation: that module's output then becomes the input for some other module, which in turn outputs a different variable, which might then output another variable that becomes an input in the original module (thus forming a continuous loop that moves the game forward.) To use a more concrete analogy: say we have a module which calculates the crime rate. The module will read a number of variables: population, education, employment, police coverage, etc. Based on whatever algorithm the module's designer has constructed, the module will output the appropriate crime rate. The module for resident satisfaction would then read the crime rate variable as one input into it's calculations for the satisfaction rate; The population growth module, in turn, would include the satisfaction rate in determining whether the population grows or shrinks. That population number then becomes an input for the original crime rate module, completing the loop.

So far, so good. The tricky part is not so much in the modules themselves, but in how they interact: the variables that one module outputs have to be legible as inputs for another. Furthermore, that legibility needs to be maintained in the event of an upgrade or replacement of any given module. In our example above, say we want to switch to a new crime rate module; the numbers output by new module have to correspond to the output from the original. In other words, an output of "25.6" has to mean "25.6 crimes per thousand citizens," no matter how that figure is calculated. We can't change the output because any number of other modules might be depending on that output, with that meaning, to make their own calculations. A similar question applies when we address the issue of backwards compatibility. When a core module is upgraded, we don't want it to break every other module out there: the other modules need to know what to expect. The question is, how to standardize those inputs and outputs?

The first thing we can do is officially codify the basic inputs and outputs of the standard modules, so that everyone is on the same page as far as the general shape of the simulation. This is simply a matter of maintaining an "official" list of the various modules and what, at minimum, they should output (inputs are at the discretion of the module designer!) Once we start to depart from the standards, though (for instance, by creating more complex algorithms that need specialized inputs) we begin to see a new problem: more complicated modules require other complicated modules to function, and this creates a web of dependencies: "UberCrimeRate Module 2.0" might provide a more accurate simulation, but it needs to read deeper statistics than the standard module to do so; Thus a user might need to install "AdvancedPopulation 1.5" to get the necessary inputs. Fortunately for us, this is a problem that is pretty well understood; The game will simply need to have a "package manager" type functionality which identifies dependencies and conflicts when new modules are installed. Modules will need to follow a standard format in order to be installed, which will include a list of their dependencies.

The second principle I wanted to talk about is ease of moddability. Open source software can, of course, be modified by anoyone, but it's also important to make modification accessible to the average user: not everyone has the time, inclination, or skill to dig through the game code, make the changes they want, and re-compile the binaries, even if they theoretically have the access to do so. We need to make sure the average modder has as much of the game as possible available to change in a straightforward format. A great example of an indie game that does just this (despite being closed source) is the Space Empires series: Almost all the important variables that an end user might want to change (ship costs, build times, etc.) are contained in separate, ordinary text files, which list and describe each variable. The result is that almost anyone can tweak the game according to their preferences. I'd like to encourage a similar degree of moddablility for Metropolis. For official modules, we should make it a point to collect all the static variables for each module into a human-readable configuration file; Community-created mods should be encouraged to do the same.

Obviously there's more to think about on this score, but these are just a few ways we can make the game more flexible and enjoyable; If you have further suggestions or ideas, please leave a comment!