Last article I talked about MOPED. This article, I won’t talk about MOPED. Instead, working on one of my games got me thinking about a subject I’ve found a bit lacking in categorization in the past. And, it often feels like categorization is something game designers enjoy doing more than actually designing games.
Theory is important, don’t get me wrong. It’s very useful to be able to learn from others’ mistakes and experiences, but theory shouldn’t be treated as a replacement for getting your hands dirty. Theory should support and supplement practice, and this article will focus on something that is mostly felt in gameplay, rather than discussed outside of it: resources.
What is a resource? This has been surprisingly difficult for me to try and articulate. The simplest way to put it is that each resource is just a value. A value that dictates the number of options/actions a player has available at some point in the game.
While a definition of resources might seem redundant, it is important to have in the context of this article. Resources are things which we implicitly understand, so trying to look at them from some empirical standpoint might be overthinking things. For what it’s worth, let’s use the ‘value that dictates options’ definition for now.
The first division of resources I tend to do is separating them into Implicit and Explicit. So, what does that even mean? Well, it has to do with how ‘active’ some resource is in the context of the gameplay, or maybe even how obvious it is for the players.
Explicit resources, by my categorization, are the ones that immediately come to mind when thinking of resources. Essentially, things you spend in order to do other things. As an example, let’s take some TCGs. These games tend to be good examples for this category. In most TCGs, the players have some primary resource (most often called mana/energy) which they must use in order to play their other cards. Regardless of how that resource is gained (which we’ll get into further down in the article), the key point is that you have to actively spend mana to take actions. The same goes for the actual cards. Cards are an explicit resource in card games. You have to spend them (with exceptions in every game, of course) to do anything. Most resources in games tend to be explicit, since most resources are actively interacted with and rely on player agency to regulate. However, there’s one more side to this story, and it’s equally—if not more—important.
Implicit resources, on the other hand, are ones that you still need to manage over the course of the game in order to play, but aren’t spent at all in order to pay costs, at least not directly. In Magic-style card games, the most important implicit resource is Life/Health/HP. You need to manage that resource, cause when you’re out of it, you lose the game. And while it’s true that there are effects in these games that treat life as an explicit resource, the core rules of the game don’t. This is an interesting thing in Magic specifically, since while many new players will have no trouble using the explicit resources we mentioned, they don’t look at life as a resource until they have some experience with the game. Out of sight doesn’t mean out of mind when resources are concerned.
For a designer, the key takeaway about implicit resources is just knowing they exist, and figuring out (if you already haven’t) which resources in your game fit this category. This will allow you to treat them with the same level of attention as the explicit ones, and at times it might be useful to try and change a resource from one type to another. Be very careful with implicit resources, though. These are things that can spectacularly backfire on you if they prove to be too hidden or annoying to track.
Now, this categorization isn’t absolutely empirical and objective, and I’m sure that different people could put the same resource in different categories due to subjective interpretation. However, I think the important takeaway here is to not forget that implicit resources exist, and that they’re a very useful tool that can help or hurt the game just as much as the more obvious ones. All resources are parameters of the design, and regardless of their visibility (or potential lack thereof), both the designers and the players of the game need to understand their importance to get the most out of them.
So, now that we’ve covered one way to split resources, I want to take a closer look at a grouping of explicit resources I’ve done, based on how they’re generated. Long story short, there are 3 categories here: gathered, recurring and cyclic.
Gathered resources are ones which are pretty much ‘single-use’. These are the resources which you stockpile—usually through actions—until you have enough that you can spend them on the thing you want. Credits in Android: Netrunner are like this. You build them up through default actions or card effects, and you can spend entire turns at times on just gathering the resource.
Resources like these are ones that require the most active management from the player, and are best used for games where the impact of that management should be a core part of gameplay. For this reason, they tend to lend themselves more to slower, more tactical games, but they can be made to work in any game with enough tinkering.
Recurring resources have some specific value that they get set to each turn/round/specific timing window. This means that players have exactly the same amount of the resource on each turn, and how much they’re able to do in that turn will vary based on the rest of the game’s state. In my game, Project:Confluence (more on it here), I use this exact type of resource, in order to remove/mitigate the overhead that a varying amount of resources on each turn can create. This way, since the players know they’ll have 10 of the resource each turn, they can focus more on how to use it, and combined with fixed-cost default actions, more quickly evaluate how much what they want to do will cost.
As mentioned, recurring resources are best used when you want to minimize the importance of getting the resource as opposed to the importance of using it. However, this comes as a bit of a double-edged sword, since these resources create a lot of consistency which will definitely impact the way the game will be played and balanced down the line.
Cyclic resources are ones that players have access to during some regular or irregular cycles. In my game (Confluence), the players’ cards themselves are this sort of resource—any cards spent go to the bottom of a player’s deck, and they’re guaranteed to have access to that card at some later point in the game. This can also be done with things like marketplaces in games which have them (e.g. some deckbuilding games), where if you miss the opportunity to get an item from the market, given enough time, the item will be present in the market again.
These kind of resources are best used when you want to have some period of time pass between the uses of the resource, and don’t really need to worry about having a fixed quantity of it (like the Confluence example), or just want to make sure opportunities can occur again at a later point in time. Do keep in mind that this is best used sparingly, as requiring players to keep track of multiple cyclic resources in order to play optimally can create massive overhead for those that choose to do so.
In addition to the generation strategy, there are additional classes a resource can belong to:
Upkeep resources are a bit of an outlier in the sense that they create a (usually) static limit to something, rather than being something you actively spend or gain. These are resources that represent the players paying an upkeep cost for having something in play at the beginning of their turn. Now, unless there is a good reason to have an actual trigger for these at the beginning of each turn, they can easily be streamlined to the following—a static value that decreases when you play something that uses it (say, deploying soldiers on the battlefield), and that decrease lasts for as long as the thing is in play. To differentiate this from generated resources, this is best implemented through having an initial maximum for the value, and returning the resource spent on something to the pool when that thing leaves play.
With the ‘deploying soldiers’ example, think of the resource as representing something like food. The more soldiers you have deployed, the less food you have available. When some leave play, you can either get that food back immediately, or would have to reacquire it over some time.
These resources are best used when you want to create hard or soft caps for some amounts, usually for limiting the number of objects in play. You can still increase or decrease the initial maximum/cap of the resource during gameplay. Do keep in mind that if it’s possible to decrease the cap during gameplay, you need to define what happens when the total cost of things in play exceeds a player’s current available resource.
Accumulative resources, on the other hand, are those which increase naturally over the course of the game. Now, these can either refresh regularly, or be persistent/stockpiled, so in a sense, being accumulative is an additional parameter more than it’s its own category. A lot of card games use this type of resource, like Hearthstone’s mana crystals, whose maximum capacity increases each turn up to a cap of 10, and refreshes to the max after that; or MtG’s lands, which have no upper limit, refresh each turn, but also have an element of randomness when it comes to the accumulation, since they’re represented by cards in the deck itself.
These resources are somewhere in the middle, since they are a subtype of either of the other two categories. They offer a reasonable amount of control over pacing, since by nature the players will have access to more resources as the game goes on, but when combined with the single-use stockpiled approach, they can be equally as tactical. In the end, it’s up to you as a designer to choose which type of resource best fits your game, and my advice would be to try all if possible, and go with what played the best. As always, test, test, and then test some more.
So, long story short, there’s more to resources than meets the eye. I will probably go back and edit this article at some point in the future, to either revise the classification, or to add to it. When that might happen is anyone’s guess, but ultimately, this isn’t meant to be 100% exhaustive as much as it’s meant to be a quick reference and something to keep in the back of your mind when going into a design. Also, don’t be afraid to look at your existing designs again after learning new things, not just from articles like this, but from your own designing/playing experiences, too. You never know when you’re gonna get an idea that upgrades your existing ones, so it’s best to stay vigilant.
Next time, I’ll be diving deeper into the M of MOPED: Modularity, and how it can make or break games, especially when design space and scope are concerned.
Until then, here’s some tunes to keep things going smoothly:
This is InvertedVertex, signing off.