MOPED Lessons: Parameterization

It’s part 3 of 5 for the MOPED principles, and today we’ll be looking at that old crowd favorite: Parameterization. Just the word itself is a mouthful, and considering the amount of things that can go wrong (or right) when it comes to parameterization, we’d best start dismantling this mechanical monstrosity.

Definition

Parameterization – The action of creating/exposing modifiable parameters that control the qualities of objects and rules in a game’s system.

Parameterization is a thing we usually take for granted in all types of systems, and don’t actively think about it very much, if at all. However, it’s an essential part of game design, especially game development/balance. As such, being aware of how you’re doing parameterization in your designs can really help you get through the entire design process easier.

Details

Let’s start by going over what a parameter actually is. To put it simply, a parameter is a modifiable value that affects the capabilities or effectiveness of a game object or effect. The key word here is ‘modifiable’; if something’s just a static, unchanging value, it doesn’t really count as a parameter, at least not in the context we’ll be using. Do note that things don’t have to be modifiable mid-game, just that different possible values for the parameter exist.

Parameters are everywhere in games. They’re so ubiquitous, that—like resources—we don’t usually give them much thought when playing the game, except if something brings it to our attention. These values are first and foremost a thing for the designer to care about, and for the players to more-or-less take for granted.

The majority of parameters in games are most likely to be numbers, since most parameters are quantifiable values. Numbers are the backbone of balance in games, since they’re the easiest way to change the power of something without changing the effect itself. There isn’t that much to say about these since we all implicitly understand them. It is worth noting that since numbers can mean many different things—from costs, to effect power, to minimum/maximum restrictions—it’s very important to have a clear visual distinction between all the numeric parameters on your game pieces. This is more of a graphic design problem, but just taking a step back and considering things like position, coloring and labels for the parameters can go a long way to preventing ambiguity with numbers.

However, aside from quantity, there are often parameters that represent some quality. These are what we’ll refer to as classes. Classes are usually denoted by words/phrases, and represent a group an object/effect belongs to. These usually include object (sub)types (think factions, teams, colors etc.) that have functionally unique properties, but also general ‘marker’ classes, that may or may not have any mechanical meaning of their own, but are used in the context of other effects and rules*.

Classes don’t necessarily have to be denoted by words, and things like specific colors and symbols are often go-to alternatives. Ultimately, the main difference between numeric parameters and something like classes is that a class is binary: an object either belongs to it or not, whereas with numbers it’s most often a sliding scale of magnitude.

*These are often colloquially called ‘tribal’ effects/mechanics. For example, a ‘Goblin tribal’ card in Magic would be a card that cares about playing/using other cards that are part of the ‘Goblin’ class.

ParaMETArs

Now that we have a reasonable idea of what parameters actually are, we can take a look at metagame parameters.

These are parameters in your game that are related to the metagame, the set of interactions that are still related to the game, but aren’t part of actual gameplay. The metagame is often referred to as ‘the game outside the game’. In card games especially, the best example of metagaming is deck construction. In games that feature some kind of deckbuilding that isn’t a main aspect of the gameplay (i.e. the game isn’t a deckbuilder, though I’m sure there are exceptions to this), designing and tuning your deck is a key part of the whole game experience, and as such needs its own set of developmental and design knobs to turn.

To continue with the example of card games, probably the most well-known metagame parameter is rarity. Card rarity is mostly a feature of TCG/CCG style games that have randomized (booster pack) distribution models, and because of that, it’s more a parameter of the game as a product, although it still affects deck construction. Higher-rarity cards are almost always stronger than lower-rarity ones, and this is especially relevant in game modes like booster draft. There, players only have the cards they open from the boosters at their disposal to build a deck with, and because boosters always contain a specific number of cards of each rarity, the overall balance of the draft format can be regulated by putting the right cards at the right rarity.

There are other examples of deckbuilding parameters: take the aforementioned tribal mechanics. In Hearthstone, for example, your minion/creature cards can belong to a specific tribe, and other cards have effects that either affect only minions of that tribe, or have stronger effects when affecting minions of that tribe. This is a simple class-type marker parameter that doesn’t really do anything on its own. However, both from a design and user standpoint, whether a card belongs to a specific tribe can make a really big difference on its overall usability and/or power level. The card would probably still have the same effect without belonging to the tribe, but then you would remove a lot of synergies and combos that other cards could have with it.

Another deckbuilding meta-parameter in card games is number of copies of a card. Android: Netrunner has a numeric parameter for its deck construction balancing needs. In that game, you play a specific character card that belongs to a specific faction. You can then have as many cards as you want of your faction in the deck, but there’s a limit for how many off-faction cards you can use. Netrunner accomplishes this by using 2 parameters: each character has an Influence limit (the parameter’s in-game name), and each card that goes in your deck has an Influence cost. Off-faction cards count towards the Influence limit, and you can’t have a valid deck that goes over it. This way, it’s reasonably simple to dictate how big a commitment a card is to put in your deck, and also how well each character can make use of off-faction cards.

As a final example of metagame parameters, we can take that old crowd favorite: number of players. This is a parameter that becomes a lot more obvious when your game has specific content that would be best played by a specific number of players. A board game might, for example, have 2-player, 3-player, and 4-player maps, where each type either works best with that number of players, or works only with that number of players. As any parameter, as the game changes and development progresses, feel free to try changing it around and seeing what happens. Maybe your 2-player game would work better as a 2v2 4-player game or vice versa. Always take some time to mess around with these sorts of things—it’s literally why they exist in the first place.

Design space—the final frontier?

We can’t really talk about parameters without mentioning design space. Design space is inherently tied to parameters, since design space is a measure of how many variants on a mechanic/effect one can have in their game, and those variants are easiest to do through changing parameters. Often, the simplest way to increase design space is to add parameters, or change their granularity. But, not all design space comes from parameters. Non-parametric variants of effects are just as valid, although they might be harder to initially come up with, and need an approach to balance that is different to tweaking parameter values.

I’ll say more on design space when we look at Emergence in the next MOPED article, but for now, the main thing to keep in mind is that while more design space is generally better, design space can in itself be one hell of a golden hammer™.

When to parameterize?

So, with all this said, the million (crowdfunded) dollar question seems to be: If adding parameters is so dangerous, when is an actual good time to add them? Unfortunately, the answer to this, as most things in game design, is a big, fat depends.

But, some cases are much better than others, so in no particular order, let’s go through some of them:

• A mechanic/effect needs to be balanced while remaining functionally unchanged. Parameters can help you vary the power of each individual occurrence separately, allowing for much easier, and more modular balancing.
• You want to nudge players towards a certain strategy that you built into the game. Class parameters and the whole ‘tribal’ concept exist for this reason. While it can run the risk of being too linear (i.e. having too few viable options for a given class), it helps signal to players that a group of things work together well. If done non-intrusively, it helps players feel smart about their decisions; on the other hand, if it’s too forceful, it might start to feel restrictive.
• You want to increase design space. Same as the first example, more parameters innately grant more options to mess around with and create more variants on existing things.
• You want to split a single parameter into multiple parameters. This is a very simple and straightforward method for adding granularity and making things easier to balance, although it has its fair share of potential risks and things to consider before attempting. How many parameters should the original be split into? Should those parameters be completely independent from each other regarding their values? What’s the best way to ‘translate’ the original parameter’s value into the new values etc.?

These are far from the only valid reasons to parameterize, but they can work as good rules of thumb for when you’re stuck trying to decide what to do next. Always try to weigh the benefit of a new parameter against the cost of introducing it. Speaking of which…

Benefits

• Increased design space—every parameter you add allows you to create more variations of existing effects and/or create completely new ones.
• Easier changes—if something is parameterized rather than set in stone, changes are a lot easier to do, and iteration is a lot quicker.
• Higher level of control—depending on the amount of parameterization, you can tweak things at different levels of granularity; also, since values for parameters are unique for a specific game object, you can change individual objects easily without worrying if and which other objects would be affected.

Costs

• Increased design overhead—each added parameter makes it harder to reason about the game pieces/effect and especially their balance.
• Increased tracking—this one applies to both the designer(s) and the players: the designer will have a harder time tracking the changes and power levels during design and development, and the players will have more values to track during the course of gameplay.
• Cascading changes—most parameters suffer from tight coupling, since they directly describe characteristics of game objects, and as such adding/removing those parameters (or sometimes just changing their values) can require a lot of other things to be rebalanced and/or revamped.

Examples

As an example of parameterization, I’ll again turn to that old faithful—Magic: the Gathering. Specifically, we’re gonna dissect a MtG card and see what makes it work.

Here we go, a random creature card (the choice of card type is intentional, by the way, since we have more parameters that way). Let’s go top-down and take a look at each parameter one by one.

• Card name: The first thing players usually read when looking at a card is its name. This is a very important parameter, both from a gameplay standpoint, but also when it comes to tracking and ease of recognition for the players. This is a textual parameter, rather than being one of the aforementioned numerical or class parameter types, and this type is mostly used for this kind of value: names, titles etc. Because in MtG each card is uniquely identified by its name, it’s a must-have for the game to work properly.
• Card cost: The symbols to the right of the name indicate how much of the game’s resource (mana) you have to spend in order to play the card. Since the only cards that don’t need a cost to play are the resource cards (they also kinda have separate play rules), this parameter is the absolute bread and butter of card balance in this game. It’s very granular, having an absurd number of possible combinations (any number + any combination of 6 standard mana symbols + a bunch of rarer/more specific symbols), which means that fine-tuning a card’s cost is not only possible, but also encouraged in the context of the game’s development. The different resource types alongside the ‘generic’ number cost make the cost a composite type of parameter, which gives it its flexibility.
• Card art: While it might not seem like it, art itself is a very important parameter in games. While it’s never really functional as part of the gameplay itself, it is absolutely 100% useful for the sake of tracking. Recognizing things at a glance, and even just being able to distinguish between game objects quickly are crucial factors for a smooth gameplay experience. Try playing a game of Magic with all the art covered by a sticky note and you’ll see how horribly tedious tracking the things in play becomes.
• Card type(s) & subtype(s): A textbook example of class parameters in action, there are 8 card types, 4 ‘supertypes’, and more subtypes than makes sense at this point. The subtypes are tied to specific types within the game’s rules, and while most of them don’t have rules meanings on their own, they’re a crucial part in creating the game’s ‘tribal/archetype’ strategies. Semantically connecting cards that are designed to work well together helps guide players in the process of deckbuilding. Things can have their card type/supertype/subtype changed during gameplay, which makes for a lot more possible options, and gives players more ‘puzzles’ to try solve when coming up with unique strategies.
• Card rarity: One of the abovementioned metagame parameters, rarity in MtG is mostly used as a way of regulating the complexity and power of cards. This is primarily done because of the game’s randomized-pack business model, but it also has an impact on both design and gameplay. Since rarity acts as an upper limit to complexity (and through that, power level), deciding the rarity of each card matters a lot, in order to properly fit with the rest of the card pool. I also mentioned how rarity’s treated in the draft game modes in the paragraph on meta-parameters above, so that’s also a major thing to consider.
• Rules text: The actual thing that makes the cards work. It’s technically a parameter, even though the size and scope of it might have some people not consider it as such. Effects in rules text have their own parameters, and so, trying to formalize things too rigidly here is probably more trouble than it’s worth. It’s variable and affects the characteristics of a game object. In my book, that’s more than enough to fit the definition.
• Power/Toughness: The box on the bottom-right contains these two parameters which are specific to the ‘creature’ type in the game, hence why I chose this type for the example. Couple these 2 numbers that have a pretty wide effective range with the cost and rules text, and you can see why MtG’s design space is absolutely massive, even when just taking these things into account. And also why balancing these things is so tricky most of the time…
• ‘Set info’ parameters: These are pretty much only ever important from a collector’s point of view, and include the name of the artist for the card’s art (PROTIP: always credit your artists, if not on the cards themselves, then at least somewhere pretty obvious/visible), the 3-letter set code for the specific set the card’s from, and the ‘collector number’, i.e. the card’s position in the set’s order, in this case 24/180. Things like this have no effect on the gameplay, but I chose to put them here to kinda complete the picture of the cards as physical game objects.

Golden Hammer Rating

GOLDEN HAMMER RATING: 5/5

 

We got ourselves a Golden Hammer™ high score! That is definitely not a good thing though. Parameterization is extremely easy to overuse and, as such, tends to get overused extremely often. It’s easy to create a new parameter when you feel like you’re running out of design space; or when you don’t want to reimagine some effect, a common ‘fix’ is to just add a new parameter to it so you can regulate its power.

There isn’t some inherent problem with using parameters: in a way, parameters are design space. But, each parameter added to your game’s rules creates a lot of potential dependencies. If you add a new (global) parameter, you’re going to want to have things care about it, both from a rules and content perspective, since things need to be tied together. Unused parameters are just garbage that’s cluttering up your game.

Oh, and there’s the whole aspect of balance and testing. I cannot stress this enough: every new parameter creates massive developmental overhead. Add a new number to your cards, for example, and not only will you have to update all the existing cards to have it, you will also have to retest every single one of them, even if they were tested and balanced well enough before the change. While it’s true that parameters are the knobs you turn to balance your game, having too many knobs can quickly lead to a tightly-coupled mess in which you can’t be sure exactly which parameter is the cause of some specific pain.

tl;dr Be careful with parameterization. Don’t be afraid of it, but take things slow. Remember YAGNI? Make sure that each parameter you have is actually necessary and important in the grand scheme of things. Both you and your players will benefit from it.

Conclusion

This was a long one… We’re past the halfway point on our tour through MOPED, and things are gonna get a bit more…abstract from here on out. The remaining two principles, Emergence and Direction aren’t as tangible as the first three, so writing about them is definitely going to take some finesse. Though, we got this far, so no stopping now. There are some non-MOPED things to talk about on the horizon, and they’re no less important than these principles.

Till then, keep on chasing said horizon. The song might be called ‘Dark Days’, but there’s definitely a bright future ahead.

This is InvertedVertex, signing off.