Gaming on a Timer

A Casual Glance – The Grind, And How To Implement It

In A Casual Glance we’ll be having a look at various aspects of game design from the perspective of a casual observer (i.e. no hands-on experience in the games industry or professionally working on covering them, just as a player experiencing them) – this week we’ll be talking about the concept of grinding in games and taking a look at a few examples of implementation, both good and bad.

During the last few days, there’s been a few discussions on grinding in games going on at the 100Pals Achievement Discord Server. While I’m not quite sure what inspired all of them, I can take some guesses: within the past couple of weeks, Capcom announced that their flagship title Monster Hunter World would be getting an expansion in Q3 2019 (Iceborne); Grinding Gears’ Path of Exile received its biggest expansion thus far (Betrayal); and on a more general note, the end-of-year festivities have brought a series of events in most (if not all) of the perpetual play games that people are into (anything from WoW to Warframe, though the subject of perpetual play itself is probably something best suited for a future post).

The common thread in all these games is their reliance on grinding as a reward mechanism, in one capacity or another. In the interest of clarity – and since the term itself is interpreted in various ways – let’s set a definition of what constitutes “grinding” in a gaming environment.

Grinding comes in many forms, from looking for specific monster sizes to raising hunter ranks…

In broad strokes, we’ll be working under the assumption that grinding is the act of replaying already cleared content in order to gain an in-game reward, either due to said reward being awarded randomly or by requiring incremental build-up to acquire. Some more generic examples are:

  • Defeating a specific enemy repeatedly to earn an item (most prevalent in MMORPG’s with respawning enemies and random item drop chances – most famously World of Warcraft’s entire loot system is built upon this cycle)
  • Completing specific quests/missions to earn advancement currency more efficiently (such as finishing repeatable quests to earn experience or “reputation” points – a prime example is Monster Hunter World’s Hunter Ranks, which accumulate through all completed content but have a much higher rate of accretion within certain event-only quests, thus making them highly desirable to anyone wanting to raise their Hunter Rank efficiently)
  • Repeating specific content in order to unlock other forms of empowerment/rewards (such as materials for crafting – Warframe is an excellent case study where certain materials that are needed to make bigger and stronger weapons are more likely to drop in specific missions)

A keen-eyed reader will also notice that, aside from repetition, the other key word used is specific – grinding only applies when having a clearly-defined goal, be it “gaining level 30” or “improving your equipment” or “unlocking a new reputation level” (in the case of more vague goals, design comes under a variety of headings, most notably “perpetual play”).

This very specific nature of grinding is also why it can often go horribly wrong in its implementation – games, at least partially, rely on offering a sense of uniqueness, discovery, wonderment or similar to get players to “buy into the fantasy”, so to speak and there is nothing that kills off that aspect faster than requiring constant repetition of the same content over and over again.

As always and with the above in mind, we’ll be having a look at some examples that manage to either work around or with the limitations of grind-based systems, whether by refining the systems themselves or by complementing them via other, interlocking systems.

Framing The Question

Digital Extremes’ Warframe is probably one of the more well-known free-to-play titles currently on the market – following a rough start during its initial launch semester, the game was slowly (but steadily) refined into a massive sleeper hit. 

In Warframe, players take control of the titular Warframes, biomechanical suits of armor with powerful abilities, which act as the game’s class system – each Warframe handles differently, comes with a set of four unique skills and one (or more) passive abilities, with some best suited for taking fire, dealing damage, hiding and eliminating enemies in a stealthy manner, and so on and so forth.

There’s a huge variety of different Frames…

Being a free-to-play title, one of the major gameplay elements is grinding for more or less everything – weapons, Warframes, companions, equipment – every single piece of gear needs to be earned through grinding, often by acquiring the blueprints and materials needed to craft it. Naturally, as a free-to-play title, this system is complemented by an extensive microtransaction store, where a player can pay real-world money in order to expedite acquisition of said gear.

Taking a look at the overall free-to-play market, one can see that the majority of F2P titles on offer mostly fail to strike a balance between the grind and microtransaction parts of the system – these games often come across as too grindy (sic), in turn making microtransactions feel forced or unfair – and yet… Warframe somehow manages to avoid such criticism (for the most part). Why is that?

I believe that a big part of why grinding works in Waframe is that the core gameplay has been built with grinding being a core concept, rather than added at a later stage. A mistake that F2P games often make is using grind as a means to either inflate game time or increase difficulty artificially (once again, a subject best left for a future post) – often with the goal of making microtransactions feel more enticing. This will in turn lead to player fatigue, resentment and eventually low retention rates.

Warframe takes two steps in its design in order to avoid this. Firstly, the grinding is kept down to small, discrete projects – for example, while crafting every single weapon in the game might require hundreds upon hundreds of hours, any single one of them can be gained in a much smaller time frame, ranging from a couple of hours to a few days. Thus, the player never feels overwhelmed, always has a goal to work towards and (more importantly, owing to the aforementioned uniqueness of each item or gear piece) provides a wide variety of different gameplay styles and alterations.

…and an even bigger selection of weapons.

Secondly, by way of level and gameplay design, the developers make heavy use of rogue-lite principles to lessen the repetition – levels are constructed out of pre-made room configurations, with a wide variety of unique setups and features (such as environmental hazards and enemy type availability), while the selection of different game modes and objectives further enhances the randomized nature of available content. In doing so, Digital Extremes achieve a player experience that feels fresh and interesting several hundreds of hours later, the majority of which is spent grinding for more content (even if the player in question doesn’t aim to experience everything on offer).

Therefore, we can observe that grinding  can be implemented in such a way that it not only improves, but rather supports and enhances the entire experience – mitigating the repetition by designing against it and by breaking it up in smaller, better-managed segments.

On that subject, let’s have a look at another game which leans on these design ideas, but this time from the AAA space.

Hunting For Fun And Profit

In a lot of ways, Monster Hunter World follows the exact same “recipe” as Warframe: a wide variety of weapons and equipment that offer wildly different gameplay styles, quasi-randomized content (called investigations and coming with a series of random modifiers that alter the mission’s parameters) and an emphasis on building the player’s gear up by progressively playing harder content.

Where it differs though, is its in focus – while Warframe takes a quantitative approach (as evidenced by its procedural-generation of levels, as well as the huge variety of items and gear on offer), Monster Hunter World focuses more on interactions –  specifically between players and monsters. 

The series in general is a great example of enemy design and implementation, with  a huge amount of work apparently going into the game to make each monster feel unique. From a creature’s diet, habits, nesting and feeding areas, to its general behavior and hierarchy in its native biome, the developers have taken great pains to simulate a consistent ecosystem with bottom feeders, apex predators, herbivores, carnivores, and a large amount of other variables.

With 14 different weapon types to play around with (each handling in a significantly different way), you’ll not feel the grind anytime soon.

By using such a high degree of complexity in their core enemy design, Capcom achieve a type of replayability which works incredibly well on a fundamental level when combined with a degree of randomness – in this case, by introducing the player into the aforementioned ecosystem. Players can (and are encouraged to) exploit monsters’ weaknesses, habits and characteristics in order to gain an advantage – any one of a monster’s unique attributes can become a tool against them.

This randomness does not stem from player skill alone, either. As mentioned above, the game offers a wide array of gear, weapons and armor with which to kit out a player’s hunter – aside from providing some much-needed mechanical variety, it’s important to note that most (if not all) of these items are carefully balanced, in order to not have any one given weapon or gear set outperform its equivalents ( it’s important to note that not all gear is equal, just that any item is a valid option within its own power tier). As a result, each hunter can and usually performs a lot differently than their peers, offering a good deal of replayability and experimentation space (design-wise).

Similar to Warframe, the aforementioned gear is also gained by grinding through content – in this case, utilizing a random drop table for each monster, which can be affected by exploiting a monster’s damage model (a system in where certain parts of each monster can be destroyed, which affects their available movesets and item drops, for example by cutting a tail off in order to prevent them from attacking with it and gaining an extra item chance from the cut appendage itself).

The ecosystem has some cool little intereactions you can find out, as hinted here.

Therefore, we can observe that in Monster Hunter’s case, the grind is tied directly to progression (since both a player’s knowledge and gear rank is increased with each successful hunt ) and can also be affected by said knowledge and skill (cutting/breaking of specific monster parts during combat, which results in better/more specific rewards).

As a final note, it’s interesting to note that in both game examples, the designers have taken steps to include the grinding aspect into the main gameplay design  – be it Warframe’s huge variety of  missions, enemies, weapons and frames or MHW’s more limited but better-balanced selection of monsters, weapons and gear, everything seems to be tuned to support, encourage and benefit from grinding, while actively taking steps against the traditional problems arising from its use (boredom and a heavy feeling of repetition).

Perhaps, this is the most important design hurdle to overcome: how to make the grind feel like less of one, while keeping its functionality and purpose intact? Hopefully, the games we’ve examined here can provide some insight into answering this question – and if not, then it at least makes for interesting observations.

What are your preferences when it comes to grinding in games? Do you enjoy the methodical approach to it? Do you prefer games that try to “mix it up”? Share your thoughts in the comments section below!

A Casual Glance – Achievements Vs. Gameplay

In A Casual Glance we’ll be having a look at various aspects of game design from the perspective of a casual observer (i.e. no hands-on experience in the games industry or professionally working on covering them, just as a player experiencing them) – this week  we’ll be looking into various cases of achievement implementation and how they interact with the gameplay aspect of a game, whether successfully or not. with examples from speedrun and no-death/low-death achievements.

As a subset of game design, achievements can be both a versatile and intriguing tool to use for guiding a player’s experience – from hinting at possible alternative or hidden actions (such as Dishonored‘s “Clean Hands” achievement, awarded for completing the game with no enemies or story targets killed) to providing incentives to engage more with specific parts of the game (i.e. any variation on the “Kill x number of enemies” ever), if implemented correctly, they can greatly boost the enjoyment and entertainment value of a given product.

LIMBO is a great  example of trial-and-error design….

What happens when achievements are not implemented correctly though? In a recent discussion I participated in at the 100Pals Achievement Discord server, the subject of speedrunning and no-death/low-death achievements was discussed, giving rise to some very interesting observations on the subject of poorly-implemented achievement design.

Firstly, let’s examine what a “speedrunning” and what a “no-death” achievement actually is, just to establish a baseline for our examples:

As the names suggest, a speedrun achievement is one that requires a distinct segment of the game to be completed within a rigid time limit – such achievements might revolve around a specific mini-game (such as Warframe‘s “Counter Intelligence” achievement, for completing any Cipher mini-game in under 5 seconds), a full level or extended set-piece (Legend of Grimrock‘s “Dungeon Runner”, granted for completing the dungeon’s first floor in under 4 minutes) or even the entire game (DLC Quest‘s “Man That’s Fast!” achievement, which unlocks upon completing the entire original campaign within 12 minutes).

…especially in some instant-death situations, where it becomes extremely punishing to newcomers.

No-Death or Low-Death achievements on the other hand (also colloquially called “hardcore mode”, “perma-death” or “deathless” achievements by the community) are achievements that are – predictably – awarded for completing certain segments of a game without the player character dying (or otherwise reaching the equivalent of that fail state). Good examples of these achievements are LIMBO‘s “No Point in Dying” (complete the game with five or less deaths in one sitting); or Hard Reset‘s “Resistant” (complete any level other than the first without dying (Normal difficulty)”. Note that, in this case, merely reaching a fail state wouldn’t be considered a “death” unless it requires either restoring a previous world state or otherwise significantly invalidates a player’s progress (which is why we don’t see deathless achievements in games with instant player respawns).

With that out of the way, let’s return to the actual discussion that prompted this post – the conversation began with the mention of LIMBO’s aforementioned “No Point in Dying” achievement and quickly went through a variety of other games containing no-death achievements, eventually proceeding to include speedrunning achievements as well, all with one major theme: Are these achievements fun to accomplish?

The people in favor of these achievement types argued that their major appeal lies within the challenge they offer – a way to show mastery over the game, skillful play and intimate knowledge of the game’s inner workings which would then be rewarded with an achievement. Meanwhile, people arguing against their use would focus on one common thread – it made a previously-enjoyable game “not fun” or similarly feeling more like a chore or a bore to play through. Both sides seemed to raise valid points and it got me thinking – as I might have mentioned in previous blog posts, one of the indicators I use in defining a badly-implemented achievement is the “fun” factor, i.e. does this make an otherwise fun game lose its appeal? 

Going back on previous experiences, I realized something: speedrun and deathless achievements aren’t inherently boring or bad, but rather they are not a good fit for all game types. Consider a game like Braid – slow, ponderous at times, requiring a critical eye and some amount of lateral thinking in interpreting the designer’s puzzles in each level. In other words, a slow experience. Looking back on my time playing Braid, the only achievement I remember distinctly not liking was “Speed Run”, completing the entire game in under 45 minutes – mainly because it didn’t mesh well with the core design of the game (even if I hadn’t quite realized this at the time). In contrast, achievements in Mirror’s Edge I found to be a lot more enjoyable, even though a big part of the list is comprises of speedrunning achievements.

Braid’s slow pace runs contrary to any achievement design requiring speedrunning strategies.

Why was that? Because Mirror’s Edge, unlike Braid, is built to encourage and promote a “must go fast” mentality in the player – everything in that game, from the conservation of momentum in Faith’s movements to the level design which promotes vertical over lateral traversal, the entire game is designed to facilitate speed – something integral and expected in the process of speedrunning. Therefore, any achievements that do require completion of content under time constraints work with the game’s design and systems rather than against or despite it.

Similarly, no-death achievements are a lot less effective and enjoyable if the game in question relies on what is usually referred to trial-and-error design, in which the player is expected to have some form of prior knowledge of the game in order to complete it (most frequently through dying or retrying to learn the “proper” steps in traversing the game). A good example of this is the aforementioned LIMBO, where a few sections have nearly unavoidable deaths (not factoring the player’s luck in positioning correctly), which mean that a no-deaths (or in this case, five or fewer) achievement assumes the player has already gone through (and remembers) the game at least once in order to reliably be able to earn it.

This is a major issue with achievement implementation in general – a lot of examples can be made within games, in which achievement systems and  gameplay do not mesh well. Anything from having to kill a large amount of enemies in a game with limited enemy supply and/or long respawn timers, to collecting items that provide no actual gameplay enhancement, to performing in-game actions with no bearing or consequence during regular play (what I’d call meaningless actions, aside from unlocking an achievement) – all of these are generic examples that can be found in most any game with achievements or trophies.

As to why this keeps happening, I believe the reason is two-fold. Primarily, achievement systems are in a weird place at the moment – they are recent enough to not have been fully studied and explored, but established enough that they are one of the systems expected by players, i.e. a developer’s customers. Thus, from a developer’s point of view, games must include achievements (since their customers expect and even ask for them, and in all likelihood their competition already provides the same service) while still not having the proper “know-how” and experience to fully realize their potential as engagement tools.

Perhaps, one day all achievements will feel as good as this… sans the meatball-hair, of course.

At a lesser degree, I believe that the current fragmentation of the gaming community has contributed in the players themselves not having a clear idea of what they want out of an achievements system. This becomes apparent when considering that there are a multitude of different services and digital distribution platforms currently operating – Steam, Origin, GOG, uPlay, Playstation Network, Xbox Live, and so on and so forth, all of them vying for customer exclusivity and, more importantly for this topic, all of them coming with their own proprietary achievement/trophy systems. As a result, multiple communities – each with different goals and expectations – have formed around most of these platforms’ achievement systems which I suspect have made it extremely difficult to provide consistent and focused feedback towards designers and developers.

In writing this, I realize that a certain subset of the gaming community (or perhaps even the majority) will loudly proclaim that achievements are “useless” or “tacked-on” – in a sense, they are correct. However, I feel that this is more a problem of how they’re implemented, rather than an inherent flaw of the system itself. Achievements have the potential to engage and enrich an experience – a lot of recent advancements in gamification have shown that their real-life counterparts can and do offer tangible benefits when implemented correctly – as long as they are implemented in a thoughtful and precise manner, while complementing a game’s core design philosophy.

Unfortunately, aside from a few broad observations and recommendations, I don’t think this is a “problem” that can be easily solved. The fragmentation certainly cannot (although some communities have recently started branching out, with help of multi-platform tracker sites such as MetaGamerScore, which make it easier to track progress across various platforms), and the developer side is one of those things that needs to just run its course, so to speak. Certainly, as time passes and the achievement hunting community grows, the need for research into achievement systems and design will grow as well and, with it, a greater understanding into how to better engage and entertain a player. In the meantime, direct developer feedback is probably the best solution (where applicable) – telling developers how and why achievements work (or don’t) is more than likely the best approach to improving these systems for everyone.

As an afterword, I’d like to mention that I am by no means an expert in this field. Most, if not all of my experience is based on personal engagement in the subject and thus might be skewed or insufficient. Even so, I feel that it provides at minimum a good starting point for discussion, much like the Discord channel debate that sparked this article in the first place – perhaps, with a large enough pool of differing opinions, achievement implementation can reach its full potential and truly enrich a game’s experience.

Do you have any examples of properly-implemented achievements? Achievement design that clashes with the gameplay? Drop a comment below!

Fun With Friends – Asymmetrical Design (We Were Here)

In Fun With Friends, we’ll be taking a look at various co-op experiences, from action-packed sidescrolling shoot-em-ups to calmer, more methodical puzzle-solving games. This week, let’s have a look at how asymmetrical design improves upon a co-op experience with help and examples from “recent” F2P co-op puzzle game We Were Here.

Playing co-op games has always been one of my favorite multiplayer activities ever since my formative years, from Contra and Golden Axe‘s side-scrolling mayhem action to more methodical, slow burners such as Lost Vikings and (once co-op moved on from the realm of the side-scroller to other genres) several Infinity Engine games like Baldur’s Gate or Icewind Dale. For me, it was always much more than just the thrill of playing with other people – it was a sense of camaraderie, or perhaps knowing  that someone else just experienced the game in the same way as I just had, a joint sense of accomplishment.

Needless to say that, to this day, I always savor my co-op sessions – doubly so since nowadays tight schedules and real-life obligations limit said sessions more than ever.

The second puzzle in the game, from the librarian’s perspective…

Before diving into asymmetrical co-op design, let’s set a baseline for a what constitutes a co-op experience. As with most gaming-related terms (which have always been a bit nebulous and subjective) the “co-op” tag can be stretched to fit a lot of diverse examples. However, for the purpose of this discussion I’m considering a game as having co-op if it fulfills the following:

  1. The co-op portion of the game is played with two or more players (obviously)
  2. These players need to work within the game’s intended design to accomplish objectives, which in turn move the game forward (co-op must be implemented by design explicitly – as an example of incidental co-op, consider a PVP server in WoW where players of opposing factions help each other out instead of attacking, thus an unintended by-product of the players’ choosing).
  3. For this post, I’m also not considering games such as Dead By Daylight, since those are combinations of co-op (the survivor team needs to work together to escape) and player-versus-player (since as a team, they’re actively working against the killer player) and thus, while  excellent examples of asymmetrical design, are beyond the scope of this post.

Further to the above, we’ll also be looking specifically at asymmetrical co-op design – while asymmetry in games takes many forms, from map design to team balance and a multitude of other variables, we’ll be looking specifically at the two-player puzzle variant, which in essence works by limiting each player’s access to specific and exclusive sets of information and interactions, then making both sets necessary for completing the game.

With the above in mind, let’s have a look at a game I recently had the pleasure of going through – We Were Here, the free-to-play first entry of the titular series, with two games currently released and a third one slated for a 2019 release (We Were Here Too and We Were Here Together, respectively). 

In We Were Here, two players take the role of a pair of explorers taking refuge in an ominous castle during a snowstorm. Separated upon entry, players are tasked with navigating the castle’s various traps and puzzles, armed with only their wits and a walkie-talkie tuned into their companion’s frequency. From there, both players must communicate with one another, providing a back-and-forth of clues, questions and panicked exclamations while they try to guide one another to the exit.

…and the explorer’s side as well.

Upon creating a session, each player is assigned one of the two available  roles – explorer or librarian. These are more than fancy titles, though, as they determine which part of the castle each player will start in and are unique (meaning that you can’t have two explorers or librarians in the same session). As the librarian, the game is mostly limited to a single room, filled with a multitude of interactive props such as maps, books and valves, while the explorer has access to more extensive levels, with a large variety of indoors and outdoors locales, including mazes, gardens and crypts.

This is where the “asymmetrical” part of the design really kicks in – for the majority of the game, the librarian’s role is to rummage their limited surroundings for clues to feed to the explorer, who is doing the bulk of the legwork. As an example, in one of the early puzzles the explorer is tasked with navigating a maze of rooms and passages while finding a series of color-coded switches that toggle gate sets in said maze, of which the librarian has a map of. Thus, the librarian takes the role of navigator, trying to direct the explorer (always via walkie-talkie) towards the correct sequence of switches, while the explorer attempts to follow the instructions and provide accurate feedback.

What I find most interesting in this approach to asymmetry is the way the developers have given the game a sense of urgency, mainly by limiting player communication to the walkie-talkie system (essentially VOIP via Steam’s API) – a lot of the puzzles in We Were Here are built around the players’ ability to quickly and accurately provide information to one another. A good example of this is a flooding room encountered early in the explorer’s route – the librarian must be quickly provided with the correct color combination of valves to shut off, in order to halt the water flow to the explorer’s side. With just voice communication, this becomes inherently more stressful and (since it’s done correctly, i.e. a generous time limit is given for new players to realize what to do) incredibly fun, in an edge-of-your-seat kind of way.

While asymmetrical design isn’t a new thing in gaming (with games such as Unreal Tournament experimenting with asymmetrical modes like Assault as early as 1999 or games with character stats eventually evolving into the class-based MP FPS sub-genre, Team Fortress being a good example), it is interesting to note that the puzzle co-op variant is relatively new in mainstream appeal – in fact, aside from We Were Here and its sequel(s), I can only thing of one more example in this genre, Keep Talking And Nobody Explodes which, in the same vein has one player defusing elaborate bomb setups while the other guides them through the process by providing specific info from a bomb-disposal manual.

So, what makes a goo asymmetrical co-op puzzle game? Using We Were Here as an example (as I’d consider it an excellent, if slightly too short game) we can extract a few good examples:

The game’s visual design is interesting, but not to the point of distracting from the puzzle design.
  1. Communication between players must be facilitated in a precise, functional manner. In our sessions, we found this to be of the utmost importance, as the explorer would often need to convey concise information to the librarian as they would often be in immediate danger of dying (and would thus need info on how to escape fast.)
  2. Puzzle design must be simple enough to describe over the communication channel, yet complex enough to feel like an accomplishment once the puzzle is solved. In We Were Here, this is mostly achieved by using modular puzzle design, where each puzzle is made up of smaller individual segments that are simple in design (and thus easy to communicate to the other player). In doing so, the developers allow players to easily and precisely describe each element to their companion (see point #1), while also building said elements into a larger, more complex (and therefore more satisfying) puzzle.
  3. If possible, recycle as few puzzle assets as possible and vary segment design. A lot of the puzzles in We Were Here feel “fresh”, mainly because the developers take enough care to provide variety in their design. While the puzzles are few in number (around five or so “main” puzzle rooms to get through), there are significant changes in what each puzzle’s solution calls on (be it spatial awareness, lateral thinking, logic, riddle-solving, and so on) which helps each room feel unique and interesting to work through.
  4. Allow for moments of tension, as well as moments of calm – use the two to keep the pacing interesting and variable. We Were Here performs admirably in this, with pacing alternating between tense, life-or-death moments and calm, logical ones. I feel that, had it leaned towards either one of the two more heavily, it would have suffered by either becoming too tense (and taxing to play through) or too slow (and boring or annoying to experience).
  5. Make sure that each player’s role is sufficiently different to the other’s. Again, the game is quite good at conveying this from the get-go, as it’s made very clear by the level design of the initial rooms that each player’s role is distinctly different – the explorer does most of the legwork and faces most of the danger, while the librarian handles the information-gathering and guidance aspects.

As an overall experience, We Were Here is interesting and highly enjoyable – perhaps a bit shorter than it should be (though I suspect this is intentional, as this first game is free to play and probably intended as a “demo” or introduction to the series, meant to draw players in) but still quite substantial and efficient in how it spends the players’ time.  If nothing else, it certainly made me and my co-op partner interested in the series as a whole.

For the record, a full playthrough (in which each player experiences both sides of the team) takes around 2 to 3 hours – I find this to be an excellent length of time for what the game sets out to do, being long enough to provide ample opportunity for observation but short enough to allow both players to fully experience it in a single session.

Have you played any co-op games recently? Any good examples of asymmetrical design you’d like to see discussed in this blog or with other readers? Drop us a line in the comments section!

A Casual Glance – Backtracking in Gaming

In A Casual Glance we’ll be having a look at various aspects of game design from the perspective of a casual observer (i.e. no hands-on experience in the games industry or professionally working on covering them, just as a player experiencing them) – this week we’ll be talking about how games implement backtracking with a few examples of how to best incorporate it and/or work around it.

For anyone that has been in gaming for any significant amount of time, the following scenario should be familiar: you have reached the end of an area (often a dungeon or military base or similar self-contained environment) and it is finally time to complete your objective – activate the self-destruct sequence, collect the Thing of Ultimate Power®, kill that pesky boss that’s been terrorizing the village… it doesn’t quite matter what the goal du jour is, just that you’re about to complete it. Once you do, a little popup appears – “Quest Updated: Return to town”.

And this is what backtracking usually boils down to.

Put simply, backtracking is what happens when a game asks the player to traverse previously-explored territory to return to its entrance point – often as soon as they have reached the other end. Trekking back to those quest-givers in World of Warcraft’s Barrens Crossroads to let them know you’ve killed 10 kobolds? That’s backtracking. Escaping the Ceres Space Colony after the self-destruct sequence is initiated in Super Metroid? Also backtracking. All that business with the shape memory alloy cards in Metal Gear Solid? Backtracking and more backtracking (and a very special example of what I call “Kojima Design”, but I digress).

It’s important to note that backtracking is a term (almost) exclusive to linear design (since open-world/non-linear content is by definition designed to allow for multiple options in traversing it) – so while the player might, for example, have to pass by the same settlement in Just Cause 2‘s Panau Island multiple times, the game flow is not specifically designed to force or encourage that and thus it would not be considered backtracking.

One of my most fondly-remembered games of its time, and one where backtracking is readily apparent.

Backtracking is a useful design in a some cases: implemented correctly, it gives a sense of structure and verisimilitude (since it “makes sense” that, for example, buildings have the same opening act as both entrance and exit in most cases) while it also doubles down as a time-saver in regards to content (since it effectively doubles any given game real estate in size by having the player traverse it twice). Unfortunately, this is also where care must be taken, as any failure in masking its existence often leads to player fatigue and, in extreme cases, boredom.

I recently replayed Grim Fandango in its most recent, remastered iteration – it being one of my favorite games of its day, I had played it enough times in the past to remember all of the steps needed to solve the majority of puzzles in the game. This in turn led to a mostly linear experience – I was already familiar with what needed to be done to progress at any given point and thus could effectively avoid the illusion of open-ended design that first-time players would experience.

Unsurprisingly, when played as a linear experience, it quickly becomes apparent just how much Grim Fandango’s design relies on backtracking to increase the game’s run time. Before we proceed, I should clarify that I don’t consider backtracking to be inherently bad or even implemented solely as a padding mechanism – as stated, it’s a great way to keep up the illusion of a more believable game world and I’m sure the team behind Grim Fandango intended it as such, at least partially (adventure games of that era were notoriously short on actual content, so it’s easy to assume that padding was in part a developer goal).

That being said, Grim Fandango is a very good example of backtracking overload. Playing it with a clear idea of where I was headed and what I needed to do, I would still be forced to traverse the same scenes three or more times over the course of puzzles. An early example of this (spoilers, beware) can be seen in Year 2: Rubacava, where one of the main objectives is to gain the Sea Bee “Official” tools for Glottis, which in turn allows you to board the last ship out of town. This involves inciting the Sea Bees to riot, which in turn requires getting their leader out of jail, which ultimately involves a city-wide hunt for a missing photograph.

Visual aid for the below mental exercise.

Sound straightforward? In theory, it is – distilled to its simplest, it’s a case of going from Point A to Point B to Point C, or rather, get clue 1 > get clue 2 > locate photograph > blackmail lawyer > get Sea Bee leader released > get tools from now-on-strike Sea Bees. The problem is that, due to how these objectives have been placed, a lot of back-and-forth is involved. In this example, you need to:

  1. Talk to Nick, the lawyer, until you can distract him and steal his cigar case. (VIP Lounge)
  2. Go to Carla and have the cigar case blown open to get the key to the lighthouse. (Security Checkpoint)
  3. Head to the Lighthouse and witness Lola’s death, get clue #1 – a tile. (Lighthouse)
  4. Head to Calavera Cafe and get the coat with the tile you found at the Lighthouse. (Calavera Cafe)
  5. Using the coat to gain clue #2 – a tattoo catalog design, head to the tattoo parlor (and solve a small puzzle) to check the specific design (Tattoo Parlor).
  6. Head to the Cat Tracks, solve a puzzle using clues obtained during the quest and produce a fake ticket stub, which can then be traded for an incriminating picture of Nick. (Cat Tracks)
  7. Head back to Nick, who agrees to help you free Terry, the Sea Bee leader, in return for the picture. (VIP Lounge)

Using the chart above, try following these steps and you’ll quickly notice that a lot of the time, due to how areas are linked, you’ll be traversing the same areas over and over and over again.

The problem is that, aside from becoming annoying busywork for older players, this also causes disorientation (in Grim Fandango’s case, also partially due to the badly-implemented combination of “tank” controls and fixed camera angles, although the remaster at least included a more traditional mouse control scheme) and in a few cases destroys any pacing the game had – after all, it doesn’t really feel like you’re racing against time when you are forced to go through the same crossroads five times in a row, right?

One of the ways this could’ve been fixed was dynamic actor placement, a fancy term for teleporting the protagonist closer to their objective once certain conditions are met (usually via cutscene or even just a plain fade to black). Amusingly, Grim Fandango already does this in certain places – the above example of a puzzle ends with game protagonist Manny Calavera and lawyer Nick being spawned outside the police station where Terry’s being kept, through a cutscene – which reinforces the belief that the rest of the backtrack-heavy sequences were indeed left in as a means of increasing gametime artificially.

So, how can a game “properly” implement backtracking, as I mentioned at the start of this post? Let’s have a look at some examples:

Dark Souls: Prepare to… unlock a shortcut?

The Souls series is a very good first example of how backtracking can be a positive inclusion if accounted for during initial design. From Software’s breakout meta-series has always relied on retreading old ground, whether it is a result of player deaths or general level layout. As far as I can see, this works for one simple reason: the level design takes the backtracking aspect into consideration on a very fundamental level.

Put simply, the levels are built from the ground up to allow for interesting traversal with multiple options even if the path itself is somewhat linear. In addition, the combat system itself accounts for this, offering a variety of options and encounters to keep things interesting over multiple runs through the same area. Finally, special care has been taken with shortcuts, special paths that can be unlocked once the player has progressed far enough into an area and which, once activated, provide an easy way to skip content that the player has already mastered (by virtue of managing to reach the shortcut in the first place).

Of course, there are several reward mechanics other than shortcuts in Dark Souls…

The interesting thing here is that, as the level design and combat systems support the design choice to include backtracking, so does it in turn support the risk vs. reward mechanics – reaching one of the aforementioned shortcuts is designed to feel immensely rewarding, as they often provide immediate access to safe areas such as bonfires or vendor shops and act as a sort of impromptu checkpoint from where progress can be regained in the event of death.

But then, not all games are (or should be) built around the idea of dying all the time, so how would a more “traditional” experience handle backtracking? Enter… Skyrim.

Dungeons and Dragonborn

At the start of this post, I noted that backtracking is a design aspect that is mostly, if not exclusively, found in linear games, so how can Skyrim, one of the poster children for open-world design, possibly have any? Easily, as it turns out – while non-linearity forms the majority of Skyrim’s design, there is one exception: dungeons.

Dungeons in Skyrim (especially optional ones) are primarily linear affairs – one entrance/exit, a long trek from start to finish with some traps/monsters/treasure to interact with, an objective at the very end – and due to their level design, should require a large amount of backtracking to exit once fully cleared. Whether it’s a nefarious vampire lord hiding out in the deepest part of his lair, a Dragon Wall built at the very far end of a temple or a Dwemer ruin hidden at the bottom of a sprawling cave system, you should invariably be heading through it all in the opposite direction once you’ve completed them.

With a reported 340+ locations to discover and explore in Skyrim’s mountainous landscape, it seem like backtracking would become a big problem and yet it doesn’t – mostly because, once again, special care is taken to properly incorporate and even take advantage of it in level design.

Quite amusing how an open-world game does linear content (and manages backtracking) better than many of its peers.

In this case, the game’s developers have made sure to include a “return path” to the majority of the game’s non-story dungeons – in essence, an extra bit of the level which bridges the end-point to the entrance and, more importantly, is only accessible once the player has reached the end of the dungeon. A barely-hidden path behind a movable wall; a door that can only be unlocked from the endpoint of the dungeon; a jump-off point which deposits you in the lake at the base base of a waterfall once you’re done climbing – no matter how, there’s almost always a way to quickly return to the entrance of a dungeon (and by proxy, the overworld and the rest of your sandbox adventures).

As with the Dark Souls example, Skyrim’s solution to backtracking allows it to extend the experience but counteracts the inherent annoyance and eliminates the tedium associated with it, as these return paths are previously-unexplored content that might also contain rewards of their own, as well as feeling a lot more natural than a forced teleport cutscene. An elegant solution overall, though in this case it comes at the cost of diminishing the verisimilitude of the world – after all, after finding the 20th or so return path you’re starting to wonder just how uncannily lucky the Dragonborn seems to be, if they’re discovering so many shortcuts everywhere they explore.

Even so, I find this to be an acceptable sacrifice – perhaps a more elegant solution can be reached in a more linear or less content-heavy game, but at least this method is a good starting point and an excellent example for future games.

Have you ever played any games that require excessive backtracking? Got any examples of your favorite games handling it in an interesting way? Share below in the comments!