Braid Behind the Scenes

In this article, game designer Sande Chen summarizes Jonathan Blow's session at the 2019 Taipei Game Developers Forum, in which he gave a behind-the-scenes look at the development of his game, Braid.

Speaking to a packed audience at the 2019 Taipei Game Developers Forum last Wednesday, July 10, 2019, independent game developer Jonathan Blow detailed a three-year struggle against naysayers during the development of his game, Braid. The 2008 runaway indie hit, considered by many to be a masterpiece, obviously defied its critics when it sold 55,000 units in its first week on XBox Live Arcade and earned Blow more than 4 million dollars in revenue.

Blow took the audience back to the very beginning with his Super Rough Draft Version, a bare-bones prototype featuring programmer art made in Paint. Despite the simplicity, this early playable level encapsulated the design principles he intended for the game. He had been thinking about the Rewind ability, in which a player is able to rewind prior actions  This had been implemented in previous games like Prince of Persia: The Sands of Time so that players could rewind and fix mistakes, but hadn't been groundbreaking. Blow wondered how a game would change if a player had unlimited Rewind and did not have to worry about dying.

Moreover, all the puzzles in his game would be tied to this Rewind ability.  It would be about realizing mistakes, seeing the puzzle differently, and taking a different approach.  Because this was an untested concept, he wanted the game genre to be one that was simple and familiar so that when things got weird, players would not get confused.  He chose to do a platformer.

Finally, he was purposefully aiming for a game with "artistic attitude," even though at the time, it was controversial to consider games as art. Film critic Roger Ebert would famously say that video games can never be art. Blow explained that because there was no concept of art games or a big enough indie game community, it was very hard for him to recruit an artist to work on his game.  He would send prospective artists his demo and get shot down.

He read segments of an e-mail from one such artist who gave lots of unsolicited advice on how to make the game better because "the video game industry is very unforgiving." Blow speculated that the artist thought he was a confused newbie who didn't know anything about game design. The Independent Games Festival (IGF) judges in 2006 thought otherwise. Braid won Innovation in Game Design.

Encouraged by this development, Blow resubmitted Braid to IGF the following year, hoping to win a grander prize, but it didn't even become a Finalist.

Steam, which in 2007 was a heavily curated storefront, would be another dead end.  Steam projected that the game would sell less than 5000 copies and rejected the game. Blow even tried a back channel to Valve, which did not succeed.

Still, despite all the negativity from outside sources, Blow's friends maintained that Braid was something special and that they really liked it.

Blow persisted and got the attention of someone at XBox Live but even then, Braid was almost canceled twice by Microsoft and his art outsourcing company lost interest in the game.

Thinking back, Blow wondered why people, especially people paid to find future hits, didn't see Braid's potential.  He concluded that it's really hard for people to look at a work-in-progress and see its finished form.  Because of this, a lot of times, feedback will be wrong or at least conservative.  Therefore, it's vital that a game creator be able to communicate the future vision to team members and others.

In 2008, Braid won numerous awards, including XBox Live Arcade Game of the Year, and a decade later. is considered a transformative work that changed the market landscape by proving that independent games could be financially successful.

[Jonathan Blow's recorded session will be available on IGDA Taiwan's YouTube channel soon.]

Sande Chen is a writer and game designer whose work has spanned 15 years in the industry. Her credits include 1999 IGF winner Terminus, 2007 PC RPG of the Year The Witcher, and Wizard 101. She is one of the founding members of the IGDA Game Design SIG.

Shared AR Gaming Experience at NYC Media Lab!

Hi!  Apologies for the huge gap in blog posts.  I have been busy but I have news to relate!  Last month, on August 10, 2018, Peter Locharernkul, Asha Veeraswamy, and I were at the AT&T Entertainment Hackathon in NYC and our offering, Shared AR Gaming Experience took 2nd Place in the category of Best Entertainment App Overall.

Shared AR Gaming Experience

While the demo focused on transforming the board game, Chutes and Ladders, into a 3D experience, this augmented reality phone app is envisioned for use with any board game. Through the use of a multiplayer lobby, the 3D augmented reality game can be played with anybody in the world.  Asha's Donkey Kong version of Chutes and Ladders showed how easily embellishments in the form of custom animations and art could be added for seasonal holidays or rebranding for advertising purposes, as is the popular thing nowadays. (For instance, check out the Lord of the Rings Monopoly game.) 

The configuration for Chutes and Ladders can even be modified to be more of a winding staircase instead of a zigzag. With board game sales reaching over $9 billion, this expansion app is sure to extend the appeal of classic games and galvanize the already revitalized interest in board games.

On the strength of the demo, we were pleased to be featured last Thursday as part of the NYC Media Lab 100: The Demo Expo where the app was shown to the public.

Sande Chen is a writer and game designer whose work has spanned 10 years in the industry. Her credits include 1999 IGF winner Terminus, 2007 PC RPG of the Year The Witcher, and Wizard 101. She is one of the founding members of the IGDA Game Design SIG.

How to be Successful at Game Jams

In this video, game prototyping specialist Bernard François explains the steps for a successful game jam experience: preparation, concept choice, production planning, and execution.
 
Making games in 48 hours is hard. But what can you do to increase your chances of success? How can your prepare yourself for a game programming competition, such as Global Game Jam?  What are some of the strategies you could employ to turn the odds in your favor?

This video tells you all about it.

Bernard François is a game prototyping specialist and founder of PreviewLabs - the only company in the world entirely dedicated to rapid prototyping for projects using game dev technology.

The Polar Ice is Melting!

In this article, game designer Sande Chen describes her playtest experiences with the card game, EcoChains: Arctic Crisis. 

Happy Holidays! I hope everyone is doing well.  Here, in the East Coast of the United States, it's unseasonably warm for December.  While we may be enjoying the spring-like weather, up in the Arctic, the polar ice is at its lowest point ever. This is why 2/3 of the polar bear population is expected to die off by 2050.  :(  The climate change card game, EcoChains: Arctic Crisis, which was funded through Kickstarter and a National Science Foundation (NSF) grant, hopes to bring attention to this global issue.

EcoChains: Arctic Crisis

I was recently sent EcoChains for review on this blog and I thought what better place to bring it than to NYC Playtest, the monthly meeting of board game designers.  They vigorously playtest board games to get feedback from other designers.  I played a game of EcoChains with the board game designers and then I played a round with people who play board games or tabletop RPGs with kids every day.

It's a fairly quick game, estimated 30 minutes long, for up to four players.  We played it incorrectly both times, despite multiple people reading the directions repeatedly.  We also did not use the advanced cards, which probably would have made the game more interesting.

Initially, we got some polar ice cards and starter animals.  Throughout the game, we built food webs, indicating which animals consume other animals.  For example, a seal can survive on arctic cod, but in turn, a polar bear can eat the seal.  Some animals, generally the higher order ones, require polar ice in order to remain in the food web.  When the polar ice melts due to climate change, the polar bear would have to migrate or die.  In the first game, we did not realize there could be more than one node in the food webs, meaning 2 seals can build on 1 arctic cod card, so we quickly reached a stalemate, whereupon we were continually passing around cards (to simulate the migration) around the table.  The second game, where this was rectified, did run much better.  While making food webs, players try to hit goals, such as sustaining 3 whales.

In both games, we did find it hard to keep track of our cards, as the food webs can get quite large.  You almost need some kind of placemat to organize your cards.  In the second game, we didn't realize that the "good" polar ice recovery event cards weren't played out immediately like the "bad" polar ice melting event cards.  I suppose this was to simulate the situation of positive externalities in that if one party makes the effort to help recover polar ice, this helps all parties.  However, the benefactor would have to choose between taking the "good" event card or selfishly continuing on the path of accumulating points.  The player who has accomplished the most goals and has the most animals generally wins.

On the education front, the game does make it clear through the gameplay that polar ice is necessary for animal survival.  Players do learn about food webs and different arctic animals.  However, my playtesters did not feel that this was a card game that kids would pick up and enjoy on their own for fun.  Rather, the game seems like it would fit in better as a classroom activity where teachers can provide context.

Sande Chen is a writer and game designer whose work has spanned 10 years in the industry. Her credits include 1999 IGF winner Terminus, 2007 PC RPG of the Year The Witcher, and Wizard 101. She is one of the founding members of the IGDA Game Design SIG.

Teaching Iteration and Risk-Taking

In this article, game designer Ian Schreiber describes the inherent difficulty in getting students to embrace failure as a part of the iterative process.

There is an inherent conflict between the nature of classes and course objectives, when it comes to designing a game as a class project.

The best way to learn to design games is to make a rapid prototype, fail miserably, figure out what you did wrong, and try again. Repeat until you get it right. In order to do this, the student has to feel like it is okay to take risks, that it is perfectly acceptable (even expected) to try crazy stuff that may simply not work out.

But of course, this is for a grade. Enter the fear of failure. Or, it's not for a grade at all. No threat of failure, but likely no effort put in by students on an "optional" project. Is there a way around this paradox?

Here's the method I'm currently using:

• My non-digital game design project has four milestones. The first is just a high concept, target audience, basic information (number of players, etc.) and some core mechanics. The second is a rough but playable prototype. The third is a playtested prototype, with the mechanics finalized or close to it. The final milestone is a polished product.
• All milestones are graded. Early milestones are easy points -- just turn in something, anything, as long as it works. Later milestones are graded based on the quality of the design -- you'd better have done some iterations.
• For the future, I'm thinking that early milestones should be worth fewer points than later milestones. This puts less importance on early work and more focus on the final product.
• On the days where milestones are due, students bring their works-in-progress to class and present the work for peer review. This also gives me a chance to see how the projects are progressing. In the future, I should probably just give a grade right then and there for the early milestones.
• Make it clear to students from the beginning that the more they iterate on their project, the more they playtest, the more they fail and then change, the better their final project will be. Unfortunately, this is one of those things they might just have to find out the hard way for themselves. I'll try bringing in a student work from an earlier course (with permission) in its various stages of completion, to show just how much difference playtesting can make.

[This article originally appeared on Ian Schreiber's blog, Teaching Game Design.]

Ian Schreiber has been in the game industry since the year 2000, first as a programmer and then as a game designer. Also an educator since 2006, Ian has taught game design and development courses at a variety of schools, and on his own without a school. He has co-authored two books, Challenges for Game Designers and Breaking Into the Game Industry. 

Jamming

Today we see the aftermath of the Global Game Jam, with plenty of interesting games made in the last 48 hours. Congratulations to the participants for making it through!  Very impressive stuff.

Last year, I participated in my first game jam and I didn't know what to expect.  I soon realized that programmers were the most sought after teammates.  I learned what really helps is knowing how to use programs that can get you quickly started on your game.  The team I joined in the game jam decided to use GameMaker: Studio, which has a free version.  Lots of different types of games can be made using GameMaker as shown by the video:
 

Furthermore, during a game jam, I found that you need to commit to an idea and just go with it.  That's mostly due to the time pressure.  So while I wish I could have done more during this game jam besides learning how to make levels in GameMaker, I did walk away with an appreciation for these game-making tools.  Even though they may be limited in some aspects, these tools could help a lot in prototyping.

Or even with creating professional-looking games without coding! GameSalad is drag & drop and app developers have had games created using GameSalad in the top 100 of the app store.  Lately, I have been looking at Scratch, which is also drag & drop.  Here are examples of games created using Scratch:

If you do want to see or play the game our team produced during the game jam, it is a top-down dungeon crawler with musical tones synchronized to the player's movements:  Temple of the Gopher God!


Sande Chen is a writer and game designer whose work has spanned 10 years in the industry. Her credits include 1999 IGF winner Terminus, 2007 PC RPG of the Year The Witcher, and Wizard 101. She is one of the founding members of the IGDA Game Design SIG.

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.

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.