A common request when pitching a game idea is “walk me through the first 5 minutes (or sometimes 30 seconds) of your game”. It is a question designed to weed out who has really thought out their ideas. The truth of the matter is that you need to convey a lot information concisely and elegantly at the beginning of your game. The objective of your introduction is to convey:
The ultimate goal of the game (save the princess)
The theme and setting (medieval fantasy)
The possibilities of the game space (sword play and casting spells)
Some sense of progression (collect the complete set of armor)
The cool and exciting hook, what players are going to find fun and interesting and keep them engaged. (usually something that makes players feel powerful)
At the same time that we are trying to meet these objectives, we also have to teach players how to play the game. Often tutorials are in conflict with introducing the game world to the player. Let’s work through some ideas on how to introduce your game and maintain player interest and motivation.
Note: Before we address introduction strategies it is worth mentioning that the first thing a player sees is an install or loading screen. Those are key moments to take advantage of - but they have a limited capacity to display information to a player.
Tutorials Often the default mindset on the beginning of a game is teaching the user how to play. Most games need some level of instruction and scaffolding; however, many tutorials are also poorly implemented. Typically tutorials are one of the last parts of a game to be built. Ideally there is a safeguarded budget of time so that the tutorial works seamlessly with the player. Often what happens is the tutorial budget is encroached upon by other features and bug fixes so that the development team is forced into the cheapest option - a rigid set of steps that must be completed in sequence where the player is “on a rail”.
Tutorials are not inherently a bad thing, but they are used often misused, particularly when making it the first experience of the player. There is a lot of over-tutorializing out of fear of the player getting stuck somewhere. It is also worth mentioning that while implementing the tutorial last, all of the developers have played the game hundreds of times. Developers become so intimate with the workings of the game that we can’t see its flaws and where there is potential for a player to get stuck. Tutorials are also often used as a crutch or band-aid - if there is a place where players are getting stuck the right thing to do is fix what is confusing, not add a tutorial explanation.
Tutorials usually just cover “how” to do something (press A to jump), and they regularly leave out the more important “why” (you will need to avoid obstacles). Furthermore, rarely does a tutorial do anything to reward a player. If instead you placed a reward so you would have to jump to reach it, you can indirectly guide the player to explore the game’s controls and their ability to interact with the game world. Despite a tutorial’s effort to teach, creating an intuitive environment of self-led discovery makes the player feel more empowered, intelligent, and has better retention than most tutorials.
If you have built an interesting and pleasurable experience, players will be motivated to figure it out. Most early games could not afford the extra memory for tutorials - Mario, Tetris, Mega Man. It is still an open question if tutorials really benefit players - it depends greatly on the type of game and the type of tutorial. If you start with your game with a tutorial “on a rail”, with the player pressing a button when you tell them to press it, the player doesn’t have to think - it is also as appealing as trying to watch a movie that continually stops, requiring you to repeatedly hit the play button to advance.
Video A player’s first experience does not have to be a tutorial. In fact, having to move slowly through the basics of the game is very inefficient at conveying the objectives of your introduction: establishing player interest, motivation, and the ultimate goal of the game. Beginning with a video is an impactful way to setup your experience without requiring any action on the player’s behalf.
As I mentioned in "Features that Add Value," video game production can be expensive, and since there is a high cost to make edits, videos are made late in production when the game isn’t likely to change. However, most games need marketing materials and an introduction video can serve both purposes. Just like with tutorials, there is a right and wrong way to execute on an intro video. While video can usually offer much higher production value, you should err on the side of keeping the video as true to the actual game as possible.
The Zelda series does a good job with its trailers. Without a single word of narration you can tell it is a game set in the medieval fantasy genre and the player is saving the world from an evil force contaminating it, employing a host of tactics to combat a diverse array of foes. Here is the actual experience the player has when they start up the game. The same story is told again in the latest Zelda game, Breath of the Wild.
Achievements Perhaps time and budget are prohibitive to writing an elegant tutorial, producing a video, or maybe you have very unique game. Achievements can be an excellent way to give your players goals. Just like other game systems, achievements can be implemented poorly. The worst kind of achievements are random progress markers - i.e. “Kill 10,000 enemies”. The best kind of achievement gives the player a reward for completing it, and communicates something about the game to the player.
Let’s take a look at the achievement system of Minecraft. The first achievement is “Press 'E' to open your inventory”, the second is “Attack a tree until a block of wood pops out”, and the third is “Craft a workbench with four blocks of planks”. These are instructions on how to play the game, and hints that encourage player-driven discovery.
I’m not sure that you want to begin your experience with an achievement UI screen like in Upgrade Complete, but implementing achievements is another option if you want to avoid starting your game with a tutorial, or even having a tutorial.
"Players don't need to know how to do something, they just need to know that something is possible."
- Stephen Calender, Game Engineering Team Lead
Every project is different and has its own unique challenges. I outlined a couple ideas, but there are definitely more strategies on how to teach the game, establish goals, and motivate the player. Whatever strategy you decide, remember:
When explaining the game, focus on why this information will be useful. Players don’t need to know how to do something, they just need to know that something is possible.
Rewards are powerful, particularly when they are tied to goals.
Inspiring and enticing the player is the best way to start an experience (that’s my philosophy anyway). You need to give players at least a small taste of the fun that awaits them as quickly as possible. That taste can be accomplished with a video, or by immediately giving the player control.
We can’t create a memorable experience that changes people’s lives if they stop playing. Players get frustrated when they don’t know how to take action or need a tutorial. Players also give up when a game is no longer rewarding and there is no sense of progress. It’s hardest to measure, but the majority of players are ready to quit once they believe the fun is over. My philosophy of fun is founded on the idea that the players most likely to endure a formidable challenge are those who have been motivated by fun.