Making the Darknet Tutorial

[cross-posted from the Darknet dev blog]

Like everyone else, I hate tutorials. The mere word conjures visions of long, lecturing paragraphs and big, orange “CLICK HERE!” arrows. Blech. Tutorials aren’t always so bad, of course, but it feels like the best a tutorial can do is blend into the background, unnoticed. They might be a prerequisite to fun, but they aren’t fun themselves.

Alas, a tutorial seems like a necessity in my own game. If Darknet were a twist on a typical genre like a platformer or first-person shooter, perhaps I could get away with some subtle control prompts here and there. But Darknet is a much weirder game, and so more instruction is required if I want the game to be accessible to the average player.

In Ciess, the 3-week game jam prototype of Darknet, there was a clearly separated tutorial section. You had to click on a big button labeled “TUTORIAL”, and then the game would tell you what to do for about 5 minutes. Hopefully, by the end, you understood how to play the full game. This wasn’t such a terrible design decision at the time; players were still kept entertained by the whiz-bang novelty of the VR interactions, and besides, I didn’t have the option to do much iteration thanks to the limited development time. But, still, I’m pretty sure that it’s a classic example of what not to do with a tutorial.

To get an idea of what I should do with a tutorial, my best source was George Fan’s excellent GDC talk about creating a tutorial for Plants vs. Zombies. He lists 10 great tips, which I relied upon to help make Darknet’s tutorial better than the ugly monstrosity in Ciess.

As I mentioned, the Ciess tutorial was separated from the main gameplay. It was almost entirely linear, blocking off any actions except for whatever it was currently prompting the player to do. At each part of the tutorial, it would tell the player what to do via a voice prompt, which would eventually repeat if the player didn’t act soon enough.

This had a few big problems. First, nobody likes clicking on that “TUTORIAL” button, so I knew it would eventually have to be integrated into the actual game. Second, nobody likes a tutorial that feels like it’s controlling the player rather than guiding them (see Egoraptor’s Mega Man X video for a particularly strong expression of this sentiment). Third, even though it was so heavy-handed, the tutorial was still pretty bad at teaching the more advanced mechanics. The details in the voice prompts were easy to miss, and because it was all presented out of any real context, players had a hard time remembering it all after they started playing for real.

I gradually tried to build a better tutorial over several months, and you can see some of the in-progress work in the old “flavor demo” that was built for PAX East. Eventually over several iterations, I settled on a much more decentralized tutorial system. The basic concept is this: instead of one linear sequence, there are about 20 separate “phases”, each of which represents some small snippet of instruction (like “press the X button to open the menu” or whatever). Each phase has its own set of triggers and prerequisites, a short voice prompt, and a small UI panel with a bit of text and an illustration.

At the very beginning of the game, a full-sized level is loaded up, and there is a very brief linear sequence that introduces the most basic controls and interactions. After that, the player has almost complete freedom. Since each phase can be triggered and completed independently, the phases can be held back until an appropriate context. Some don’t even show up until much later in the game, when the player has unlocked more advanced mechanics.

This system solved the biggest issues: it was integrated into the game, was much less controlling, and taught the mechanics in a slower, more effective way. The addition of the visual panels also helped fix some of the weaknesses of the voice-only approach.

There were still a lot of issues to solve, though. For example:

- UI placement: In a VR game, where do you actually put the panels? There’s no way to overlay text on the screen in VR; everything has to exist somewhere in the world. At first, I put the panels near relevant objects, but this inevitably blocked part of the player’s view of the world, and if the player was looking in the wrong place, it meant that they wouldn’t see the panels at all. Then, I moved the panels into the player’s lap, so the player could look down and see them at any time, and so that the panels wouldn’t block the view of the game. Instead, I found that players would never look down, and they never even noticed that the panels were there. My current solution is to grab the player’s attention by popping up the panel directly in front of their view, then let it drift down into a more comfortable position. This is effective, but I still worry it’s a little heavy-handed; it can be annoying for things to spontaneously appear 2 feet in front of your face.

- Managing player attention: Usually, a tutorial phase was triggered during some gameplay event or transition. This meant that the game was trying to teach something during the game’s most interesting and distracting moments. Naturally, players would watch the game and ignore the tutorial. I was mostly able to mitigate this by tweaking the timing of the hints so that there was less overlap. Players were also distracted whenever the text on the panel was different from the voice audio; it was impossible to listen and read at the same time. In later iterations, I made sure that the text and the start of the voice prompt matched as much as possible.

- The sheer amount of information: Over and over again, I went through the tutorial text and tried to make it shorter and shorter, hoping to reach George Fan’s suggested maximum of 8 words. It was hard. I also tried to reduce the total number of tutorial phases; after seeing too many in a row, it started to feel like an information bombardment, regardless of the contents. Whenever a player got confused, I had the urge to solve the problem by just adding another tutorial phase. I tried to fight that urge and delete some extraneous content, but that was tough. After all, I had a wonderful hammer, and every problem looked like a nail. Rationally, I know that you sometimes just need to let the player be frustrated or confused for a little while to figure it out for themselves, but it’s not easy to be so hands-off in practice.

- Difficulty: Now that it was integrated into the main gameplay, there was actually some challenge involved. Since I was essentially an expert at the game, I had no sense for what an appropriate level of difficulty looked like, and I didn’t want it to be insultingly easy. This was the wrong priority. When it was too hard, players were essentially forced to master the mechanics right from the start, instead of having time to experiment and develop strategies. Eventually, I rebalanced everything to make the start of the game much easier, and then I repeated the process a month later when it became clear that I hadn’t gone far enough. Now that the tutorial feels absurdly easy to me, it’s finally appropriate for new players.

I’m still iterating, adding and removing phases, and tweaking the details, but I’m pretty happy with the tutorial at this point. I finally don’t feel like I need to apologize anymore or give extra hints from over the player’s shoulder. It’s not an ideal, fully integrated tutorial, but I think it does a good job of pulling players into a very unfamiliar game and giving them the tools they need to conquer it. I can’t quite say that I enjoy playing the tutorial, but I think it serves its purpose well.

- @E_McNeill