What is the point of early prototyping? Early prototyping helps developers identify core mechanics that (a) quickly turn a concept into a tangible product, either interactive or non-interactive, and (b) allow user feedback to continue iterating on a concept.
In terms of game development, it simply helps us “find the fun” of our game.
There are many different ways to prototype, leading to many different types of feedback. However, developers must ensure they do not spend too much time on the prototype; they should use the most expedient platform. Below are a few questions that early prototyping can help us accomplish.
Question One: Does the player understand how to play our game?
It’s a silly question, but a game developer will always have inherent biases due to their deeper understanding of their game.
Although the developer may think the game is “simple” or “obvious,” this may not be true. This may range from simple movement controls such as WASD (which may be extremely confusing if the game is tailored towards non-tech-savvy audiences!) to puzzle complexities such as those in Baba Is You.
An interactive prototype (role prototype) or minimum viable product would be the best way to see if players can figure out how the game is played. My recommendation for approaching this is either through a tutorial, integrated visuals (like in Binding of Isaac, where an image of the controls is written on the ground), or, in some cases, relying on commonly used keybindings/mechanics (though as mentioned before, this can be dangerous).
To succeed, a developer shouldn’t interfere in the player’s initial game playing to see if they can start on their own (assuming that this is how the game is meant to be played).
Figure 1: The puzzle game Baba is You, a winning entry for a past game jam that can quickly get complicated with the introduction of new rules
Question Two: Is there anything in our game that can be added / can be removed?
This is another one that seems obvious, but it echoes back to the idea that games that revolve around a specific mechanic will likely want to start simple. If a prototype is already extremely confusing or difficult, to me, that either means that (a) the mechanic is not explained well enough, (b) the mechanic is too complex and should be broken down, or (c) there are a lot of other unnecessary confounding factors to the game that make the mechanic too confusing.
Consider the game Gravity Snake, which is ultimately the game Snake but with the added mechanic of gravity; if the snake is floating in the air, it drops until it touches some platform. Although the mechanic seems extremely simple, it requires the player to move in a way that may not be extremely intuitive. In the base game, the snake must eat all of the apples to win… but consider adding new things like moving spikes, or power-ups, and suddenly, the game detracts from its original mechanic into something unnecessarily difficult.
This problem requires a prototype that tests the core gameplay loop (role or implementation prototype; never mind the looks or visuals, for now). Where does the player struggle? What does the player learn? How can we streamline the process to make the game less frustrating but challenging? These are all questions that I argue this way of prototyping can answer.
Figure 2: The game Gravity Snake, where a player moves with snake-like movement, but with the added condition of gravity
Question Three: What types of dynamics arise (either intentional or unintentional) from the combination of mechanics that we’ve implemented?
Games revolve around a certain set of mechanics. As explained in class, these mechanics can combine to create specific dynamics. Some may be intentional, such as reducing the amount of ammo the player feels to encourage the player to sneak around rather than violently attack everything. Some may be unintentional, such as utilizing a specific combo move to obliterate the competition. (This gets into concepts similar to the first-order optimal strategy mentioned previously, which is up to the developer’s discretion to avoid or encourage.)
This requires deeper thinking into a sub-question: are players motivated or incentivized to prefer a certain strategy over another? Prototypes make answering this problem significantly easier: you can visibly see what the player decides to do at each turn. In this case, the best type of prototype would be one where all the mechanics are present. For example, if it’s a card-battling game, perhaps it’d be best for a small group of abilities to test the player’s ability to utilize synergies. For a shooter game, maybe having two weapons with one specific enemy is enough to analyze a player’s decision-making.
What if the player does something different from what you expected? Perhaps you want them to click one button over another, but they completely ignore that button of interest. This type of prototyping (role or look and feel prototype) can lead to the developer putting more emphasis on places that don’t have enough attention (putting a glow on the button of interest) or remove attention from some areas that have too much (gray-out the button that they click instead). It can also lead to culling certain mechanics to let others shine. This variant of prototyping with great attention to dynamics helps greatly with developer decision-making.
Figure 3: Two types of buttons… this leans more towards design practices, but one is more enticing than the other!
Question Four: What aesthetics does our game induce in the player? Does this match the intended aesthetic, if any?
Another question that prototypes can help us answer better is one about feeling and aesthetics. This is inherently very difficult for a developer to test since they primarily control mechanics, which influence player dynamics and thus create a player aesthetic. Developers also play their games repeatedly (presumably), which may lead to a different feeling towards the game as opposed to the common player. These aesthetics can range from player to player depending on their playstyles, and because of this, it’s really important to have a wide variety of players to play a game to figure out their first impressions.
Take, for example, the game Alien. This game used to have “trip” checkpoints that would automatically save the game whenever players passed a certain place on the map. Through prototyping and playtesting, the game’s developer discovered that players would act playfully, prancing around the ship (despite the constant chance of being brutally murdered by a rampant alien) because the save points were so frequent and the amount of progress that would be lost was minimal between deaths.
I argue that it doesn’t matter what stage the game is in to see positive results from building this prototype. It relies more on the experience it provides the player, typically a combination of visuals, mechanics, and possible dynamics. In doing this, the developer can ask the player how their experience was afterward or what category of “fun” they experienced. This will help the developer figure out which mechanics or dynamics require more tweaking before being able to reflect their intended aesthetic.
Figure 4: The game “Alien”, where you’re constantly hunted by an alien on the loose
