Tag Archives: process

Always Be Prototyping

Il meglio è nemico del bene
–Orlando Pescetti

Proto, from the Greek protos “first.” Type, also from the Greek typos which had a great many useful meanings, most of which had to do with a physical impression of something, like a dent or other struck-mark. Our modern understanding of a prototype, even a digital one, is consistent with its etymology: a first impression.

In digital games, the earliest prototypes are “paper prototypes;” constructed in this easy-to-iterate medium. These come before the rough digital incarnations known as “wireframes.” Eventually, “High-fidelity” prototypes are the penultimate step in the process in the creative construction. The stages, if not the language, are consistent with regards to the paper games we make.

I often refer to the paper prototype stage as an “alpha.” At this point, I’ve created a proof-of-concept, useful for testing assumptions, gameplay techniques, and a rough gauge of the complexity of my idea. Much like their digital counterparts, these are frequently hand-drawn and contain the least amount of information. There’s no point in making them any nicer since they are expected to change, usually by crossing out old information and scrawling in new.

Wireframes translate handily to the “beta” phase of game development. There might be placeholder art, computer-generated templates, and some early ergonomic affordances. We’re starting to fine-tune the mechanics of gameplay here, perhaps also trying to conceptualize the visual design, but that remains secondary as we are still trying to work out any functional flaws within the game system. It’s important not to skip this stage and move into high-fidelity prototypes too quickly as it often gives the impression that the game is more finished than is true.

High-fidelity prototypes represent mockups of the final product, before entering production. The visual treatments are considered most strongly here as well as the ergonomics. These are the showpieces that represent your product-to-be. They should be functional, appealing and coherent.

Each of these three phases often takes several iterations to complete, occasionally jumping backward from one to another as you discover things to address. They are all still prototypes—_first impressions_—and constantly, iteratively improving them, and validating your assumptions is the path to a final product.

And when is it a final product as opposed to a prototype? That’s the million-dollar question. There is no formula to tell you unequivocally when the development process is complete. But there are guidelines, deadlines, and other such process-based valuations that will help you make an informed decision.

In commercial design, deadlines are usually a defining factor. In a project scheduled for three months, you must have a final prototype at the end of that period. Other guidelines might have to do with performance, such as playtesting reports and an apparent lack of flaws. (The Minimum Viable Product model is one such metric that explicitly sets a release well before the design is in a final state.)

And now, having reached my intended word count, this article is concluded.