Hey everybody, it’s me again: your friendly neighbourhood game designer, here to have a little chat about tutorials and teaching in games in general, and in Cave Digger 2 in particular. 

 

The first thing I did when I joined the Cave Digger team was to play around in the first installment of the series. And the first thing I noticed when playing Cave Digger 1 was that it really didn’t hold your hand much when it came to teaching and tutorializing features. Sure, the very basics of “PICK UP PICKAXE” and “SWING PICKAXE TO WALL” were there, but once you ventured out of the saloon and discovered the train and the rest of the world you were on your own. This sense of old school, discover-it-for-yourself gameplay was a big part of the design ideology of Cave Digger 1. 

 

So you can probably imagine Jaakko’s face when I told him that this time around, I wanted to focus on teaching and tutorializing things so that the players in turn could focus on enjoying the gameplay instead of spending time figuring out how to play. [INSERT SURPRISED PIKACHU FACE HERE] Luckily he’s a sensible man, and it didn’t take much convincing to bring him around.

Teaching gameplay is a tricky beast. First of all, you need to try to recognize features that need teaching to begin with – stuff that is new, hidden or particularly unintuitive when comparing your game to other games of the genre. Teaching VR games is trickier still, since the standards of gaming for VR are still forming: whereas it seems a little ridiculous to have an extensive tutorial section for “use WASD to move, E to interact” in a flat-screen PC game, in VR you essentially need to start with movement and interaction, since the “language” of gameplay isn’t standardized yet. The fact that there’s a massive variance between different controllers and devices does not help this challenge one bit. 

The general rule of tutorials in games is to teach a thing once while holding the players hand – instruct the user with textual and visual guides and cues – and then make them repeat the activity several times on their own, preferably in quick succession right after you showed them how to do it. For example, in a game about punching boxes you’d tell the player that “punching red boxes gives you points” and force them to do so, then introduce a room full of red boxes, which they can only leave once the boxes are well and truly punched. Then after a while you can add variety: after several rooms full of red boxes you can introduce a yellow box, and safely assume that the first thing the player does is try to punch it. Whether the yellow box then gives them extra points or explodes in their face depends on the game and genre.

Finally, there’s a difference between teaching moment to moment gameplay systems (“how to punch boxes”, or in our case “how to dig walls”) and structural gameplay systems (“the game consists of 8 worlds, with 4 levels each”, or in our case “a mining run consists of 3 levels, with a special room at the deepest point”). I tend to try to think of teaching gameplay structures as navigation or orienteering – our job is to give the player a clear path to follow until they know the terrain well enough to set their own goals. 

 

We’ve done a bit of testing with live subjects – our initial tutorial efforts, built on my best designs, entirely stymied 2 kids AND 2 adults in their tracks after 1 minute of gameplay. That was a bit of an eye-opener, and a very necessary part of the process. We’re currently going through the feedback from the Steam Next Festival earlier this summer, and adjusting our early-game teaching sections accordingly. In general you all were super active, and the feedback was super useful! Please keep talking to us once the Early Access opens up! 

 

I now realize that this piece became a bit of a ramble, so maybe I’ll get back to the topic at a later date: there’s certainly much more to say here.

 

Cheers,

AMP

Random development quote: “Pelasin äsken pihalla pesistä shrimpyllä, Hannes syötti ja meikä mäiskäsi mailalla. On tääkin peli“.