Resource-related Rambling

Resource-related Rambling

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.

Difficult definitions

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.

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.

Generation Methods

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: stockpiled, recurring and accumulative.

Stockpiled resources are ones which are pretty much ‘single-use’. These are the resources which you, well, 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.

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.

Tags: , ,

Leave a Reply

Your email address will not be published. Required fields are marked *