It’s important to wary of the impact choice of prototyping material can have on game design. Having a familiar method for building prototypes can channel one’s thinking, limiting the design options available.
Lots of people build games in Game Maker. It’s a powerful tool that allows one to create computer games without needing a thorough background in programming. Any computer-literate person can use Game Maker to construct a prototype.
Or at least, certain kinds of prototypes. Game Maker is built on the assumption that you want to create the kinds of games commonly seen on computers–platformers and shooters, for example. Its easy, drag-and-drop options have those games in mind.
By contrast, it’s quite difficult to use Game Maker to prototype, say, a classic hexgrid wargame. None of Game Maker’s built-in menu functions apply intuitively to creating such a grid or to moving units around it. Game Maker has a “gravity” button, but it doesn’t have a “divide up the playing area into equal spaces” button.
Experienced users can, of course, use Game Maker to produce hexgrid games. I suspect, however, that those who think in Game Maker terms will naturally gravitate toward prototypes–and, ultimately, finished products–that Game Maker readily supports. It’s easy to build action games with Game Maker, and hard to build turn-based strategy. That feedback will tend to shape the mechanics one uses, and ultimately the games one creates.
One can set aside Game Maker for tried-and-true paper, but that has its own problems. Tracking multiple objects through three-dimensional space is relatively easy for a computer, but is a lot of work when done by hand. Games with many modifiers affecting a single random decision benefit from a computer to do the math. The decision to prototype a game with foamboard and 3″ x 5″ cards is also an implicit decision to accept limitations on mathematical and physical complexity that computers can brush right past.
There’s no prototyping tool that doesn’t impose some kind of restriction. Java programmers and C++ programmers may have different opinions about whether it’s realistic to design a game that must run at a consistent 60 frames per second. Someone who builds prototypes out of wood is apt to make a very different game about constructing a house than someone who exclusively uses paper. No matter what one chooses to prototype with, that choice will impose demands on the later design.
Yet, the limitations of one’s prototyping tools need not extend to one’s design thinking. The key is not to let the tail wag the dog. Allowing the game’s needs drive how the prototype is made ensures that the prototype is making the game better, rather than turning the game into an excuse for the prototype.
I’ve been thinking about this because of a new game I’ve been working on recently, something with a more “arty” bent than Over the Next Dune. The game calls for player 2 to have an effect on player 1’s movement. At the start of the process I briefly considered using a simple physics model, with player 2 as a sort of deity who could manipulate gravity in real time. However, that seemed like it would be most obviously suited to a PC or tablet game–and since I have only a very modest background in programming, I wasn’t prepared to go down that road. I started looking for designs that could be mocked up with paper instead.
Although I’m pleased with where the game has gone since, it was, in retrospect, an error to abandon that early concept just because it would have been difficult to prototype. The preconception that “I don’t do prototypes on computer” caused me to shy away from an interesting idea without giving serious consideration to whether I could make it work in a board game format. I limited my own options without finding out whether that limit was really necessary.
They say that when you have a hammer, everything looks like a nail. In the same way, preconceived notions about how to build prototypes can limit one’s design creativity. Focus first on the design, and then find a way to prototype it when the time comes.