When you start to make a prototype one of the first decisions you have to make is which medium to use. This might seem like an easy decision to make, just pick your preference and roll with it but I think there are a few more subtleties to it born our from my experiences of the various mediums. I want a prototype to demonstrate that the game idea I’ve had is good, that I and my team are capable of building it and that there aren’t a bunch of crazy unknown issues lurking to catch us out down the line. It also shouldn’t take too long to build, otherwise we’re just making the game. Ideally I want the lowest cost solution that gets me sufficient information and that differs per project.
Digital
Digital prototypes are ideal for video games, right? After all we’re trying to make a digital game?
Well yes and no. Certainly making a real videogame as a prototype will get you the most accurate information about the game you intend to make. The largest issue for developing a digital prototype is cost. It’s by far the most expensive option. Firstly because it’s much more complicated to make a digital game. Secondly because the expectations in terms of acceptable production values are higher particularly if you want to test the prototype with real people.
As such we only really want to use digital prototyping when the other methods wouldn’t work. In reality this boils down to interactivity and how close the prototype will resemble the final game. The more realtime interaction the game or feature requires the more you would have to abstract that interaction for it to work as a paper or whiteboard prototype. That abstraction comes at the cost of real knowledge about the game since we’re no longer dealing with the game as it is going to be played.
Another danger with digital prototypes is disappearing down the rabbit hole and not limiting your development. It’s extremely tempting to keep working on an idea for a video game once it exists despite things not really working. “If only I had <feature d> then it’ll be good… *three months later*… if only I add <feature x> then it’ll be good.” To avoid this feature creep you need regular evaluation of the prototype with decision makers. You also need to accept failure. It’s a good thing to find out your idea is not viable quickly. This can be a problem with the other mediums as well but in my experience videogame developers understandably get caught up much more easily in their chosen medium.
For example a team of five of us worked for three months at CCP to make a multiplayer prototype of some potential avatar based gameplay for EVE Online. In essence you explored an extremely dangerous environment as a group in order to salvage ‘awesome stuff’. We could have prototyped this quite easily on paper as a boardgame in much less time but you would lose quite a lot of the feeling we were attempting to create in being confined and exposed to danger as a group. Plus we wouldn’t have come across some of the technical challenges we faced when implementing it. This all fed into the final proposals we made to the Executive Producer of EVE who canned our project because we didn’t have the man power to produce it. A good decision and a good result for the prototype.
Paper
Paper is awesome, nearly a
nyone can make a game just using their imagination, paper, scissors and a pen.
Paper works best for prototyping game systems that work at a slightly slower rate than most twitch games. However there are often system in games that actually work in a way that’s easy to translate into the turn-based mechanics of card and board games. The problem then becomes abstracting the twitch elements from the game in such a way as you can be confident that you are modeling the rest of the game correctly. The more integral the twitch gameplay is to the game the less this is acceptable and the more attractive a digital prototype will look. Even if the game works at a pace that is amenable to turning into a board or card game you still might need to simplify it to be fun as a game in that format. People are less capable at complex maths than computers, even a slight increase in complexity of a game system makes turns drag, the game hard to understand and hard to pick up. This can be a good revelation though as very often in games we want people to be able to intuitively understand their systems and those with too many hidden variables become increasingly hard to fathom. Further simple systems that still produce the required ‘simulation’ or feature are much easier to maintain and balance.
The image on the right is an example of a card prototype I made for a revamp to the hacking mechanics in EVE Online. The system as it stood involved a skill check on a timer and after a designer defined amount of successes you had hacked the item in question. Very simple and worked well but it was also deathly boring. In revamping the game system I reimagined it as a simple ‘procedural death labyrinth’ and as the system was turn based it was very easy to represent as a card game.
Actually making and iterating on a series of prototypes was done over a couple of weeks and involved my entire team plus a couple of game designers from other teams. We also playtested the game with a variety of other people in our office not only to get feedback on the game system but to spread understanding of what we were going to build. Once we were pretty happy with the gameplay we had prototyped we quickly moved on into actually making the system. There was a really short timescale to make this game system and I credit the vast majority of the success of the game system with players to the time we spent prototyping right at the beginning. It gave us the confidence to power into implementation with a strong, shared vision that we knew would work despite the full digital version only really coming together in the last week or two.
Whiteboard
To me Whiteboards are the place to design and prototype details in a Just In Time fashion. They are great for quick, collaborative sessions where you are trying to build a shared picture of what the intimate details of the immediate work are. Most of the time I’ve used them as a way of explaining an idea through a series of pictures or a diagram that can be changed to show the state of the game you are currently talking about. This can be particularly useful to work through several different ideas quickly in order to pick the most viable for a first attempt at implementation. They are also really good for collaboratively designing UI.
However using a whiteboard is also the most approximate form of prototyping. Very often you’re not exploring the game system itself but how it appears and works from the point of view of the end user. They should be used liberally but in support of other forms of prototyping rather than instead of them.
meheleventyone 