When creating a new kind of game, the only rule is that you need to be playtesting as soon as you possibly can. It’s only when you actually start playing that you know whether your ideas actually work as the basis of a game. As soon as we settled on a general direction for our game – but before the code was playable – we starting making paper prototypes.
The picture above is from a playtest that used generic game prototyping pieces (and a set of rules) to simulate the space of our game – characters, enemies, resources, walls, etc. Obviously paper prototyping has its limits, but it can be extremely useful as a way to get an early glance at some of the particular functions of a game. For example, the prototype above helped us understand what elements contributed to the feeling of exploring a mysterious space, beset on all sides by potential threats.
What are the limits of paper prototpying? One danger is to try and make the paper prototype fun in and of itself – this can derail a game design process, because suddenly you are creating a board game, not a videogame! If your paper prototype becomes too enjoyable and loses that weird, slightly awkward feeling of being a simulation of elements of a videogame, watch out! You may be falling into the trap of making your paper prototype a fun game.
Another danger is that too much paper prototyping can lead to “boardgame-itis” – a videogame design that relies too much on what makes boardgames work. We often don’t appreciate how sophisticated board games are in terms of density of information: the average strategy boardgame displays much more simultaneous information than the average videogame. For example, if your videogame design ends up relying too much on the ability to see all of the details of a complex map, or relies on a strong sense of resource economies (ie, the game is a third of the way through a deck of 60 cards), or even just relies on the fact that a player knows they are rolling 2D6, your videogame may wind up with boardgame-itis. The final game will feel opaque and hard to understand, even though it worked really well as a paper game!
We reached a point after a couple weeks of paper prototyping LIBRARY where we realized we were using tokens, cards and pieces to track a whole lot of information. Some of this prototype game state consisted of the kind of information that a computer could track much more easily than a human “game master,” and which wouldn’t necessarily be something a player of a digital game would need to know about at all. We felt like other aspects of the game would necessarily evolve in the transition from paper to screen in order to avoid “boardgame-itis” in our information display.
Paper prototypes can be incredibly useful – as long as everyone understands their pitfalls and limitations. In any case, at this point in the development of LIBRARY we have moved from paper prototyping to digital prototypes. It’s still super-important to be playing the game as much as possible throughout development – just switch to a digital version as soon as you can.