Many games feature certain mechanics or interactions that are exclusive to a particular context, and are only used a handful of times. They may be specific to an environment or playable character; or they may be too simplistic to keep repeated use fun and novel.
This type of context-sensitive mechanic can be tricky to implement – you generally don’t want to tutorialise and spend time on something that the player will rarely encounter, but you also need to clearly communicate what the player needs to do.
This article examines a specific situation in the game I am currently developing (8-Bit Adventures 2), and demonstrates how I approached this problem. It’s a very simple example and certainly nothing unusual if you have much experience with Game Design. But I think the ideas behind it are good to keep in mind when approaching certain aspects of designing a game.
To provide some context, the game is a 2D RPG in the vein of traditional Final Fantasy, Dragon Quest, et al. If you’re unfamiliar with the genre, RPGs are generally broken up into three parts – the Overworld, Towns, and Dungeons. The example I’m about to use comes from the game’s first dungeon – a Sewer themed area (very original, I know!). Dungeons are generally the most dangerous places in an RPG, but also feature plenty of treasure and generally some sort of light puzzle-solving or other unique interactions. As such, context-sensitive mechanics are fairly common in these types of environments. But let’s talk specifics.
The moment the player sets foot in the dungeon, they can see a treasure chest across the water to their right. The vibrant colours of the chest help it to stand out in this environment, making it immediately noticeable. The player has been taught that treasure chests always contain useful items and rewards. An object like this feeds into players’ innate sense of curiosity, and so they naturally want to open it and learn what’s inside.
They've also been taught that a treasure chest is something attainable – so even though there’s not a clear and direct path, they know that there is almost certainly a way to reach the chest. And that knowledge is critical when it comes to teaching the player without the need for tutorials or other intrusive elements. It’s not the best analogy, but you can think of the treasure as a carrot on a stick – leading the player in the direction you want them to go.
In this first room, the player has two options – they can either go left, away from the chest; or take the path leading down. Because this second path is placed much closer to the chest, there is a clear distinction between the way that leads to progress and the way that leads to treasure (a common trope in RPG Dungeon design).
Along this path, the player will be introduced to two new, but very simple, mechanics. Firstly, they reach a pool of water, containing floating crates and barrels. It initially seems to be a dead end.
However, the player knows that treasure chests are attainable, and they can see a path leading upwards on the other side of the water. They may also notice an unusual pattern of objects in the water. If the player experiments, they will discover that holding right while standing next to the floating crate allows them to jump to it. And with this new-found ability, they can cross the water and continue on towards their goal.
While jumping across evenly-spaced objects like this is not a very common mechanic, it is used a handful of times in this dungeon and sparingly throughout the game – including an important example that occurs shortly after this introduction.
The player is now able to reach the treasure chest. However, they can’t open it from behind, and a barrel is blocking the way! Once again, though, the player knows that if there’s treasure, it can be obtained. And with no obvious solutions, they’ll start experimenting.
Because 8-Bit Adventures 2 is an RPG, the player has only a couple of ways to interact. They can turn around, walk, open the menu, and press the action button to interact with people and objects (such as treasure chests). If the player faces the barrel and presses the action button, they will find they can push it into the water. Not only does this open the way to the treasure chest, but it also creates a handy short-cut! The player can now simply hop across the water to get back to where they started, eliminating any need for backtracking and putting what the player just learned into practice.
And that’s it! The player has reached their goal, and in the process learnt new ways of interacting with the environment. And best of all, they’ve done it without any intrusive tutorials, so it feels like more of an accomplishment! As I said before, it’s a very simple example. But I think there are some key tenets behind it that can be applied fairly universally.
- A Goal – Providing the player with a clearly visible goal (or reward, in my game’s case) is vital. When you’re trying to organically teach a new mechanic, it’s important that the player can see what they’re trying to accomplish or where they’re attempting to reach. This means less chance of them getting lost, or confused about what they should be doing. Essentially, it’s like teaching in real-life – if you give students a reason to learn something, then they’re generally more enthusiastic and focused on doing so. And, of course, if it’s suitable, a reward (such as treasure) is great for reinforcing success!
- Same Methods, New Interactions – The debris-jumping and barrel-pushing mechanics were new to the player, however they both used methods of interaction that the player had already become familiar with. Specifically, holding a directional button to move and using the Action button to interact with an object. This keeps things familiar and prevents the solution from feeling obtuse or out of place – despite this specific mechanic only being used a handful of times. If this doesn’t apply to your context-sensitive mechanic, and you need to use a brand new button or control method, then I would personally recommend tutorialising it in a more obvious or traditional way.
- Keep it Quick – I’ve always found that good pacing is extremely beneficial in games – even in small sections like this. As such, the action of reaching the goal and executing new mechanics should be quick and simple. The process of getting the treasure chest described above will generally take players less than a minute. They aren’t bogged down by any sort of tutorial windows or exposition, and none of these new interactions take very much time or interrupt the pacing or game flow. Additionally, as a result of pushing the barrel, the player opens a short-cut – allowing them to easily bypass any possible backtracking and immediately proceed with the dungeon.
Finally, it’s also worth considering how often a context-sensitive element like this should be utilised. For example, the object-pushing mechanic is only used twice in this dungeon, while the jumping mechanic is brought back several times (albeit sparingly) throughout the entire game. As a general rule, I’d say that using a context-sensitive interaction once is too rare; at that point, I’d personally re-examine whether it’s necessary or adds anything to the game (and it may! It’s just worth considering). Twice is generally the minimum, in my opinion - and sometimes that’s enough. There’s no hard-and-fast rule (unless you decide to use the Rule of Three!), but ideally this type of mechanic should remain a novelty, instead of overstaying its welcome.
The goal of this article was to demonstrate one approach to organically teaching context-sensitive mechanics, without interrupting the game’s flow and also providing players with a sense of personal accomplishment. This is my first time writing an article on Gamasutra, and I’ve been mulling over this concept for several months now, so I sincerely hope it proves useful to someone. Thank you very much for reading!