My favorite professor always stressed the importance of flash calculations and crude approximations over rain checks, which came to mind as I learned more about the pretotyping/prototyping process. His class was one of the last that an engineering student would take prior to graduation, so it was his job to drill into us the engineer's way of thinking: give me a ballpark answer RIGHT NOW, and if it's promising enough we'll figure out what the real answer is. After memorizing a few dozen important constants having to do with air and water (which are everywhere), we were presented with seemingly unanswerable questions like "how much does all the air in this building weigh?" or "I have six gallons of water; how much energy does it take to bring it to a boil?" Forcing us to come up with answers in mere minutes made us cut a lot of corners. This room looks about 8 feet tall, and the building is like five classrooms long, but how much of that is taken up by… Oh no, three minutes left! Those flash quizzes were the most terrifying experiences of college, but they taught us the value of being comfortable with ambiguity.
In a way, a prototype is like the back-of-the-envelope calculation an engineer uses to get ballpark estimates, and serves the same purpose - to gauge something. I had never really looked at prototypes like that before. I used to think of prototypes as smaller steps on the way to larger games, but Chris and Chaim's presentation really drove home that they are more like experiments - they test specific hypotheses and yield results that can be used to redirect a game's design. Whether the goal is energy savings or fun, quickly roughing something out provides a window into a possible future. Some of those futures are magical candy lands of sugary success while others are endless marshes of feces and regret, so it's important to look before you leap.
As the Gamasutra article says, prototypes can often show when to "shoot the baby in the crib." The general perception that ideas are precious leads people to loathe abandoning any idea before it has been fully explored, not realizing that scads of other ideas could have been probed in the meantime. For a lesson in letting go, let's look to Hinduism. As I recall, there are three main gods in Hinduism: Brahma, the god of creation; Vishnu, the god of preservation; and Shiva, the god of destruction. Shiva, though destructive, is not considered villainous. Hinduism recognizes that destruction can be positive because not all things are good. There can be joy in absence and simplicity, which helps designers to be agile and design by subtraction.
The pretotyping and prototyping process seems to have three outcomes: idea sucks - scrap it, idea is amazing - go for it, idea might have potential - make more tweaks or shelve it. The last instance is the toughest since what should be done next is unclear. When examining such situations, keep in mind all of the different components of the design. What do the game mechanics do on purpose, and what do they do on accident? How are these things useful? I'll invoke the engineering example of freezing traffic lights.
Products, prototypes, and systems all have non-trivial details and changing something can have unforeseen consequences. In this case, replacing existing traffic lights with LED traffic lights caused problems in colder regions. While traditional bulbs produce light, they also produce heat as a byproduct of their inefficiency. In engineering terms heat is waste, so replacing the lights with super efficient LEDs (which produce almost no heat) would save energy and money. Unfortunately, this means that they freeze over in the winter and become entirely useless. In the same way that a traffic bulb's "waste heat" has a hidden use, the mistakes that are made in prototyping may have hidden uses so keep them in mind.
The concept of making prototypes "juicy" with feedback noises and animations is definitely important for providing a feeling that a game is alive. It ties in with the concept that getting all aspects of a game to an "okay" level of quality is much less effort than getting any one aspect to a "great" level of quality. Adding a few noises here and there really is trivial and adds a huge amount of character to a game.
Of the concepts explained in this mission, pretotyping may be one of the most interesting. Pretotyping seems to be the 20-minute version of prototyping. It involves using whatever you have sitting around to make a game, be that coins, sticks, or your food. By enforcing your own rules with real life objects, you can see how a game mechanic (or product) works without ever touching a keyboard. Iteration occurs as quickly as you can think, and is often initiated by commonplace activities like folding clothes. In fact, a group of my friends were once stuck in a cafeteria and ended up making a game using the ubiquitous salt and pepper shakers. The game can be played with any stackable group of objects, and I was encouraged to try scripting it in Pygame as a learning project. I did. I'll have to write about that soon…
