Teaching the Player Without Intrusion - Creating The Tutorial

An Introduction

     Tutorials are one of the most arduous tasks a designer can be challenged with designing. A tutorial needs to teach concepts to the player, while also remaining engaging enough to the player.  The tutorial also needs to communicate the "game language" effectively, and by the end of it the player should have a good understanding of the game and feel eager to learn more about it in the following gameplay. Tutorials are better off used for teaching things like controls and core mechanics, while other facets of the gameplay can be instructed through exploration or level design as the player progresses in the game. 

     Jungle Jim has many platforming techniques at the players disposal, and even includes advanced "movement extensions" which add to the platforming skill ceiling. Because the game includes less-experienced players in its target audience, the skill floor is designed to be still very low, but a lot of these movements are such that the player is not likely to discover them on their own. One of the games core experiences I want to invoke is "freedom of expression through movement", so it is important that the player understands some of the movement tools they have access to as they start to form their own platforming style.

With that said, I knew the game needed a well designed tutorial. This excited me, as tutorials are often regarded as one of the hardest things to design for a game and as a game designer breaking into the industry, I was eager to prove my chops. 

Little did I know just how difficult the task really was. 

Goals:

I had a number of goals I wanted to reach for a successful tutorial:

1. Teach players all of the base inputs/controls of the game.
2. Communicate many of the mechanics through level design.
3. Teach the player in an unobtrusive way.
4. Teach the player quickly and allow the tutorial to be bypassed if the player already has the skills.
5. Show the player the "language" of the game.

     By using playtesting, I slowly learned how players from all ranges in my target audience felt, and slowly improved the tutorial over time to accommodate both of their needs and interests better.

Teaching Inputs / Controls

     First, I created a list of every input/mechanic I wanted the player to have an understanding of during the tutorial, and then I started creating a loose order that logically made sense to teach these in. That list looked something like this:

• Walking
• Jumping
• Hold jump to reach higher
• Ledge Cling 
• Object Interaction
• etc.

     Many of these mechanics are quite basic, and require no need to point them out specifically(such as walking and jumping). But my target audience includes gamers with less experience, so it is important to teach those too, especially for a 3D platformer which is a genre less experienced gamers struggle with due to movement in 3D space being troubling. These mechanics are still taught, but more subtly. I will go over the beginning area of the tutorial to explain.

1. The player is first in a closed room with one way out straight ahead centered on their screen. This urges them to walk forward.
2. The player proceeds to see pits. The last pit is required to jump over to clear. Mural (explained later) shows jump input.
3. The player is forced to discover that holding jump increases height. This also teaches that ledges can be grabbed and mantled.

     In this short span of time, the player should learn very basic concepts for the game--all without any intervention. I used techniques like this all over the tutorial level to teach the mechanics on my list that didn't require specific instruction.

     To teach players more advanced mechanics, I wanted to stay away from forcing the player to read long texts to learn. Many of the games I love have tutorials that teach the player without needing text, and will use level design or imagery to teach the player. While I haven't played it myself, a good example of this would be Cuphead. Cuphead's tutorial doesn't stop gameplay, but rather uses arrows, images, and text in the background to assist the player in learning. 

     For my game, I had an idea to use magical animated wall murals to teach the player mechanics and the inputs required to do them. The concept fits the setting and themes of the game, and the animated aspect would allow the player to see the order of inputs which was important for some movements.  (The mural shown is still an early block out)

     At the time of writing this, the murals are implemented in the level and do succeed in teaching the player inputs, however, I also had one oversight with them. Due to their animated nature, the player has to stop and watch the mural in its entirety in order to understand the move.

      The murals are only 1-2 seconds long so for most players this isn't an issue in the slightest. But the other part of my target audience that has experience in platformers would sometimes feel as if they had to stop playing the game in order to watch the mural. Viewing the murals is completely optional and they could ignore if it they chose, but they would still feel pressured to watch it because they felt a strong desire to learn the game inside-and-out to compare with their favorites. However, they didn't like having to stop moving to see it. 

     In Cuphead, this isn't an issue because the game is 2D and the camera has a great view of the image no matter where the player is positioned. But this game is in 3D, so the same trick doesn't have the exact same effect. The current version of the mural can also be hard to see at a glance, especially if the player doesn't have experience maneuvering a camera in 3D space. 

     The solution to this? I have not found one yet. I could possibly make the murals appear in the games UI, but then players would dislike it blocking their view of the screen. The murals are not intrusive because they are completely optional, but the major takeaway I have here is that for some players,  "they can be hard to see, and can be annoying to stop moving to watch".

Optional NPC Guides:

     As mentioned earlier, the games movements have "extensions" which are inputs the player can perform during movements to do a new movement or extend the current one. Similar to a combo system, but now it's like a "movement combo". These are completely optional, but add to the feeling of mastery and expression of movement. I wanted this information to be available for advanced players that want to perform them. 

     At the same time, I wanted to accommodate for my less experienced audience and give them something optional that can explain the controls and movements for players that struggle to inherently understand them. 

     With these two ideas in mind, I added an optional NPC aptly named "Tut" that is placed around the tutorial level that will explain the moves depicted on the murals. The NPC explains the general move and the input for them, but will also go further and explain the extensions or use-cases of the move. The NPC also keeps dialogue fairly short, usually 4 lines maximum with the longest being shown below. (Tut shown below has no model or textures yet, placeholder capsule.)

     Playtesters had a mixed reaction to this NPC. Some of them appreciated having the option of getting advanced tips and tricks explained, and others also needed the information explained to them and it was more convenient for them that way. On the other hand, some players felt like they HAD to talk to the NPC's even if they didn't want to. I was not able to get a clear answer, but they did genuinely feel that way.  It is possible that they just couldn't resist interacting, kind of like a "shiny red button" if you will. Though I have yet to understand why many players see optional aspects of the game as something they are required to do, and that is something I hope to understand some day so I can learn how to accommodate a broader range of players even more.

Tutorial Length and Unobtrusive Nature

      My goal for the tutorial length was no longer than 15 minutes. I accomplished this, with playtesters generally falling in the 9-12 minute range. One important thing with a tutorial is that it doesn't wall the game. Keeping the length on the low-end absolutely helps new players manage any frustrations with tutorials feeling too long or obtrusive to their experience. 

     Another important aspect is how the tutorial affects replay value. If a tutorial is too demanding, players will be far less likely to replay the game. In Elden Ring, upon starting a run players will encounter a boss right away. This boss is designed to defeat new players, which makes them respawn in the tutorial area. However, experienced players are able to bypass the tutorial if they can prove that they have the skills already. This was something I wanted to implement into Jungle Jim...and I did!

In order to perform this tutorial skip, the player must demonstrate skill for the following movements:

• Triple Jump
• Wall Step
• Wall Jump
• Flip Kick
• Dive Kick

Cutscene

     The tutorial features a cutscene which I had a fair bit of trouble with implementing. Cutscenes can be very annoying for some players, while necessary for others. The main pain point for players is when a cutscene is unskipable- so I made it so that all cutscenes in the game can be skipped! At the beginning of every cutscene, the bottom left of the screen will inform the player that holding Start will skip the cutscene.

     However, that was not the end-all for my issue. Even with my cutscene being skippable, some players were still unhappy with the presence of the cutscene, but they were unable to point their finger at a reason why. After watching a few players and thinking, I was able to figure out the root of the problem.

     The root of the problem was that the cutscene started abruptly. The player was in control of the character, and then without warning it was taken away. Even if they could skip the cutscene, the control being taken away for them so suddenly is what was actually unsettling them about it.  The area they were walking into did not look like it would start a cutscene, and there was no indicator to signify that something would happen if they stepped into it.

Here is a clip of how the cutscene started BEFORE fixing the issue:

     In order to  fix this issue, I needed the player to feel like they were the one's starting the cutscene. By adding an indicator for where the cutscene starts, the player can start the cutscene at their own pace and through their own decision.  To push this even further, the whole cutscene starting itself became optional. 

Here is a video of the cutscene area AFTER changes:

     If the players want more story, charm, and direction in their experience then they can step into the indicator to start the cutscene. If they change their mind, they can skip the cutscene.  If they are only half-involved, they can press A to speed up the cutscene text. If the player ignores the indicator and places the relic to open the first door, the indicator will disappear as the player's intention is clear: they do not want the cutscene, just the game.  

     By using this cutscene as a tool the player can choose for themselves, players are much happier with the outcome of this area now that it is entirely within their control how much they will learn and when their control is taken away. This change ended up helping in other areas too. Previously, for an experienced player replaying the game, they would have to enter the cutscene first, skip it, and then jump over the wall to skip the cutscene. Now, they only need to jump over the wall and can avoid the cutscene entirely. 

     This also however, created more scenarios for me to account for and program. Notably, if they player decides to collect the relic without watching the cutscene, different logic needs to play and a different cutscene needs to play. I am well capable of doing this, it was just more work to do to make the game a better experience for players. 

Communicating The Language of the Game

      Quite possibly the hardest part of creating a tutorial is having to do ALL of the previous points, while still being able to communicate your game's language. A game's language is the game's flow. This involves questions such as:

"How does the game actually play?"  

"What expectations should the player hold for each level?"

...etc.

This is the major point that I feel my tutorial is failing in. The main reason for this is quite simple though: the tutorial was the first level I made, so the language of the game doesn't actually exist yet. Yep. There are still many questions about the game flow that are not solved yet and will require playtesting real levels in order to get completely figured out. 

This has been a long devlog post, so I'll leave it at that for now. I would like to continue improving the tutorial even further, but I also cant keep working on the same thing forever or else the game will never get made.

I am still incredibly proud of the success in playtesting throughout this tutorial, and I can't wait to start working on the rest of the game!