Wooga is one of the biggest companies in casual gaming, which has seen a meteoric rise in the last couple of years. This is a highly competitive field, and consistently performing well as a company is no easy task. To remain a step ahead, Wooga heavily invests in prototyping games. In this session, Dominic Graefen, an engineer at Wooga, shared his thoughts on why prototyping is important, and how best to approach it.

First, it is important to understand that prototyping is not part of pre-production. While some prototypes may lead to a game going into pre-production, many will (and should) fail before that. The goal is to identify bad game mechanics early, before too many resources are invested in the project. Prototypes are about failing while it is still cheap to do so. Because of this, those involved in making the prototype should not become too attached to their work; prototypes should be as disposable as sketches in a notebook.

Teams working on a prototype should be as small as possible (but not smaller). A game designer who can code is often enough to get started. If more people need to get involved, it is important to maintain a flat hierarchy and keep overhead low. The process is about quickly creating playable versions of a game, and should not be bogged down by meetings and status reports. Managerial support is important as well. At Wooga prototypes are given the same priority as other projects, so teams can work uninterrupted until a prototype is deemed finished.

Developers should be mindful of not over-engineering a prototype. Even if it leads to a game going into production, the prototype code is likely to be discarded. For the same reason, the choice of technology can be arbitrary. Just pick whichever tool you are comfortable with: a tool that enables you to produce tangible results quickly. Flash is often used at Wooga, because it can be deployed to many devices (including web) and boasts a very simple asset pipeline. Unity is equally viable, although it is often not the best choice for 2D games.

Prototypes should be about features, not content. To this end, sounds and graphics for new prototypes at Wooga are taken from existing projects whenever possible. Such reuse can greatly speed up the development cycle. It also keeps the prototype from becoming too aesthetically pleasing, which is, somewhat counterintuitively, a good thing. People have shown to be less critical of gameplay if a game looks nice, which is the opposite of what you want during prototype development and testing.

Testing is, of course, the most important aspect of prototyping. It should be done early and often, by many different people. This can be done in formal user tests, but even having other teams play your game will greatly improve the quality of the prototype. Having set dates for user tests also helps keep prototype development focussed and agile. Test, iterate, test, iterate, and always watch out for ‘accidental’ fun. If your test panel finds unexpected ways to have fun with your game, do not correct them. Embrace the change, and use this as input to iterate again.

The hardest part is perhaps to know when to stop iterating. When is your prototype finished? When should you take a game to (pre)production, or accept failure and move on to the next project? This is a little fuzzy and intuition is important, but when all your key features are implemented, feedback from the users is the best indication. Are they happy? Are you? For Dominic, if the answer is not definitely yes, it is definitely no.

Written by: Szenia Zadvornykh

This post was written by guest blogger, Szenia Zadvornykh from dpdk, who attended and covered four sessions at FITC Amsterdam. Follow FITC on Twitter, Facebook or on RSS for updates.