MOPED Practice: Optimization tidbits
Time for some more MOPED. This time, however, we’re not doing a deep dive into a specific principle (the MOPED Lessons series handles that). Instead, we’ll talk about specific techniques and/or details related to Optimization. These are techniques learned from experience that help smooth the flow of gameplay and reduce overhead for the players.
Local vs global optimizers
Over the course of playtesting different games, each with their own level of decision complexity and analysis paralysis, I’ve noticed that players can be grouped in 2 different categories depending on their approach to decision-making: “Local optimizers” and “global optimizers”.
The former prefer to think more on the spot when making decisions, favouring short-term plans and/or goals, and just generally ‘wing it’ a lot more often. On the other hand, global optimizers prefer to consider as many options as possible before making a decision, and try to predict how things will cascade from that decision. While the ‘global’ optimization is generally the better approach, especially in games like chess where there’s no variance involved, this is more about optimizing the game feel rather than balance.
A larger decision space affects the 2 types differently: when decision complexity increases, local optimizers might feel pressured to think ahead further than they usually would, and could easily get stuck that way; on the other hand, more possible options mean that global optimizers have an even harder time and would take much longer to go through those options. Introducing new actions can easily lead to a combinatorial explosion if left unchecked.
Generally, a game will fit one kind of player better than the other, but that’s not to say that it can’t be fun for both. Sometimes, the same player will optimize locally in one game, and globally in another. That said, designers should try to figure out what archetype is more prevalent among their target audience, and try to fit the game’s decision-making to them.
It is important to ask players about their thought process during the game. Try to ask questions that can help you uncover what the players feel the biggest decision-making points are, and especially if the 2 types of optimizers agree on them. This can help you figure out possible bottlenecks that mess with the game flow because of analysis paralysis. Generally, you should avoid questions like ‘do you feel like the game would be smoother if X were changed to Y?’. Questions like that might accidentally cause players to skew their perception of the mechanic/rule in question, adding unwanted bias to the data.
In my opinion, optimizing the game for a specific type of optimizer makes for a better design overall. However, one should generally try to always reduce/smooth out decision complexity across the board, as this would equally help both types of player. Either way, try to keep the decisions straightforward, and the (inevitable) AP to a minimum.
Timestep size and interactivity
In simple terms, a game’s timestep size refers to how many actions a player can do before they have to pass agency to another player. In essence, it’s how long a turn lasts, though I use the term ‘timestep’ since it’s a bit more general, i.e. independent of how a game’s turn/round/priority structure works.
In general, the smaller the timestep size, the more interactive the game is, since there’s more back-and-forth between the players. If a player can only do a small amount of actions—or, on the extreme end, a single action—before it’s another player’s turn, that granularity makes it so that the other players can respond to the action immediately. Games of this type tend to be more cutthroat, since there are a lot of opportunities for other players to disrupt your strategy before you can act again. On the other hand, games with a larger timestep size tend to be less interactive, which can lead to more swingy turns.
Picking the right timestep size can affect not just a game’s flow and balance, but also its overall complexity. Timestep size is often (but not always) proportional to a game’s decision space and decision complexity. The longer a player’s turn, the more they have to plan and take into account all the different actions they can take during that turn. If we look at the above-mentioned optimizers, it’s easy to see how a longer timestep size can actively push players towards global optimization (and vice versa), even if they’re not naturally that type of player.
A very important thing to note about timesteps is that they’re not always fixed. A lot of times, games have ‘variable’ timestep size, i.e. the amount of actions one can do during their turn varies over the course of the game. Usually, this is because of the number of actions depends on a player’s currently available resources and/or things they have in play. For example, in games like Hearthstone, your number of actions depends on the amount of mana you have for playing cards, and the amount of minions in play that you can attack with (to simplify a bit). Since players gain mana each turn, the decision space usually grows as the game progresses, and the timestep size tends to increase because of that.
On the other hand, games like Android: Netrunner have a set amount of ‘action points’, and barring some specific effects that give you more of those, the overall number of available actions remains more-or-less constant during the course of the game. You can have all the resources in the world, but you’re still only going to have 3-4 actions on average.
To be perfectly clear, like with 99% of things in game design, both large and small timesteps are just tools and neither is inherently better than the other. Tools can be misused, however, and knowing what you want for your game is very important. Mismanaging decision complexity can cause otherwise really well-designed games to feel clunky or just unpolished, leading to a poor overall experience for the players.
Adding structure to limit decision complexity
A way to make the game flow more smoothly is to keep turns concise. This doesn’t necessarily mean that they have to be short, or that there shouldn’t be a larger pool of decisions to choose from, but instead it’s all about reducing AP and keeping said decision space in check.
In general, more freeform turns, during which players are given full freedom regarding the order of their actions, makes for a pretty big decision space.
‘Do I attack now, or do I save the attack for after I draw some cards? Or maybe I should draw a single card, attack, then draw the other one?’ *
*I’m aware that drawing a card might be a bad example for this, since you generally want to draw cards as soon as possible, since more cards = more options for later actions, but I’ve used it for this example since it’s a dead simple effect that is game-agnostic and anyone can understand.
This type of decision-making, while definitely interesting, and offering a lot of strategic depth, can also be pretty taxing on the players in the long run. With completely freeform turns, decision complexity scales directly with the amount of actions the players have available during their turn, doubly so with repeatable actions.
The simplest and most effective way of limiting this type of decision complexity is by adding a well-defined turn structure. A lot of games do this, as it’s pretty much trivial to implement, and the results speak for themselves. When you split a turn into distinct phases (e.g. resource phase, play phase, attack phase etc.) and limit the actions which are possible within each of those phases, you limit the decision space in a natural way, one that doesn’t require you to remove any actions from the overall pool.
This also has the additional benefit of players being able to memorize the actions by the specific phase, as well as the order of the phases. This greatly reduces the potential for misplays of the actions themselves, however one has to be careful with how the phases are defined, as players might accidentally skip phases or do them out of order (MtG’s ordering of the ‘untap’, ‘upkeep’ and ‘draw’ phases being one of the most common misplays for newer players).
All this being said, it’s important to note that unstructured turns are also a very powerful tool, but a tool that requires the game to be pretty carefully built around it. The main thing to consider if going for this approach is the decision complexity and availability of the individual actions. Keep that low enough (and cascading decisions down to a minimum), and you should have no real issue with your implementation.
Granularity, tracking, and you
Granularity in games is mainly a measure of how big the ‘steps’ are between values of some parameter. Consider the following example: in Game A, the players’ HP goes from 0 to 10, and in Game B, it goes from 0 to 30. From this, we can say that Game B has more granular HP.
High granularity is usually great for development and balance. You have a greater range of values to choose from, and picking the ‘right’ value is easier because the ‘steps’ between values are much smoother. However, as with pretty much all things I talk about, it’s a bit of a double-edged sword.
High granularity makes for harder tracking. Values up to, say, 10-20 can usually be tracked using a single (multi-sided/RPG) dice, but anything more than that will probably need specific game pieces dedicated to tracking. It also makes for slightly harder math, which isn’t that much of an issue, but the lost seconds tend to add up over the course of the game. Consider these pros and cons carefully when deciding on the granularity of your values, as well as the fact that lower granularity makes things swingier (which isn’t inherently bad, and is oftentimes favorable).
Each parameter in a game has an ‘effective’ range of values related to that parameter’s granularity. As an example, I’ll use Magic: the Gathering. In that game, players’ life lies between 0 and 20, which I’d consider pretty granular. For effects that can damage players, the ‘effective’ range of values is, in most cases, 1 to 5 (or 6, haven’t really crunched the numbers). Effects with values outside this range exist, but they’re few and far between, and for good reason. This is done to regulate the power and swinginess of this type of effect.
The thing I want to highlight about effective ranges is that any change to the granularity of a parameter will require a proper reevaluation of the effective range: squeezing MtG’s life down to the 0-10 range doesn’t necessarily mean that the effective range for damage can also just be cut in half. Chances are, you would have to take another look at all damage effects in the game and tweak their values to better reflect the new level of granularity. Things like this have to be carefully considered, and then even more carefully tested, in order to make sure that the game remains balanced and fun.
Redefining the wheel
Intuition is an extremely powerful thing. Our brains really like to try and find patterns in things, and often try to auto-complete missing or incomplete data. Because of this, trying to fight intuition is a losing battle in the vast majority of cases.
Let’s jump into an example: One of my first games was a co-op boss battler. The details aren’t really important, but it was a card game where the main resource was managing cooldown on your cards. This was represented by putting the cards in a fixed-size queue/track, and whenever their cooldown ‘ticked down’, the cards would all move one or more places to the left. The cards that were pushed out of the queue this way were put back in your hand. For some reason, I went with a really poor wording decision: I used ‘draw X cards’ to mean ‘move your cards X places to the left in the cooldown queue’.
This was bad. Really bad. What I did was essentially try to redefine the phrase ‘draw a card’ to fit my game’s specific rules. However, the new meaning was anything but intuitive compared to what drawing a card usually is. I’d go so far as saying that ‘draw a card’ is axiomatic. In most cases, it means either putting the top card of some pile in your hand, or at the very least, putting a card in your hand. My game’s version could technically lead to cards being put in your hand, but having to go through a completely unrelated step first.
This isn’t to say that it’s impossible to redefine/change common terms to fit your game. Wingspan does exactly this with ‘draw a card’. However, the difference is in that, while in Wingspan you can draw cards from either a market zone or a randomized deck, ‘draw a card’ always means ‘put that card in your hand’. It’s close to the generally accepted definition of drawing that it’s intuitive. It doesn’t take any leaps of logic or much thinking in general to understand how it works.
The point of this example is simple: Don’t try to fight or redefine an intuition, unless you can build up an equal or better intuition to replace it.
A closing example on how to do this correctly comes from a video game, Endless Space 2. In that game, all the menus are designed around the fact that right-click is the dedicated ‘back’ button. This is an extremely uncommon choice for menu navigation, and initially it feels extremely weird. But very quickly, this builds up a very strong new intuition, to the point that after extended play, I found myself trying to right-click to go back in other games and even just other software in general.
As a final point, here’s a very cool video about a bicycle with inverted steering. The human brain is ridiculously adaptive, and any habit or intuition can be learned, unlearned and relearned given enough time. (Un)fortunately, the usual gaming session isn’t nearly enough time for that, so try not to bend players’ minds too much during it.
So, that’s the end of this lesson. Eventually, each MOPED principle will get an article like this, but there’s no guarantee when. Like pretty much everything regarding game design, it’s all about experience. One can only share knowledge about things they’ve experienced first-hand, at least in this domain. But, as long as you keep designing, you’re gonna learn new stuff, intentionally or not. The more you learn, though, the more there is to learn, so keep chasing that horizon.
Here’s the obligatory wind-down song of the article:
This is InvertedVertex, signing off.