on prototyping and coding your own ideas

This article explains how I learned a fundamental lesson about communication and empiricism regarding game design.

Kent's prototype

W!games was making Gatling Gears at the time of my internship. I was one of six on the design team working on an internal wiki to write down designs, making level layouts on paper, discussing the story, doing interface design, system design, character design, and attending daily meetings with gameplay programmers or other designers. I learned many things there, but one specific event stood out. A few months into my internship, senior designer Kent Kuné came to the office unexpectedly showing a prototype he made of the playable character of Gattling Gears. And it walked and shot and animated exactly like he wanted to.

Kent did not have prototyping in his job description. In fact, nobody at W!games had prototyping in their job description. The structure at W!games was much like what I was taught at school: a game designer designs a feature, then a programmer programs the feature, after which an artist implements the art, and a sound designer adds the sounds. But Kent decided to make a prototype of the main character to get a practical view on his vision, as well as showing (rather than telling) the team what was in his mind. He understood that 1) his words fell inherently short when he had to accurately express his vision to the rest of the studio. As the game designer, he asked them to do things with his ideas without understanding how they were doing it. (Making beautiful things with code, art, and audio is a mysterious craft to many). And on top of that, he knew that 2) his vision of the game was very likely to change the moment he would see it in front of him.

Kent's prototype showed his vision of the playable character extremely well. By programming the prototype himself, he was able to make a thousand tiny choices with his vision of the character in mind, without ever having to put his vision to words. And, because he had created the prototype, he could now talk about and show the rest of the team everything he coded, from the general structure to the tiniest detail: how his vision changed over the course of creating the prototype; how he iterated on the acceleration; how quickly the head rotated relative to the body; where the pivot points were located; how the feedback of the gun worked; and many other things.

on prototyping as a language

To illustrate why his words fell inherently short: did you know that there are at least 10+ ways of making a character accelerate and decelerate, and every specific implementation has a different feel to it? As the designer, how do you know which implementation is going to fit best without knowing exactly what they are, and what they do? First, as a non-coding designer, you are forced to explain your vision using words such as 'easing' or 'accelerate' or 'naturally', but these don't let you specify the details of the specific kind of acceleration - if you would even know about them. Then, the programmer interprets your words, possibly interpreting it differently from what you have in mind. And then on top of those things, you leave it up to the programmer to decide whether to go with a lineair interpolation of the acceleration, a Hermite interpolation of the acceleration, or to use another spline interpolation for the acceleration with more control over the datapoints that define the interpolation. Conclusion: there are enough places for wrong interpretations or implementation, and for your communication to fall short.

When Kent initially showed the prototype to the team, everyone in the studio expressed their vision and opinions. The game design team, who had all been trying to put their designs in words, suddenly had something concrete to talk about. The team working on the character didn’t agree on the way the animations worked and were discussing what to do next, and the gameplay programmers were discussing how things would work in their codebase. You could say that a fundemental thing such as the specifics of the main character of a game should have be defined early on in a project. But these discussions were about fine details, and now, Kent's prototype functioned as a language to communicate these details exactly as he had in mind.

on underestimating the process and overestimating your ideas

Interestingly, Kent made his prototype almost half a year after the studio started working on the project. Why didn’t Kent make a prototype for the project earlier on? And why did these discussions only happened after Kent made his prototype?

The people at W!games highly underestimated what they could potentially learn from prototypes.

We have the tendency to be efficient, to make sure that we’re not wasting time. Kent didn’t make prototypes earlier on in the project because it would not be efficient: it would 'cost' him time and everything he wrote would have to be rewritten by a gameplay programmer. However, with prototypes like the one Kent made, the gains in knowledge easily and exponentially outweigh the losses of spending time creating the prototype. It is certain that any gameplay programmer picking up where Kent's prototype left off would result in a better version of the game.

In addition: have you considered that what you see as being the game, your idea of the game, your vision of the game, is incomplete, or maybe even ungrounded? How can you know for sure that everything works as well as you think? Well... you can’t! You would have to see the game in front of you and see which things don't work. Kent’s prototype was the first time W!games saw the game, or actually Kent’s game, in front of them. For the first time they could experiences what the game ‘would actually be like’, and for them, it was a starting point to fill in the gaps, discard everything that didn’t work, and iterate on what was already there.

on how far to go and how much to put into your prototype

Kent showed me the potential gains of prototypes and inspired me to learn basic programming. He often walked into the office showing his latest experiment: a strange networked multiplayer game, or a kitesurfing game, or a crowd simulation game. He taught himself how to program for the fun of it, to play around with it, and showed me that facing any technical difficulty, such as working with quaternions or trying to steer a physics-based body, often lead to a concession to the design or a smart solutions so that he could make it work anyway. And he always found a way.

But how far should his programming knowledge go, really? Must any game designer know about everything that the programmer does up until the point that the game designer could do it him- or herself? We can easily see that something as small as an interpolation, anywhere in the game, can make a game feel completely different. Practical game designers talk about this all the time, calling it game feel. When a prototype embodies the bare bones, or baseline version of your concept, every detail can make a huge difference in the feel or aesthetics, on all levels of production: the core mechanics, but also the general structure, the interface, feedback in your game, enemy behaviour, specific gameplay elements, handling of specific situations, etc. But does this mean that a game designer should know about the internal workings of resource management, the functions of a shader, networking protocols, and other technical marvels? To my definition of game design, I would say no, using the simple heuristic that a game designer should focus on anything that directly influences the experience of the player.

Prototypes are built to express or communicate specific things and can therefore ignore or neglect many other facets of a game. Let's say you want to validate the design of your scoring system works: why spend time adding animated characters to your prototype, or writing complicated shaders, or optimising the prototype's framework, when it doesn't tell you anything about your scoring system? Chances are that a prototype in excel or a paper prototype will do an equally good job at showing you whether your scoring system works or not. However, if you set out to prototype the flashlight mechanic of your first person shooter, a paper prototype would probably not be the way to go: 'game feel' relies heavily on direct visual and tactile feedback that, in the case of almost every video game, you won't experience through paper prototyping. So in order to test your flashlight mechanics, you have to consider the minimum amount of engineering necessary, and stick to the plan. It might be tempting to make the light in your digital prototype beautiful, but how much is that going to help you understand the mechanic? Losing yourself in over-engineering, over-optimising, and making things pretty is tempting. But some things can easily be validated and communicated in simpler manners.

on making the decisions yourself

I cannot think of what ‘design’ I did before I was inspired to pick up some basic programming. I’m not even sure whether I designed anything at all while leaving all implementations of my ideas up to other people. I now see that if I, myself, want to design a game, I must be the one making the tiny choices, tweaking the feel, working on the interaction or player behaviour. Not the programmer I’m working with.

I am not saying that programmers are bad designers. I am simply saying that programmers are game designers too. If they make all those tiny choices on how to implement a game designer’s feature, then they are doing a large part of the design of the feature. No matter how communicative of a designer you are, and no matter how deeply you have thought about the feature, there will still be choices you cannot help the programmer with if you cannot code, because of structural and technical decisions the programmer makes.

If you are a game designer, but unable to code, know this: the best way to validate and communicate your own ideas to others is to make your own prototypes. So pick up some tutorials, scroll endlessly through script references, learn the syntax, Google all your errors, and start coding your own ideas. Enjoy actual video game design.

@AdriaandeJongh