By Joris Dormans (May, 2021)
This is a blog about our development of Unexplored 2: The Wayfarer's Legacy. This game features state-of-the-art content generation, generative storytelling, emergent gameplay, adaptive music, and a vibrant art style.
For Unexplored 2: The Wayfarer's Legacy we came up with the 'fortune system': a special, recurrent game mechanic to handle any situation that the real-time mechanics of the game cannot. In this case, the fortune system covers physical activities such as climbing and clearing rocks from a path, as well as social interactions with NPCs. In this post I like to present our journey as designers to create it. Spoiler: our road was longer and had more twists and turns than we anticipated.
A fortune test in action: trying to decipher an ancient inscription.
When we started work on Unexplored 2: The Wayfarer's Legacy, we had a clear idea of where we wanted to go, although we didn't quite know how to get there. Unexplored 1 is a fairly traditional roguelite dungeon-crawler, where we mostly reached high with the quality of generated levels in an action-based game filled with lock and key puzzles. For the sequel our ambitions were grand: we wanted to take the same type of gameplay out of the dungeon and generate a whole world for the player to explore. But most of all we wanted the player to feel they are in control of their own adventure.
Now, we are definitely not alone in this ambition. Many games in the action-adventure and action-RPG genres promise the player they can become the hero in their own adventure. But we tried to place ourselves firmly in the table-top RPG tradition where adventure has meaning beyond combat. In a traditional fantasy table-top RPG players will fight numerous foes, but they will also use the same or similar rules for stealth, climbing, social encounters, magic, and much more. We feel these types of actions complement combat in adventure stories and table-top RPG sessions in a way that is rarely seen in a computer game.
There are many reasons for this omission. Combat translates very well to real-time mechanics, and in many cases the same goes for stealth. Both involve a lot of maneuvering and create opportunities for players to make many small decisions that affect the outcome of an encounter. Mini games for lock picking, climbing, and magic have been done in the past quite successfully, but the difficulty of translating the variety offered by table-top RPG to computer games is more strongly felt in social interactions. Many have already written about the difficulties of dialog trees, and I assume the shortcomings of that common solution are well known.
Performance in a Fortune Test can determine the outcome of a social interaction.
Table-top RPGs typically use dice rolls to handle any situation with uncertain outcomes. These dice rolls are commonly referred to as skill-checks because your character's abilities and skills are very likely to factor into the chance you have to succeed. Some RPG systems can have quite elaborate rules for making these skill-checks, but even simple, single dice roll against a certain target number can be quite fun and engaging.
Skill-checks are not uncommon in computer RPGs either, but when implemented with similar mechanics they do not seem to offer the same level of fun. The physical experience of picking up a die, and shaking it before rolling in order to find out whether your action succeeds, is vastly different from simply clicking a button to the same effect. The result is often that computer RPGs focus the gameplay on the things that work well on a computer, and for many this means combat, and for some it means combat and stealth.
What we were looking for when we designed the fortune system for Unexplored 2 was some thing that had the same level of engagement for the player as rolling a dice on a table, could easily express many different types of skill-checks, and offer a level and depth of gameplay that would not pale next to real-time combat. The fortune system is not a direct translation of dice, but an enabler that allows us to tap into a wide palette of possible encounters to craft adventures from. We are quite happy with the end result, but it did take many iterations to get there.
From the outset we knew that we wanted to have one system that could express as many of different types of skill-checks as possible. This includes things as diverse as testing your strength to try and open a door, testing your wit in a social engagement, or your agility when prying open a lock. We also knew we wanted to have multiple possible outcomes for any of these situations. Some of these tests are not even about whether you succeed or fail, but what it costs you to proceed. For example, the first fortune test you will encounter in Unexplored 2's tutorial is to open a door that is stuck. Basically it is a test of strength, but there is no point in having the player 'fail', because that would mean they would not be able to complete the tutorial. Instead, the player always succeeds, but sometimes the player becomes fatigued, sometimes they lose time, and sometimes they cause rocks to fall that might damage the player.
Early design mock-ups for the first iteration of the fortune system.
Considering these requirements our first stab at making the fortune system was a simple card based mechanic. All the possible outcomes would be represented by different cards, the player is shown the cards before they are shuffled. Next the player simply picks one of the cards and the effects are applied. The system was simple and effective. It had a few advantages: it communicated the chances of success fairly well, and picking the outcome yourself feels more engaging than simply pressing a button to generate a random number.
But there were also problems with these first iterations. The outcome is purely based on luck, and it only involves one blind choice by the player. Because of this it grew tedious quite fast. In addition, we were making an RPG and we needed characters with different backgrounds and skills to have different chances of succeeding. We experimented with a system that would add extra success outcomes to the stack of cards if you have the right skills, but the player never seemed to feel the effects very clearly. The composition of the deck felt random, and players were never required to actively make use of their skills.
We tried out several things to improve this basic system. For example, to increase the expressive range of possible outcomes some cards only represented negative effects, if you drew one of these you might get fatigued, but you could draw again to try to pass. This iteration required you to keep drawing until you either succeeded or failed the test. It didn't help much, tests were even more tedious, and felt even more random.
To counteract the randomness we experimented with multiple cards being drawn at the same time and requiring the player combine a number of them into a result. Negative cards could be 'locked-in' and required the player to figure out a way to deal with them or negate them. But ultimately none of that stuck.
Multiple fortunes, locked-in fortunes and one of the first appearances of sparks as a resource to manage your fortunes.
We figured that an important flaw of the system was lack of player agency. One might argue that in a table-top RPG, players also do not have much agency when rolling the dice. This is partly compensated by the physical experience of rolling the dice. In addition and in contrast with our system, in a table-top RPG players have to actively apply all the rules. If having skills add modifiers to dice rolls (or better still, add extra dice), the effects and outcomes of earlier choices are far greater than our system offered. At least, this leads to a greater sense of agency.
To remedy the issue we decided we needed to offer the player more ways to control the outcomes of a test. This led to the introduction of a resource called 'sparks'. Sparks allows the player to redraw any fortune they did not like, as long as they can pay for the resource with sparks. In addition, the redraw mechanic also turned out to be a great opportunity to incorporate skill redraws into the system: having the right skills now also entitles you to a number of free redraws. That way players would actively utilize their skills, which made having them much more tangible.
We quickly realized that having enough sparks allows you to get any result you want, so we knew we needed to have a fairly tight economy of sparks. For a little while the fortune tests themselves were the most important source of sparks themselves, because we awarded players with sparks when they picked or stuck to negative outcomes. Although this creates an interesting dynamic where you could not win all fortune tests and had to pick your battles, it also meant that players could farm certain fortune tests for sparks, which was not the intended effect.
We ended up with a system where you start with a fair amount of sparks, and you can occasionally find them as a reward for exploring levels. Occasionally, players might run into a large stash of them, or be offered to gain a fair number of them instead of gaining a regular skill during character progression. But in general, we wanted to make them short in supply, forcing the player to think about when to use them, and making sure that redraws granted for having the right skills feels sufficiently powerful.
The fortune system was tuning up quite nicely, or so we felt. On more than one occasion we were pretty sure we had nailed it, only to find out it didn't age as well as we'd hoped. The system seemed to lack a certain depth. Fortune-checks always seemed to evolve in fairly the same way and basically were dominated by the ability to keep redrawing until you drew a favorable outcome. There was no way the player could get 'good' at the system or was even challenged to think about the test strategically.
The solution for this was to incorporate very simple deck-building mechanics to make sure that each test evolves in different ways, even if the starting conditions are the same. The first step towards achieving this was to eliminate all the 'success' fortunes from the starting pool of a fortune test. In order to successfully complete a test the player needs to draw and play fortunes that add success to the pool of possibilities. Now we had two types of fortunes: 'outcomes' that will end a test in success or failure, and 'effect' fortunes that add fortunes to the pool but might have other gameplay effects as well. For example, the 'Make an effort' fortune adds three successes to the pool, but comes at the cost of applying the Fatigued status to the player as well. Obviously, such a fortune would only make sense in a fortune test that represents a physical challenge such as climbing. But we already had different starting pools to represent different challenge types. This way, an easy social test can be made to feel quite differently from a challenging agility test in which you run the risk of setting off all manner of traps or alarms.
The effect fortunes allowed us to offer the player different stakes. For example, the 'raise the stakes' fortune only adds one success to the pool, but it represents a 'great success' that would yield better results. Again, this might not be applicable for all situations, but it works well in many fortune tests representing social interactions. In a situation where the player is bartering for better prices, a great success fortune might be well worth a few sparks in an attempt to draw it from the pool.
More importantly, the player's choices started to have an immediate effect, and what constitutes a good choice started to vary strongly with the situation. Some effect-fortunes initially seem to be so desirable there is no harm in always playing them, but we've seen situations for any possible fortune where not playing them is in fact the better choice depending on the current fortune pool, previously drawn fortunes, and the goals players set for themselves. Slowly but surely, the ability to read the current state of the fortune pool, in relation to the availability of sparks and skill redraws became a decisive factor in performing well in fortune tests.
At this stage, we also added an extra cost to redrawing: the first redraw of any round now also adds a negative fortune, typically a 'failure' or a 'critical failure'. This means that the players actions can affect the fortune pool positively or negatively and it countered the strategy of aggressively redrawing.
The last additions to the fortune system were fortunes designed to stir things up occasionally. For example, we added the Inspiration fortune which when chosen simply adds three rerolls. On paper we were a little worried that a fortune like this might feel a little too mechanistic. It has very little meaning outside the fortune test. Once implemented however, we quickly discovered it felt actually quite good. It felt rewarding to draw and play, but more importantly it stirs up the dynamic of the test. If you draw an inspiration fortune, it may inspire you to change strategies and start playing for a higher reward.
Another fortune we added at this stage is the 'rare opportunity' which represents a favorable bonus, often only applicable when the test is completed successfully. Its appearance is random; tests that allow them will not always have them, making them feel more rare and special. This fortune plays into the different risk-reward strategies the player can play for: often they will have to get a little out of their way to get one, and once you have it, winning might become more important.
The 'gloom' fortune allowed us to tie the fortunes to important narrative themes in the game. The world of Unexplored 2 is threatened by an evil empire that slowly but surely destroys everything it touches. In their wake the lands become desolate and bleak. Traveling through these lands the player finds that many tests are 'polluted' with gloom fortunes which when played cause loss of 'hope', a vital, sanity like, resource of the player character. In effect, gloom fortunes are a little like 'filler cards' that get in the way in deck-building games like Dominion. But the way they tie in with the backstory makes another effective way of making sure that the presence of the empire is felt even in the most mechanical parts of the game.
An encounter with enemy soldiers guarding a bridge where a fortune test can be used to avoid combat.
Once the system was in place we faced another challenge: how to communicate it to the player? The first playtests were not particularly successful. People had trouble understanding how the tests worked. In hindsight, for a large part this was because the UI had grown quite organically as we iterated on the mechanics. Over the years we had explored many directions and to a certain extent the UI retained traces of all. In order to fix it we had to clean the slate and decide on the best metaphors to support the mechanics, from scratch if need be.
Along the way we decided that we didn't want to have a card based system, and that simple tokens drawn out of a bag were the best real-world equivalent for our system. This choice was partly informed by the fact that we wanted the player to know what fortunes are inside the pool at any moment. Playing cards and deck-building have slightly different affordances. A shuffled pile of cards to draw from, for example, typically does not reveal which cards are in the pile, only roughly how many are left. In addition, we do not have the typical cycle mechanics common to deck-building games where new cards go into a discard pile before being reshuffled into your deck. All new fortunes go into the pool immediately, and once played, a fortune is discarded altogether.
Once we doubled-down on that metaphor and tried to implement that as cleanly as possible the system started to click for players. From new playtests it quickly became apparent that players now understood it well enough and quickly could engage with the system strategically. Even though the subtleties of the dynamics meant that there would be plenty left to discover over time.
Having a UI to match a well chosen metaphor to communicate the mechanics effectively, is quite obvious. But deep in the trenches of game design, we found that, for us, that was also quite easy to forget.
Obviously, we are quite happy with the result; I would not be singing the praise for the fortune system in this post otherwise. But it also seem to resonate with our audience. As Steven Messner points out in his PC Gamer review: "Just like in D&D, Unexplored 2 understands that it's way more fun (and tense) when there's different shades of success and failure."
The fortune system is able to express a wide variety of possible situations that would otherwise be difficult to represent in the game. I am particularly proud of the way it can handle social interaction in a meaningful way. We do not rely on branching dialog trees with many blind choices. Instead, the player can perform well based on their character's build and their willingness to invest sparks.
The system is quite dynamic, what is a good choice in one circumstance might not necessarily be your best option in the next test. I have come across situations where I found myself forgoing obviously beneficial fortunes such as 'inspiration'. The fortune tests create a chain of small, meaningful choices: when to redraw? Which fortune to choose? Combined these choices string into a performance that will determine the outcome of the encounters. Players can play it safe, or push their luck. The density of choices may not be as high as the density of choices during a real-time combat encounter, but the strategic engagement we have seen in players with these tests allows us to incorporate a greater palette of possible adventures in our game, which is exactly what we set out to do.
Contact: info@ludomotion.com