This is part 4 in a series dedicated to musings on the craft of creating in-game tutorials.
“Where are my tools?”
I’ve seen projects where there was a great plan to deliver amazing tutorials but it was thwarted by a lack of authoring tools. In the previous post, I discussed the developers’ reticence for working on features that are only going to impact a limited portion of the game. This reticence will often manifest itself as a resistance to the development of tools. Tools do take time, they do require debugging, and the users – in this case, you and me – will often think of crucial features only after they started using the “finished product”, screwing up the development schedule (as if it needed more of this).
Nowadays, when I pitch an approach to tutorials to a team, I make sure that the required tools can be used in other circumstances. Your tutorial will have pop-ups? Then design it as a universal pop-up system so that future content could also feature pop-ups. You need to script your usually autonomous AI? Mention examples of missions where this could be useful in creating exciting scenarios. The whole point is this: It’s always better to develop tools that can be re-used but often, the simple possibility of re-use can be good enough to sway your lead programmer.
Do make sure your requirements for tools are as stripped down as possible. We would all love to have something that looks like a commercial product to help us ship our games. Sure, Unity, Illustrator and Unreal engine are awesome. But asking for your own equivalent to these products is akin to demanding the creation of a whole new business, just for your needs.
But there’s another, important point to knowing how simple a tool can be: Maybe you don’t need any help at all. XML and JSON files can be built from within excel, flash can export text files and bitmaps, all sorts of text editors out there can automate your processing. Chances are that you only need some basic technical knowledge to build your own tools and leave everybody alone. And the benefits are numerous: You’ll gain respect from your peers, you’ll save time to a lot of people, you’ll learn about tool creation, and you’ll actually develop a better understanding of the game you’re building. I once built my own level editor out of an excel spreadsheet for a tower defense game and this has allowed me to make at least 5 iterations of every single level in the game, in just a few days. In the end, I knew the technology better, I got better at balancing the game, I was happy with the levels we shipped, and the engineers got to spend more of their time on the actual game systems. Oh yeah, one last thing: For all of this, there was no overtime.
But you’re still likely to need help, especially on more ambitious projects. In this case, you have no choice but to convince your teammates that tools are required, and very badly. Like any other feature, tutorials need to be authored, tested, updated, polished. But because of the nature of tutorials (see below), and because they can leave such a lasting first impression, you’ll probably have to tweak, balance, re-work and sometimes redo them completely. If you don’t have tools to do this yourself, your coding staff will be wasting its precious time just when it needs it the most: at the end of the project.
And do make sure that you can test your own creations as quickly as possible. There isn’t much point in creating great authoring tools if you have to wait for the next daily build to test your update.
If you had perfect knowledge of your tutorials and the reaction they got, you’d spec them on paper, and somebody could hard-code them. That would indeed be the quickest way, and I’ve heard staff actually express this wish. But my next point is …
Expect to iterate and test and iterate some more
Not everybody has fun the same way, not everybody has the same skills, and this makes game development quite a challenge. On top of this, not everybody learns at the same pace, or in the same way. Because players differ from each other so much, both in their ability to perform and their ability to concentrate on the instructions you give them, you have to be ready to playtest and adapt. Hence the need for tools because, the quicker you can implement changes, the more iterations you will be able to create, and the better the end result will be.
I urge you to scour the net for post-mortems on games that have great tutorials, or those that managed to make a lot of newness very approachable. The common thread is this: Even the brightest designers out there – especially the brightest! – will get feedback and act on it, instead of resisting it.
Here’s a quote from Socrates: “I appear to be wiser than he, because I do not fancy I know what I do not know.” In my experience, as designers evolve from junior to senior, they stop pretending to know what they don’t, and nowhere does this apply more to your users’ reactions to something they’ve never seen before. As experience sets in, game designers accept – and even enjoy – the fact that they have to go on a journey to discover their players’ feelings. Assuming that you can design spot on tutorials once and be done with them is a path to failure, unless of course you ship the same game over and over. But only a minority of us ship regular installments like EA Sports.
Conclusion: Tools for iterations
You need tools, because you need to iterate, because you accept that adjusting your tutorials to your players’ tastes is a lot like docking spaceships in orbit: It needs a gradual approach to avoid a catastrophe.
Never assume that you know how your players will react. Instead, plan for changes so that you can react to the feedback quickly and appropriately. Remember that, as the designer, you are the least able to put yourself in the place of someone who has never seen the game.
Soon, on ex Ludis …
Teaching how to think is much harder than teaching how to act. But the solution to this problem may finally make you popular with the marketing department.