Building Treehouse

In this article, game designer Erin Robinson describes her adventure in prototyping a new game called Treehouse.

This game started where all good things start: at an IGDA meeting. At the customary pre-drinking raffle, I happened to win a copy of Brenda Brathwaite and Ian Schreiber’s excellent book: Challenges for Game Designers. It was a book full of exercises on how to prototype games using pen and paper, to allow for rapid game development without the hassle of programming.

I eagerly dove in, excited for both the arts and crafts aspect, and the fact that it would let me procrastinate on other, more important projects. An exercise in chapter two asked the player to make a game based on exploration. It suggested, “the location could be anywhere, from a treehouse village to downtown Chicago.” Immediately, my mind connected the two, and the concept of “Treehouse” was born.

Although because I’m a video game designer, I went with a post-apocalyptic city.

Anyway, I decided to make the game tile-based, so that the player could “explore” the environment by turning over tiles. After sketching a few tile ideas, I narrowed it down to seven types, which I’ve illustrated here. I printed eight of each, to be arranged face down, randomly, in a 7 x 8 grid. You would play as one of four female adventurers (yes, “Doctor President” is female), scrambling to build the most treehouses before the game was over.

In order to build a treehouse, you had to gather wood. This formed the “collection” aspect of the game. Players, upon discovering a “Building” tile, could roll a die to see how much wood they found. A building could only be searched once, so a big part of the gameplay became hunting down these particular tiles.

I arbitrarily set the price of a treehouse at five wood. I also introduced the concept of “movement points” to moderate the player’s actions. Each player started their turn with three movement points. It cost one point to flip over a tile and move there, two points to search a building, and three points to build a treehouse. Although you could retread over tiles you had flipped over, the restriction on movement points put a large value on exploration.

For kicks, I also created “Tree Building” tiles, whose trees were only accessible if there happened to be an adjacent “Ruins” tile. The idea was that the adventurer could climb up the ruined shell of a building to reach the roof. Originally, all treehouses were worth the same amount (that is, one “victory point”), but climbing to the top of a building was such a hassle that my playtesters demanded an extra reward for doing so.

Most importantly, the game ended up being pretty fun. There was a healthy amount of competition that came from fighting over scarce resources, and a metagame dynamic of “trash talking” emerged spontaneously. The only real shortfall of the game was at the very end, when some players had run out of wood, there was no real point to them continuing to play. There was also no way they could screw over anyone lucky enough to still be building treehouses.

My quick fix for this, although it wasn’t perfect, was to call the game over as soon as the last tile was overturned. Thus, if your opponent looked like they were going to keep building, you could quickly explore the last tiles and end the game.

All in all it was a fun first effort, and I’m eager to test out other game principles in this lo-fi manner. Ironically, one of my playtesters complained that the paper tiles were hard to flip over, and suggested I just program the damn thing so we could play it on the computer.

Back to the drawing board.

Erin Robinson is an independent game developer currently working on a title for Wadjet Eye Games. Her previous freeware games "Nanobots" and "Spooks" and are available on her website.

Simple Prototypes; Complex Virtual Worlds (Part II)

In Part I, Dr. Ricardo Rademacher, CEO of Futur-E-Scape, begins his journey of creating a virtual world prototype by reviewing the existing literature on prototyping. In Part II, he gives his thoughts on how simplicity pertains to a virtual world prototype.

For my own contribution to the subject, I will write down my thoughts into three areas: design, art, and technical. Each of these areas will be seen during the prototype phase but will receive on equal consideration.

Design Simplicity

A prototype should be designed to focus on a single gameplay element. For example you may wish to prototype a close combat module and a ranged combat module for your RPG. The prototype should test one or the other but not both. Because of this, it can be easy to align a prototype to a use case scenario. If written at the proper level, each use case will address a certain gameplay module within the total design. Since each use case narrative should completely track how that gameplay could be instantiated, there could be a one-to-one relationship between prototypes and use cases. As well, a prototype design document can be as little as one page for a developed use case narrative or a few pages at most for an extended high concept treatment. Because in a virtual world these systems will be interrelated and coupled to various others, it is important to understand them on a small modular level before you integrate. In our example, since most combat is usually presented also in a chat window, a stable prototype of a chat module will ensure that when you go into production, each element is well understood before mashing together.

Artistic Simplicity

One of the major difference is given between a prototype in a demo is in the art assets. While a demo should look as good as a finished product code, the prototype is not bound by such constraints. In effect, this means that the production and integration of art assets should not be a priority during the prototype phase. The art pipeline should be part of any game engine analysis done prior to choosing that particular engine. And since art assets do not contribute significantly to gameplay or other systems, making a prototype looked pretty merely wastes time that could be used testing deeper systems. This is particularly relevant when it comes to the creation of virtual worlds. Since a virtual world has so many art assets, often in redundant roles, focusing on art early on in game production will unnecessarily sap resources that could be better put it to design work.

Technical Simplicity

I found that the biggest challenge of prototyping a virtual world to comes from the technical side. Given the online nature of virtual worlds, there is a host of technical issues that you do not encounter in single player games. However, when it comes to prototyping, these are NOT the issues you want to focus on. For example, these elements should not be part of your prototype and our best relegated to a technical review phase of your production or a separate technical team:

Networking: while networking is arguably the most important system of a virtual world, its lifeblood if you will, there is no need to test it during prototype. We know the Internet works and reassuring yourself of this while you are trying to create a game will again divert unnecessary focus away from the design. As a matter of fact, it is during the prototyping phase that information about the networked data elements will come to light such as how much and what type.


Database: just like networking, the database is a central part of your game and yet one that you should not prototype. While there are many networking engines available for free or commercially, you can more or less exclusively use the mySQL engine for database. Thus just like networking, this is an aspect that is well understood and thus should not be prototype. There is a strong temptation to make use of a database early in prototyping, such as by putting in extensive player information or combat tables. I would advise that during the prototype you merely use a flat file system, if the amount of information necessary for a prototype is so large that it requires a database, then you are likely attempting to prototype too much or too large.

Security: while bad security will bring your game down, there is absolutely no reason to be concerned about this during the prototype phase. A prototype by my definition should not be made public. It should be a purely in-house application for testing purposes. Hence there is no reason to include any kind of security model. Furthermore, security will often have the effect of merely adding some latency to your virtual world. The extra milliseconds needed to encode and decode a network packet should not significantly alter your games performance.

Dr. Ricardo Rademacher is a native Chilean who obtained his Physics PhD in 2002 and is the founder and CEO of Futur-E-Scape, LLC. Created in 2004, this company is dedicated to the creation and research of educational virtual worlds. He also speaks at various educational and entertainment conferences and has written several publications on these subjects.

Simple Prototypes; Complex Virtual Worlds (Part I)

In Part I of this article, Dr. Ricardo Rademacher, CEO of Futur-E-Scape, begins his journey of creating a virtual world prototype by reviewing the existing literature on prototyping.

Prototyping is a word you will hear time and time again in the production of a game and often touted as the most important phase of game development. Given that it is the first incarnation of your game idea or game world, mistakes and success at this early stage can multiply as the project goes forward. But what exactly IS a prototype? And what does a prototype mean in the context of creating a virtual world?

In my own personal attempts to create a virtual world, I have created several versions and called all of them a prototype. And in my experience, while the definition of a prototype is elusive there is a key characteristic that is universally agreed upon: simplicity is the key to prototyping. The simpler the system, the quicker you can get to testing gameplay. As well, it is easier to fix a simple system rather than a complex interrelated one. However when we apply this definition to the creation of a virtual world, we come upon an immediate stumbling block: Virtual worlds are not simple. And thus my journey through the prototypes has been a journey of reconciling the simplicity of a prototype with the complexity of a virtual world. What follows is a quick survey of what others have to say about prototypes and a few personal thoughts on how to apply simplicity to a virtual world prototype.

There is a certain common sense element to how we define a prototype. We somehow just "know" what it is or isn't, even if we can’t exactly define it. Even on paper, there is no clear definition. For example, Jeanne Novak (Game Development Essentials, 2009) defines a prototype as a “A working piece of software that captures on-screen the essence of what makes your game special, what sets it apart from the rest, and what will make it successful.” While she goes on to suggest that prototyping should be done using non-computer resources (like board or card games), this is of little help when trying to determine what you prototype about your virtual world design. We also have Meigs (Ultimate Game Design, 2003) who has this to say on the subject: “Short of complete actual engines, there is no way to test game ideas in any efficient way. Some game ideas, by definition, are easier to prototype than others.” Therefore we are left with not only an ambiguous definition but also a pessimistic one.

There are however a few resources that give us more concrete guidance. Salen and Zimmerman (Rules of Play, 2004) give us the following advice: “early prototypes are not pretty. […] still, the prototype is more than an interactive slideshow --- it is a genuinely playable game that begins to address game design challenges of the project as a whole." They point out the development speed benefits of using simple programming languages and techniques for your prototype. So from this we can take away that our prototype should be simple and quickly developed so as to address issues in game design early in the development schedule. Richard Bartle (Designing Virtual Worlds, 2003) gives us a little more targeted advice: "prototypes are necessary partly for commercial reasons -- they demonstrate to investors that the team can produce the goods […].” And thus from this we see that the prototype can serve a function beyond that of merely testing gameplay.

Dr. Ricardo Rademacher is a native Chilean who obtained his Physics PhD in 2002 and is the founder and CEO of Futur-E-Scape, LLC. Created in 2004, this company is dedicated to the creation and research of educational virtual worlds. He also speaks at various educational and entertainment conferences and has written several publications on these subjects.

Prototyping: An Odyssey (Part IV)

In Part I, scholar Altug Isigan looks to etymology and the Odyssey for lessons on prototyping. In Part II, he observes that prototyping is usually about aspiration towards a “product” -- a goal which can be plagued by overrepresentation or underrepresentation. In Part III, he describes a notion of prototyping that finds balance between two approaches in creativity, the controlled and the impulsive approach. In Part IV, he concludes that the most valuable product of prototyping is not a better game, but a better game designer.

Crystal, Flame... or Both?

From what we have discovered in our odyssey so far, we can say that prototyping might benefit from the unification of two seemingly contradictory approaches, the controlled and the impulsive approach… Or, as Italo Calvino’s calls them, the traditions of the Crystal and the Flame (1988: 71). Let’s compare their characteristics:

Crystal

Represented by Hephaistos-Vulcanus

Reserved

Methodological fastidiousness

Patient searching

Concentration/Devotion

Craftsmanship/Expertise Order (Program) Whole Geometrical rationality Structure Self-organizing system Distanced/Self-sufficient

Flame

Represented by Hermes-Mercurius

Impetuous

Rushing into extremes

Flashing inspiration

Shape shifting/Playfulness

Jack-of-all-Trades Chaos (Happy accidents) Parts/Fragments The forking paths of Life Movement Order out of noise Connectivity/Exchange

The Crystal can be summarized as the “union of a spontaneous logic of images and a plan carried out on the basis of a rational intention”. The Flame on the other hand sees “imagination as a means to attain a knowledge that is outside the individual, outside the subjective”; it’s an attempt to “identify with the world soul” (Calvino; 1988: 91).

What does a possible combination of the both look like? Let us listen again to Italo Calvino:

[The third way is] imagination as a repertory of what is potential, what is hypothetical, of what does not exist and has never existed, and perhaps will never exist but might have existed... [It is the] spiritus phantasticus [...] that is, a world or a gulf, never saturable, of forms and images. So, then, I believe that to draw on this gulf of potential multiplicity is indispensable to any form of knowledge. The poet's mind, and at a few decisive moments the mind of the scientist, works according to a process of association of images that is the quickest way to link and to choose between the infinite forms of the possible and the impossible. The imagination is a kind of an electronic machine that takes account of all possible combinations and chooses the ones that are appropriate to a particular purpose, or are simply the most interesting, pleasing, or amusing. (Calvino; 1988:91)

You are a game designer in the 21st century, an age of goals and expectations; milestones, deadlines, products, profit. It’s true; these are realities and you have to deal with them. But if you look carefully into the office spaces around you, you will see a repertory of potential or hypothetical game designers that do not exist, that have never existed, and perhaps will never exist, but yet might have existed.

Recall them.

…There we are, my friends, arrived at home, in safety, reunited with our beloved (and within our selves). We’ve grown during our voyage, and now let me share with you, my loyal comrades, what I’ve learned for myself from this our odyssey.

The Voyager is the Destination

Calmly watching the sea from a height, and facing the sinking sun, I hear my inner voice saying: “Every finished prototype is an exploration of the potentiality of the game designer. It is the game designer, as a multitude of potentialities, who refines himself with every new prototype he makes.”

The ultimate result of prototyping is not a better product; it is a better game designer.

A seasoned designer knows that the secret of the ninja is not his pace or her exactitude, nor the sharp sword, but the preparedness for the decisive move when the time for it comes. This is a quality that one gains though experience in both control and impulse. Ironically, exactitude is oftentimes a matter of approximation, and pace oftentimes a matter of patience. I believe that for the aspiring game designer (the designer-as-prototype, the designer-as-potentiality), there is one great motto to adopt: festina lente: hurry slowly.

Allow me to bid farewell to you with a short story about a Chinese artist:

Among Chuang-tzu's many skills, he was an expert draftsman. The king asked him to draw a crab. Chuang-tzu replied that he needed five years, a country house, and twelve servants. Five years later the drawing was still not begun. "I need another five years," said Chuang-tzu. The king granted them. At the end of these ten years, Chuang-tzu took up his brush and, in an instant, with a single stroke, he drew a crab, the most perfect crab ever seen. (Calvino: 1988: 54)

References

Björk, Staffan and Holopainen, Jussi (2005). Patterns in Game Design. Boston: Charles River Media.

Borges, Jorge Luis (1999). “On Exactitude in Science”.

Calvino, Italo (1988). Six Memos for the New Millennium. Cambridge: Harvard University Press.

Dickinson, Emily (1991), Collected Poems. Philadelphia: Courage Books.

Dixon-Kennedy, Mike (1998), Encyclopedia of Greco-Roman Mythology. Santa Barbara: ABC Clio.

Fullerton, Tracy (2008) Game Design Workshop: A Playcentric Approach To Creating Innovative Games (2nd Edition). New York: Morgan Kaufmann.

Gingold, Chaim (2008). “Catastrophic Prototyping and Other Stories”. In: Fullerton, Tracy. Game Design Workshop: A Playcentric Approach To Creating Innovative Games (2nd Edition). New York: Morgan Kaufmann: pp. 182-185.

Guthrie W.K.C. (1955). The Greeks and Their Gods. Boston: Beacon Press.

Higginson, Thomas Wentworth (1991). “Preface”. In: Dickinson, Emily. Collected Poems. Philadelphia, Courage Books: pp.13-16.

Homeros (2007). Odysseia. Istanbul: Can.

Jennings, Elizabeth (1991). “Emily Dickinson and the Poetry of the Inner Life”. In: Dickinson, Emily. Collected Poems. Philadelphia, Courage Books: pp. 394-401.

Altug Isigan is a scholar at the Eastern Mediterranean University, Department of Radio-TV and Film, in sunny Famagusta, Cyprus, where he is writing a dissertation on narrative in games. You can read more of his work at his blog, the Ludosphere.

Prototyping: An Odyssey (Part III)

In Part I, scholar Altug Isigan looks to etymology and the Odyssey for lessons on prototyping. In Part II, he observes that prototyping is usually about aspiration towards a “product” -- a goal which can be plagued by overrepresentation or underrepresentation. In Part III, he describes a notion of prototyping that finds balance between two approaches in creativity, the controlled and the impulsive approach.

The Stunning Eye of the Prototyping Process

In a very intriguing passage about the values of lightness in literary creation, Italo Calvino takes a look at how Perseus overcame the terrifying Medusa. The answer, according to Calvino, lies in the indirect approach that Perseus adopted as he fought the monster. Perseus did not carry out his fight against her, but around her (1988: 4-7). I’d like to claim that this principle provides us with a metaphor of the prototyping process.

Consider the diagram below:


Diagram 3: The Stunning Eye and the Safe Path around it. This diagram builds upon the prototyping stages formulated in Tracy Fullerton’s Game Design Workshop, Second Edition: A Playcentric Approach to Creating Innovative Games (2008).

The safest way -if you don’t want to get stunned- is to avoid the ‘eye’ of the prototyping process (the Everything). Instead you have to walk carefully around the ‘eye’, and stay on the triangular track that leads around it and only take one step at a time when you move between neighboring areas.

…Until here, the focus of our voyage was on control. We explored the ways to foster a meaningful level of exactitude in our prototypes. We discussed methods on how to survive the complexities of prototyping. We realized that it is not only possible, but also necessary to exercise a certain level of control over the prototyping process. Maybe it is now the time to sail into the rather untamed waters of prototyping. I feel a fresh wind coming up and I’d say let’s not miss this chance and sail into more playful waters.

Prototyping with a Portfolio Philosophy

In the preface to Emily Dickinson’s Collected Poems, Thomas Wentworth Higginson quotes the poet Ralph Waldo Emerson as having described Dickinson’s work as the “poetry of the portfolio” (in Dickinson; 1991: 13). Higginson continues by saying that hers was poetry “produced absolutely without the thought of publication and by way of expression of the writer’s own mind” (p.13). Higginson concludes that the writer enjoyed a level of freedom that allowed for her “unconventional uttering of daring thoughts” and indifference towards the expectations of the ‘poetry of the establishment’ (pp.13-15).

It can be said that the “philosophy of the portfolio” is vital in the prototyping process, too. As much as there is a need for control, there is also a need for just forgetting about goals and deadlines and other restrictions for a while and see where the expression of our own minds carries us. As dangerous as this might look to a producer or all other “sane” members on a development team, there opens itself to us a new gate to unimagined potentialities.

Dickinson is known for the various renderings of her poems. Crafting a poem was an open process of writing many a poems that could have been that poem (or not). The process was free from any marketing concerns. In this free-flow process, there came to day a multitude of potentialities which served as a ground for “happy accidents”, as Elizabeth Jennings (in Dickinson; 1991: 385) calls them. This was not so much about reaching an end product as it was about maintaining an energy field in flux which in it held together the echoes of all previous prototypes (and those to come). Despite the emphasis on the process over the product, it is especially worth mentioning that with over 2000 poems, Dickinson has been a very productive writer.

We will name here two lines of thought in creativity and innovation -both being in favor of vibration, flux, and multitude- that connect to this fruitful experimental “philosophy of the portfolio”:

One of the lines can be exemplified in Roland Barthes’ idea of a mathesis singularis (in Calvino; 1988: 65), the science of the partial (in contrast to mathesis universalis, the science of universals). Another example within this line of thought can be found in Robert Musil’s novel Der Mann Ohne Eigenschaften (The Man without Qualities. In a passage of the novel, the main character Ulrich mentions “mathematical problems that did not admit of any general solution, though they did admit of particular solutions, the combination of which could bring one closer to the general solution.” (in Calvino; 1988: 11) This line seems to be a foundation for an open-ended inductive approach in experimental game design of which Björk/Holopainen’s Patterns in Game Design philosophy (2005) could be seen as a variant of.

The other line connects to the modern literary movement of creating a “machine for multiplying narratives” (Calvino; 1988: 120) as being observed in some of the works of Raymond Queneau (A Hundred Billion Poems) and Georges Perec (Life: A User's Manual), both being members of the experimental literature movement Oulipo (an abbreviation in French for “Workshop of Potential Literature”). Here, the goal is to create clockworks of/for potentialities; a system/mechanism which inexhaustibly generates permutations and variations of its own by using what it is constituted of. No need to say that these types of concerns are among the most central themes in today’s debates on the narrative potentialities of interactive digital products (such as games).

It is obvious that the “philosophy of the portfolio” might serve as a basis for a “Workshop of Potential Gameplay”. Getting this sort of philosophy incorporated into the formal processes of the profit-seeking industries might be also one of the ways to answer the repeated calls for “art games”.

…The winds were generous, my friends, and they carried us along the vast seas of prototyping. Is it only me, or do you, too, smell the scent of flowers and trees? Could it be that these green hills at a distance are the hills of our beloved lands? And isn’t that a bay over there, the bay of our city, with all those ships and buildings embracing each other? It seems like we will soon be at home; and now it’s the waves of excitement and joy that seem to carry our ship. So let us be quick and clear up the remaining issues, since we will have to part soon.

Altug Isigan is a scholar at the Eastern Mediterranean University, Department of Radio-TV and Film, in sunny Famagusta, Cyprus, where he is writing a dissertation on narrative in games. You can read more of his work at his blog, the Ludosphere.

Prototyping: An Odyssey (Part II)

In Part I, scholar Altug Isigan looks to etymology and the Odyssey for lessons on prototyping. In Part II, he observes that prototyping is usually about aspiration towards a “product” -- a goal which can be plagued by overrepresentation or underrepresentation.

From Potentiality to Product

In his study The Greeks and Their Gods (1955), Guthrie elaborates on Aristotle’s philosophy. He notes that the notion of aspiration is central to Aristotle and his contemporaries. They see in nature and all its beings a potentiality that moves towards its actualization. It is the movement between an arkhos (the out-of-which) and a telos (the into-which). The process is completed when perfection (full-fledged functionality) is reached (p. 353-370).

We can build upon this Aristotelian vision: A prototype helps us in managing the potentialities of a game concept, and in transforming it into a functional representation of it. Basically, the prototype bridges the initial gap between the game concept and the audience that is intended to interact with. It provides a means and common ground for them to meet and see how they get along with each other. The first meeting will be evaluated and followed by others and the process will typically take the form of a refinement cycle which is carefully planned, guided and closely observed by the game designer.


Diagram 1: The Refinement Cycle.

It’s throughout the refinement cycle that the game concept (the onto-paper) is gradually transformed into a functional prototype (the into-paper).


Diagram 2: From gameplay visualization to functional representation of the game.

Obviously, the prototype’s most important contribution to the game development process is its power in simulating a running version of the game. It is a highly accurate and functional representation of the game, and hence invaluable for those who know what that means.

The Pitfalls of Representation

The level of accuracy to which a prototype represents the gameplay is crucial in successful prototyping. However, striving for accuracy has its pitfalls.

Two major problems that occur in the search for exactitude are caused by escalations in the representation. However, the two types of escalations we speak of are into opposing directions. Ironically, the result of both is (and feels) essentially the same: You’re getting lost.

Let’s have a closer look at how this happens:

The first type of escalation can be called Overrepresentation and has been best exemplified in an old tale recounted by the Argentinian writer Jorge Luis Borges (1999):

[…] In that Empire, the Art of Cartography attained such Perfection that the map of a single Province occupied the entirety of a City, and the map of the Empire, the entirety of a Province. In time, those Unconscionable Maps no longer satisfied, and the Cartographers Guilds struck a Map of the Empire whose size was that of the Empire, and which coincided point for point with it. The following Generations, who were not so fond of the Study of Cartography as their Forebears had been, saw that that vast Map was Useless, and not without some Pitilessness was it, that they delivered it up to the Inclemencies of Sun and Winters. […] (Suarez Miranda, Viajes de varones prudentes, Libro IV,Cap. XLV, Lerida, 1658)

The lesson: Keep the scale of your representations on a perceptible level. If the representation grows into the size of what it ought to be a representation of, why are you calling it a representation anyway?

Ironically, trying to scale down the representation and divide it into manageable pieces can soon turn into another unpleasant situation: Fragmentation. This problem has been nicely explained by the Italian writer Italo Calvino in his Six Memos for the Next Millennium
:

Sometimes I try to concentrate on the story I would like to write, and I realize that what interests me is something else entirely or, rather, not anything precise but everything that does not fit in with what I ought to write—the relationship between a given argument and all its possible variants and alternatives, everything that can happen in time and space. This is a devouring and destructive obsession, which is enough to render writing impossible. In order to combat it, I try to limit the field of what I have to say, divide it into still more limited fields, then subdivide these again, and so on and on. Then another kind of vertigo seizes me, that of the detail of the detail of the detail, and I am drawn into the infinitesimal, the infinitely small, just as I was previously lost in the infinitely vast. (Calvino; 1988: 68)

The lesson: It’s not just their sizes that make things manageable. If you have too many of such ‘manageable pieces’ you’ll find yourself unable to manage them all. Limitation must have its limits or it becomes just another version of Overrepresentation.

…So far, the wind seems to be on our side, so let’s sail a bit more into this direction and see what other solutions we can find for the problems in prototyping.

Altug Isigan is a scholar at the Eastern Mediterranean University, Department of Radio-TV and Film, in sunny Famagusta, Cyprus, where he is writing a dissertation on narrative in games. You can read more of his work at his blog, the Ludosphere.

July 2009: Mature Games

July 2009's topic, Mature Games, was submitted by game designer Ryon Levitt.

He writes:

"For the love of God, think of the children!"

The famous train of thought that has carried much debate against the video game industry. But is this realistic anymore? The ESA says that "The average gamer is 35 years old and has been playing for 12 years." However, while many other media, such as books and movies, are recognized as having certain (not necessarily pornographic) sub-genres for adults, many critics continue to act as though the word "game" automatically means "for kids". One reason for this is that the typical target demographic is still Adolescent Males and, as such, contain many typical "young male power fantasy" stereotypes - Big Guns, Big "Guns", Violence, Crime, Sex, Drugs, and, of course, Rock and Roll.

As designers, we face many questions regarding this subject:
- How can we fix this image?
- SHOULD we fix this image?
- Are games for adults and youths mutually exclusive?
- What do adults want in an entertainment medium?
- Does "adult" automatically mean "casual gamer"?

Ryon Levitt is a programmer-turned-designer for KOEI, currently working at their main branch in Yokohama, Japan. He is currently working on his first title as a designer. Ryon is one of the founding members of the IGDA Game Design SIG, and helped coin the acronym GDAM.

Prototyping: An Odyssey (Part I)

In Part I of this article, scholar Altug Isigan looks to etymology and the Odyssey for lessons on prototyping.

In Search of Full Sail

When I decided to write an article for this month’s GDAM (I didn’t know at that time that it would be this article), the first thing I did was to look up the word prototype. To my surprise, I found that it was rooted in a combination of the Old Greek words protos and typus: “first impression”. I thought that most game designers would find this to be a very appropriate definition.

Delving deeper into the etymology of the word, I found out that it was connected to the adjective ‘protean’ (someone or something taking on varied shapes), which in return was generated from the name of an oracular ancient deity with the name Proteus. At the very moment in which I decided to have a closer look at this deity, I had already triggered a trap: Before I even realized, I was thrown into an odyssey that would carry me through the vast seas of prototyping. Would I be able to find my way back home? Only the winds knew the answer.

Indeed, it is one of Odysseus’ close friends -Menelaus, husband of the beautiful Helen of Troy- who, in Homer’s Odyssea, mentions the name of Proteus. In an account of what happened to the many heroes of the Trojan War on the way back to their homes, Menelaus tells Telemakhos also the story of his own adventurous return to Lakedaimon (Odyssea, Chapter IV: In Lakedaimon, verses 350-570): He and his friends get stuck on the island of Pharos, where for weeks and weeks there is no wind to fill their sails. Eventually they find themselves plagued by scarcity and face starvation. The exhausted Menelaus finally realizes that the reason for this abnormal situation must be a curse of a god that he must have failed to please. But which one, and what wrong had he done? Obviously, only an oracle would be able to tell him these secrets. But where on this abandoned island could he find such a gifted person? It’s Eidothoe(Ido) who suggests him a solution: She says that he must seek the help of Proteus, a prophetic sea god that frequently visits the shores of Pharos with his flock of seals. There is a problem though: Proteus doesn’t like to share his wisdom with others, and should anyone attempt to force him to prophecize, then he pulls off some stunning tricks that help him to escape.

“Proteus possessed the gift of prophecy, a gift he could avoid using by utilizing his ability to metamorphose at will. In an instant he could become fire, flood, or wild beast. However, if a person held him fast, no matter what form he assumed, he would eventually return to his normal form and deliver the truth.” (Dixon-Kennedy; 1998: 263)

Menelaus, determined to escape the island, prepares a trap, and with the help of his friends he captures Proteus, who, after some wild shapeshifting, eventually normalizes and tells Menelaus the reason that got him stuck. With this vital information, Menelaus manages to bring back the winds and re-opens the sea routes that will lead him to his beloved lands of Lakedaimon.

I must admit that I was enchanted by this myth. It was a wonderful metaphor for prototyping and captured its essence perfectly. Let’s look at the elements of this myth:

• Metamorphoses: the ability to assume many forms in rapid succession.
• Prophecy: the revelation of the mistakes you were unaware of at the time you made them; and directives on what course to take in order to repair the damage that they have done.
• Exactitude (As an extension of the Prophecy element): The Oracle of Delphi carried the inscription “Know thyself!”, an inscription that has been often interpreted as “Know your problem!” or “Have a clearly formulated question!”. Otherwise the answer of the Oracle will sound cryptic and useless.
• Teamwork: You can’t fasten Proteus all by yourself; you need the help of a group of dedicated and determined people.

So, what’s prototyping then? Following the myth of Proteus, it is –together with your comrades– to hold tight onto the prototype –and your question!–, and not to allow yourselves to be fooled by the many shapes it will assume. If you’re determined enough and hold on tight, finally the prototype will be tamed: Your mistakes as well as the steps you need to take for the future will be revealed to you.

Now, as we seem to have some wind filling our sails, let’s move quickly to our next topic.

Working at the Pace of Mind

There are many fascinating things about prototypes and prototyping. We can summarize the most important points as follows:

• Sustainability: Prototyping is a (relatively) cheap and repeatable process.
• Flexibility: You can prototype almost anything, with anything (and anyone).
• Safety: You don’t risk to waste expensive code or art during or after experimentation. More than that, you protect yourself from wasting such expensive assets in the future, because the prototype will help you to tell into which assets to invest and into which ones not.
• Modularity (Scalability): Like a magnifying glass, you can zoom into particular game mechanics or zoom out to see the interactions between them.
• Responsiveness: Instantly make changes and receive feedback on them. A prototype is functional, interactive, up-and-running.
• Collaboration: Although it mostly starts alone, prototyping can be easily expanded to include friends, team members, producers and executives or members of the target audience.
• Control (Manageability): You can always take a step back and reconsider things, until you feel that you’ve cleared it all up and are ready to proceed with the next step. You have control over the goal, scope, ‘question(s)’ and what not’s of the process.
• Experimentation: (Almost) anything goes! It is the playground of the imaginative and innovative mind.

However, there is one thing that is the ultimate argument in favor of prototyping, and that is its pace and exactitude. These qualities can make them so persuasive that it made one game designer to speak of prototypes as “powerful ninjas” who can “move mountains” and “cut all debate with one swift movement” (Gingold, in Fullerton, 2008: 184). Is that to say that a prototype works at the pace of the mind? Not always, but probably it is the method closest to cope with the pace of the imaginative mind. And when it’s done well, a prototype becomes the sharpest of arguments, like the sword of a ninja.

…We’ve made quite some way already, but there is still a lot to discover in these waters… See those islands over there? Let’s go and check them out!

Altug Isigan is a scholar at the Eastern Mediterranean University, Department of Radio-TV and Film, in sunny Famagusta, Cyprus, where he is writing a dissertation on narrative in games. You can read more of his work at his blog, the Ludosphere.

Simplicity is the Glory of Prototyping

In this article, programmer Nels Anderson explains how to maximize the benefits of prototyping.

Prototyping is one of the most important phases of pre-production and it is important that the (likely limited) time spent prototyping is made as productive as possible. Some studios are renowned for the amount of resources dedicated to prototyping. Unfortunately, most do not have access to a bottomless wellspring of money and time. One way to help maximize the value of prototyping is to think of it as brainstorming with evaluation.

Ultimately, prototyping really is a collection of brainstormed ideas that have been taken farther than a white board or sticky notes. Keeping that spirit of brainstorming is important to successful prototyping. Successful brainstorm means getting through as many ideas as possible, not dwelling on minutia related to just a few ideas. Similarly, it's important not to dwell on details while evaluating prototypes. This means prototyping as quickly as possible.

As my background and daily work is partially in engineering, it pains me to write this, but prototypes should not be coded unless they absolutely must. There's simply too much setup time involved in getting code prototypes up and running. There's a feeling of tangibility and permanence that can come with coded prototypes, which can be detrimental to rapid iteration. Use paper prototypes whenever possible, because no matter how good your programmers are, heavy stock paper, scissors and markers are faster. When prototypes require code, still push for as much expeditiousness as possible. Use Flash, Director, Panda3D or even Unity if you have a team member familiar with such. Steal as much existing work as you can, from other projects, public mods (if appropriate), wherever you can. And, above all else, plan to throw any code you write away before starting the project in earnest.

A fantastic example of this is when EA Blackwood was prototyping Skate. The prototyping team connected the control logic to a simple text output. No animation or rendering at all. But this prototype let the team gain a clear understanding of how the game would feel and that it was enjoyable to play.

Also, always include an artist in your prototyping. Not only can this help visualize what a prototype can grow into, but much of the initial creative process occurs during prototyping. Having an artist supporting the prototyping can keep those creative juices flowing and take things in directions that simply might not happen solely with written and spoken brainstorming. But as with the engineers, artists during prototypes must work as quickly as possible. Several rough sketches with only a small area coloured and filled in with detail are far more useful than a single immaculate, detailed and coloured piece. Be as broad with art prototypes as possible and don't emphasize areas of the prototype that are vague or likely to be changed.

Lastly, include audio in prototypes, especially music. As much as an artist can help evoke certain aesthetics during the prototype, music can help establish thematic tones that will take prototypes in more valuable directions. It gives a prototype more substance and can help you visualize what a more complete experience will feel like. Even if it's just a paper prototype, play some thematically similar music on a stereo in the background. Kyle Gabler, one of the developers of World of Goo, advocates getting music into your game as soon as possible, possibly even before you have a solid idea of what your game actually is. Use temp tracks if you must, but do be careful about inadvertently falling in love with them.

I believe the value of prototyping is directly proportional to the number of iterations that can be achieved. Do whatever you can to make that prototyping faster, more substantive and more evocative. The more ideas that can be brainstormed and evaluated, the more likely it is you're going to hit on something truly fantastic.

Nels Anderson is a programmer at Hothead Games. He's probably the only game developer in Vancouver (and maybe all of Canada) that was born and raised in Wyoming. He writes about games and game design on his blog, Above 49.

July 2009 Poll

Please come and vote for the July 2009 topic!

You'll see the poll to the side. The choices are:

• Mature Games (Games for Grown-Ups)
• Multiplayer Economies
• Cheats
  

Please choose by June 19, 2009!

Prototyping: Do it Quick + Dirty

In this article, creative director Eitan Glinert describes the process of prototyping that has worked for his company, Fire Hose Games.

So you've got an idea for a game, but you're missing an artist, you don't have the design nailed down, you need to find funding, and you don't know what platform you're going to develop for, you're not sure that the concept is even feasible, or you [insert development hurdle of your choice here]. How do you even start? With prototyping!

Prototyping is the process of making a small, crappy, slapped-together version that demonstrates certain key aspects of your final vision. It's a great way to start making games since it is far less daunting, and during the process you'll learn a lot about what you should actually do in the full version. Prototypes are throw away, but that's a good thing since it'll give you more freedom to experiment in ways you might not normally try.

Starting out

Take stock of what you have, and make a list of your strengths and weaknesses. When we started out at Fire Hose we were 3 MIT nerds with a good amount of design experience. We were especially good at programming and game design, but we completely sucked when it came to art and we had almost no money whatsoever. As a result, we decided to focus on the technology and design, and to just rip off artwork from other games. A larger, more established studio might have strengths of lots of money and a large code base, but weaknesses of time and manpower. Whatever the case may be it's important to focus on what you're good at and (for the time being) ignore the rest.

Scoping is really important as it dictates how big the prototype will be. We recommend making a few rounds of prototypes, starting with quick + dirty one day versions, then a 1-3 week build, and then a 2 or 3 month final prototype which is a good vertical slice of what the game eventually might feel like. Of course this will vary team by team, as larger groups can accomplish more, and not everyone has 3 months or so to devote to prototyping (though we certainly recommend spending at least that long if you can afford it). It's worth noting that there is a limit to how big a prototyping team should be; larger than 10 people will probably not be useful since the goal is NOT to make a final version, but just something quick and dirty that can be tested. We find that 3 – 4 people can do a good job of rapidly comping up with something worth playing with.

Let the development begin!

Once you've got your team, get to it! Remember, the standard rules of development don't apply, so feel free to take shortcuts. Want to steal assets/code from other games? Go for it! Want to use stand in, crummy programmer art? Why not! Code in whatever is faster, not most robust (i.e. python, not C). In fact, you should do whatever is necessary to get it done quickly. We've done prototypes where someone sits behind the monitor and reads the spoken parts to the user, pretending to be the computer. Don't feel bad about taking such shortcuts, remember that it's all throw away anyway.

The one rule that DOESN'T change during early prototyping is that you need to test, test, test. In fact, you should be testing more than you normally do, since you're probably throwing more new features in front of your users now than during any other part of development. Test on a weekly basis, ask lots of questions, and try to direct users towards rating the features you actually care about (but don't be leading when you do this!) It's amazing how much users are willing to forgive when they are presented with an obviously half-assed prototype, so don't feel bad about asking for feedback.

Finish the job!

It's easy to stop after making one prototype and calling it a day, but don't stop there! Analyze testing results and iterate on the prototype, taking what you've learned and making it better in the next version. Feel free to try out completely new, different, orthogonal, or contrary features/designs in subsequent builds, since you're trying to learn more about what will work. You should also start looking to fix your weaknesses during this phase – hire that artist, find more funding, or start putting together a schedule that is actually appropriate for the full title.

Deadlines are your friends, so be sure to schedule them in. It's easy to just keep iterating with prototypes forever, don't fall into this rut. Set hard deadlines for when you will finish certain versions and stick to them. Testing days are generally useful as deadlines since it'll force you to have finished builds that users can play with.

And when you're done...

Throw the prototype away and start fresh! Trust me, this is the right thing to do. It feels rotten since you've spent a lot of time working on it, but you can't build off of a hacked together prototype full of spaghetti code, stolen assets, and written in a non-robust language. Prototypes serve a purpose, but should not turn into a final game. The main things that should survive are the design and lessons learned.

Eitan Glinert is Fire Hose Games' founder and creative director. Before Fire Hose, Eitan spent several years making educational and accessible games, including AudiOdyssey, the first Wii Remote game accessible to the blind. If you have any questions on prototyping, feel free to contact Eitan Glinert at this e-mail address.