GDAM 2009: Year in Review

Originating as a proposed initiative for the IGDA's new Game Design SIG, Game Design Aspect of the Month (or GDAM) began on March 1 of 2009 to serve as a platform and community blog for game developers and scholars to discuss design issues.

Since then, we have covered several topics. They were:

• March 2009: Player Death
• April 2009: Designing Quality 2-3 Hour Games
• May 2009: Trends of Simplicity
• June 2009: Prototyping
• July 2009: Mature Games
• August 2009: Single-Play Sessions
• September 2009: Gaming the Game Developers
• October/December 2009: Pitching/Creating a High Concept
  

We look forward to more great topics in the coming year! To participate, please submit topic suggestions for future months and contribute articles. You can also become a regular contributor or an editor.

Happy Holidays! And many thanks to our readers and contributors!

January 2010: Mechanics That Artificially Lengthen Gameplay

January 2010's topic is Mechanics That Artificially Lengthen Gameplay, originally proposed by game design student Helder Mauricio Gomes Ferreira and refined by game designer Ryon Levitt and scholar Altug Isigan.

A significant number of players complain about game designs that seem to be deliberately wasting their time. Due to the amount of grinding and long walks that can be seen in this genre, it is often MMORPG's that are subject to such criticism. It appears, however, that from time to time all types of games and genres suffer from sequences that mindlessly waste the time of their players.

During its January rally, GDAM asks you to provide insight and answers to the problem of game mechanics that artificially lengthen gameplay. In the broader sense, we ask you what methods or mechanics the game designer has at her disposal to lengthen gameplay without annoying the gamers. In particular, we ask the following questions in the hope to inspire you for articles:

• What is the relationship between business models and mechanics that artificially lengthen gameplay? Which business models or design principles built around mechanics that artificially lengthen gameplay could serve to increase a game's value for both players and developers?


• How can dead time in runs and overall travel time be reduced without destroying the rationale behind the business model and the overall pace and rhythm of the game in question?


• What design methods do exist that could be helpful in creating mechanics that preserve player motivation while gameplay is artificially lengthened? How, in that regard, can we utilize psychological processes like for example matching creatively?


• What kind of ancillary reward systems do exist or could be developed and how could these help to foster a feel of environmental progression in the game that makes long walks feel like they are part of the game rather than being pointless and repetitive tasks?


• What are design methods and principles that can be helpful in manipulating felt time and making it easier on the player when gameplay is lengthened artificially? How can we stretch game sequences by building additional moves into game mechanisms without making them feel artificial?

An Advertising Approach to High Concept Pitching (Part 2)

In Part I, scholar Altug Isigan looks at the structure of commercials to see what tactics from advertising can be applied to high concept pitching. In Part 2, he explains the role of the structural parts of commercials and gives examples on how these can be used to shape a high concept.

Expose Benefits over Features

In the exposure part, it is most important that you avoid listing mere features. They may all mean a lot to you and the group of people you work with. But a feature, if it is not explained as to what benefits it brings to the user of the product, could be easily overlooked or deemed insignificant. So you got to remind your addressee of what the feature translates to in real life and how, in practical terms, it answers the need you’ve addressed in the teaser.

So, how do we expose a feature as a benefit? Here are two examples: Instead of saying that the game can be played with up to six players you could say that it is for the whole family or can be played with a large group of friends. Instead of saying that the game features a total of 72 hours of gameplay you could say that it features more than 30 exciting levels with over 100 items to be unlocked.

What’s really important is to translate the feature into the type of “currency” that makes sense to the user and expresses “value” on her terms, not yours.

The Peak of the High Concept

We don’t write a high concept because we want it to be forgotten. We write it because we want it to be actively considered by our addressee, and because we want it to be remembered over longer periods, even if it initially got rejected. Well, that is where the climax jumps in.

On one hand, a climax is something cool or funny or worth to remember about our presentation. A pun, a wit, a catchphrase, anything that is impressive or fills the heart with lightness. The climax presents us something that we will remember whenever the same need resurfaces. And the other way round: remembering the climax will make the addressee think over and over of the idea that had been pitched.

On the other hand, the climax can also be build upon a promise: Something that will increase what the addressee can gain from the proposal if she decides to maintain her interest in it. Maybe there is already work in progress about a sequel to the proposed idea? Maybe the proposed game introduces a technology that the company’s whole product line can benefit from, once it is being crafted? Whatever the promise is, it should definitely be something intriguing.

Finally; don’t forget: ideas are not rejected solely because they are bad. Sometimes you just weren’t lucky enough. Maybe it was not the right time for submission, but who knows, six months from now, your high concept might be exactly what the company is looking for. Give your addressee a reason to remember your game idea.

So, what’s next?

No advert is really complete without a call for action. This is simply when you invite your addressee to take a next step (one that takes her closer to your idea):

-“We’re having a testing session for the game on Monday afternoon. Come join us.”

***

What is there more to say? I hope that this article was useful and created in you the desire to have a closer look at advertising techniques. Good luck with your proposals!

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.

An Advertising Approach to High Concept Pitching (Part I)

In Part I of this article, scholar Altug Isigan looks at the structure of commercials to see what tactics from advertising can be applied to high concept game pitching.

First and foremost we need to remember that the high concept has a target audience of its own. Often this target is the company’s creative director or someone in a similar lead or executive role who is well aware of the trends and brands out there in the market. This person will have a strong gut feel for what sells and what doesn’t because of her prior industry experience and closer relations to the people in the company’s marketing and R&D departments. Furthermore, as part of her job, this person must maintain a certain vision about company goals and product lines. It can be assumed that this person is skilled in seeing whether there is a match between the game vision in the proposed high concept and the player profiles that the company usually targets with its products (or now plans to expand into). Our goal is to communicate to this person the "match" we believe our game idea is.

Now this goal is exactly the reason why we should look into a few advertising techniques to find out whether we could learn something from the structure of commercials for better pitching.

The Structure of a Typical Commercial

To put it very simple, the structure of a typical commercial looks like this:

Teasers = Holding Mirrors into Faces

Teasers are not just fancy graphics or sounds. They are active attempts to pin down someone as their addressee. That means that teasers express a need or a problem of the addressee in a way in which the addressee usually isn’t able to express it. When addressees are confronted with the teaser, it will catch their attention because they will immediately relate to what is being said and they will like it that something about them has been expressed so much to the spot. Being “identified” by the teaser, now the addressee will be curious and willing to listen to more, since it looks like someone is really understanding them here. In short: whatever problem or need the teaser addresses, it should translate to the addressee as “Now that is something for me! Let me have a closer look at it!”

But it’s not just about finding the right title, tagline or catchphrase. Teasers are also about using the right graphical devices to create an overall impact and to guide the reader’s eye to what is essential. You should always carefully consider your layout and typography options. Even if it is a single page, the high concept can already reveal mood and identity through font type and size, spacing, paper type and color etc. Maybe you can come up with an illustration that serves as a summarizing metaphor of the game?

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.

5 key steps of pitching a successful and original game IP (Part II)

In Part I, lead designer Benjamin Krotin describes the prepatory work that needs to be done even before meeting with a prospective publisher. In Part II, he gives advice on how to find the right publisher and make the sale.

3. Fitting A Publisher

Far too often, developers will take their perfectly-crafted documents
/presentations and bombard every single publisher around the world with them. Although this is not an uncommon strategy, approaching too many companies too quickly could result in a diluted effort. Instead, developers should scout out which publisher would best suit their IP, and then target them for a more specific approach. For example: An imaginary IP like Super Magic Princess might be a good fit for companies like Disney Interactive, Majesco, or THQ, but this certainly would not be the case for an IP such as Ultra Bazooka Troopers. That sort of game would likely be more suited for companies such as Sega, Activision, or Midway. By tailoring their pitch to the appropriate publishers, developers decrease their odds of being shot down before they have had a chance to show off their work. By doing this, developers reduce the risk of overexposing themselves too quickly. Finding the right publisher to present an IP to is almost as important as coming up with the one.

4. It's Who You Know!

Okay, it is time to confirm a long-standing theory, it is who you know. Any developers that are ready to start approaching publishers should stop in their tracks and give their address books a quick run-through before taking another step. If that address book comes up a bit short, it is time to talk to someone whose is not. Before an IP pitch is even complete, developers should begin approaching the business development managers and producers at various publishers, and start getting their feet in the door. Whether it s through a cold-call, an e-mail, or through an introduction, it is best to know the person or persons that will be receiving a pitch before they are even sent one. This way, a pitch becomes more personal, and it becomes easier to express the emotion and principles behind a concept. Additionally, when the person at the other end is a friend instead of just a contact, a developer's project is likely to get more attention and avoid ending up in the "to-do" pile. By befriending the right people and establishing a proper network of connections, developers are letting themselves get known before they have even shown what they have been working on. A good rule of thumb to remember is this: It's who you know first, and then it's what you know.

5. The Meeting

The meeting is simultaneously one of the most over hyped and underrated aspects of any game developer's pitch. Getting a meeting with a publisher is usually the first step to taking a project out of the conceptual realm and bringing it closer to a development deal. Typically, whenever the first meeting is arranged, its ultimate purpose is to introduce the development team and its IP to the first set of decision makers at a publisher. Hence, the first meeting, though important, is really only one small fragment of an overall larger and more meeting-filled pitch process. The most important aspect of any meeting is to get the point across... What is this game about? Why does it fit this publisher? Why will it succeed? These are all just of a few of the questions that must be answered (without them being asked) if a publisher is going to take any project that is presented to them seriously. Another important aspect of this sort of mindset is to also always remember that by default, it can never be assumed that the publisher has any imagination. This may sound harsh, but the crux of the matter is that it is true. This is because the project acquisition arm of any given publisher is usually made up from more than just a few people. As such, it becomes nearly impossible for concepts like imagination to flow seamlessly between the staff, as everyone's interpretation of a game will likely differ. This is further compounded by the hierarchy that exists within these units. Person A, who is first in line to review something, is usually not in any way obligated to share what they have found with Person B, who is above them in the chain of command. As such, a pitch can be lost before it has even had a fair review. To prevent this, a developer must realize that they are never really pitching to a publisher per-se, but rather to a focused collective of individuals whose job is to either approve or reject ideas. If an idea is approved, it is then bumped to a superior, whose job is to do the same thing. Once enough of these individuals agree, that is when an IP gets a chance. By being informative, original, and extraordinarily persistent, a developer with the right IP can accomplish great things!

[This article originally appeared on the Mary-Margaret Network Blog.]

Benjamin Krotin is President and Lead Designer at 1988 Games, where he is currently pursuing the well-received original Wii IP Zombie Massacre. In addition to managing the day-to-day operations of 1988 Games, Ben is also a contributing writer for Cigar Press Magazine. Ben can be reached at this e-mail address.

January 2010 Poll

Please come and vote for the January 2010 topic!

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

• Cheats
• Mechanics that artificially lengthen gameplay
• Multiplayer Economies

Please vote by December 25. Thank you!

5 key steps of pitching a successful and original game IP (Part I)

In Part I of this article, Lead Designer Benjamin Krotin describes the prepatory work that needs to be done even before meeting with a prospective publisher.

The game industry that we thrive in today is filled with many great ideas and many great idea makers. However, far too often great ideas and opportunities somehow get lost in the fray and sadly dwindle down to non-existence. To help reverse this, there are five key steps that anyone, at any level of game development can follow. By maximizing the methods by which an IP is produced and presented, a developer can increase their chances for success with publishing.

1. Making Sure Your Idea Is Novel

Rule #1: Do something new.
Rule #2: If you are not going to do something new, at least do something different!

If one were to break a game down to its core elements, what would they find? Sure, there is story and artwork, and of course audio; but what really makes a game?

What makes a game is gameplay, and gameplay can be translated in basic terms as the raw, visceral enjoyment that a player receives from pushing buttons on a controller. Much like story is to cinema; gameplay is by far and away the single most important aspect of any game project. When combined with story, art and sound, good gameplay becomes magic, and capturing this magic is what every designer's job should be. With this in mind, any proper original IP should be grounded in solid and preferably original gameplay. Placing gameplay into the equation first, even before story, will help distinguish an IP right off of the bat and will serve as a solid foundation upon which the rest of a game's assets can be built. But gameplay alone will not move a publisher, so before a single designer can work their craft, the development team as a whole must find their niche before deciding which direction to take. Existing market conditions must be carefully examined and evaluated, with developers keeping in mind that an IP, which in its own way caters to either a lucrative or untapped market, is much more likely to succeed. Creating something original from the bottom to the top and targeting it to a distinct market will be far more enticing to a publisher than just blindly making yet another first-person shooter for the XBOX 360. That is of course unless this first-person shooter does something new and cool. One look at companies such as Nintendo, Harmonix, or Bungie is a testament to this notion.

2. Documentation

"No one reads that stuff anyway..." Anyone who has ever pitched an IP to a publisher has likely either heard this, or has even said this themselves. Although mostly true, it is still extremely important to have a bulletproof document that not only outlines, but concisely explains the game and its mechanics. Nothing will catch a producer's or business development manager's attention faster than a clean and easy-to-read document that answers all of their questions and shows off what an IP is about. The best way to tackle this is to break the game design down into a brief concept outline document that covers basics like story, gameplay, and controls. This is especially true for the controls, as these are the real meat of any game. A successful control layout will show a concise control diagram, and will include a breakdown of all of the various control mechanics and basic gameplay states that can exist within the outlined gameplay. It is important to be thorough but not to go overboard, as no one will be able to read, let alone understand any control breakdown that is too complex. By being thorough and concise with outline documentation, a developer is effectively presenting a summarized game design document to the publisher, but one where all of the technical fluff that is typically found in a full-scale design document is cut out. Bottom line: Get to the point, get their quickly, and then dress it all up with pretty pictures.

[This article originally appeared on the Mary-Margaret Network Blog.]

Benjamin Krotin is President and Lead Designer at 1988 Games, where he is currently pursuing the well-received original Wii IP Zombie Massacre. In addition to managing the day-to-day operations of 1988 Games, Ben is also a contributing writer for Cigar Press Magazine. Ben can be reached at this e-mail address.

GDAM Reboot

After a very fruitful first year, the Game Design Aspect of the Month editors are preparing for the new year with the goal of building on last year's achievements and improving GDAM's features. We want to continue to present game designers, industry professionals and game researchers with a platform for high-standard discussions and exchange. We would like to express our gratitude to our readers and to all those who during the past year contributed to GDAM with their articles or took the time to participate in our podcasts: Thank you very much!

GDAM January: New Topic Suggestions

We are interested in hearing your topic suggestions for the month January. Please contact one of our editors if you believe you have an idea that would make a good GDAM topic. You can find out more about topic suggestions here. Some of our topics in the past were Mature Games, Prototyping and Player Death.

Call for Editors

GDAM wants to strengthen its team of editors and would like to hear from individuals who would be interested in joining us. Routine tasks of GDAM Editors include:

• Developing or taking care of incoming topic suggestions
• Acting as contact points for writers and assisting them during article submissions
• Editing and preparing articles for publication
• Participating in the production and publication of GDAM podcasts
• Promoting GDAM via various communication platform

A certain level of commitment is expected.

Current GDAM Topic: Pitching and High Concepts

We are still looking for articles on our current topic Pitching and High Concepts. The topic was suggested by narrative designer Tobias Heussner and you can find a more detailed topic description here. Those who are interested can also participate in our podcast session on Pitching and High Concepts. Please contact our editors for more.

Pitching and High Concept

In this article, narrative designer Tobias Heussner shares his thoughts on pitching and high concepts.

As I said in the introduction, I believe that the high concept is a very important tool and each designer should be able to handle it. Maybe you like to get together with your co-workers and try to come up with some high concepts for your favorite game, if you’ve never used high concepts before. You can also take a look at the available loglines from movies or other games to get a better understanding.

A very good method to improve these concepts and to approach them is called the concept of unique and familiar. This concept is proposed by Karl Iglesias for screenwriting and here I’d like to show how we can use it for games.

How can something be familiar and unique at the same time? Isn’t this a contradiction? It is, but still can be used in one sentence by combining a unique element with a familiar one.

Usually the unique element is the part of your idea no one has done before or at least not in this way. To find this idea you may want to ask yourself the questions “What is new?” or “What makes this game unique?”

The familiar element is something we can relate to, for example emotions or definitions. Questions to find this element can be “How can one relate to this idea?” or “Is it understandable?”

Here is an example how a high concept for the game SimCity can look like:

"Be a god-like major and create/manage the city of your dreams."

Clearly the familiar element is “god-like major”, because back when the game was developed, god games been a solid part of the market and everyone could relate to the control schemes and design ideas. The unique element is “create-manage the city of your dreams”, because even if we might have some ideas how this may look like, back then we didn’t had a chance to see it in computer games.

Using the same principles for your own concepts today may not only result in a clearer vision, but also in a concept which gets higher attention during pitches.
Finally I’d like to share some don’ts according the high concept that proofed being useful for me.

1. Never compare your idea with an existing one within the high concept. If you do so within this core vision it simply can’t be unique any longer, because using sentences like “It is like X mixed with Y” simply indicate that you propose something that’s in general been made before.
2. Avoid being too general, because if you are too general you’ll miss the chance to communicate the beauty of your unique idea.
3. Don’t complicate it, because a high concept should help to communicate your idea not to confuse others.
4. Avoid scientific terms, because you never know who’s reading your concept and if he would be able to understand these terms.
5. Never use any possibly insulting term, because again you don’t know who would reading your concept and you surely don’t want to unintentionally insult the executive who is supposed to sign a development deal.

These are my thoughts on this topic, which are surely not the ultimate answer, but I’d like to use them to kick-off an exchange of ideas. I hope that this exchange will help us all to grow and to proceed in the quest of creating better games.

Tobias Heussner is a Game/Narrative Designer, currently working as an Associate Producer for Radon Labs GmbH in Berlin, Germany. He has been involved in professional game development for over 10 years, has worked in different design and management roles, and has worked on 15 different, published titles, including top-sellers like Paws&Claws: Pet Vet and the AAA-RPG The Dark Eye: Drakensang.

New Editor Notice

Sorry for the delay in posting articles and podcasts. Because of this, I have asked for help and Altug Isigan (see bio below) has graciously offered to step in as an editor of Game Design Aspect of the Month.

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.

The Rise of the Technical Artist and Tools Engineer

In this article, software engineer and project manager Casey O'Donnell discusses the role of technical artists and tools engineers.

Game development has seen a dramatic shift in the last five years. The amount of storage space available for developers to use has risen dramatically and the expectation on the part of players and publishers that this space be used has risen as well.

This has meant in many cases that more content must be placed into a game. More levels, more models, more textures, etc. All of this has required a shift in how developers approach game development. "The pipeline" has become much more important. The pipeline is at its simplest a process by which a particular game asset (sound, image, model, level) is placed into a game.

As the demand for content has increased, the pipeline has become much more important. Specifically the turnaround time for an artist or designer to see something in the game such that they can ensure that what they've constructed in 3D Studio Max or Maya indeed looks as it should inside the game. Or, in the case of designers, that a level moves as anticipated, or that indeed "out of bound" areas cannot be accessed.

The pipeline has become much more complex over this time period, and its two main laborers have become the "Technical Artist" and the "Tools Engineer." Each serves different purposes and many are the same person in smaller game studios. Technical artists, in my experiences, have often been artists who first started college as computer scientists hoping to make games, only to find that such is not the mission of most computer science programs. In the mean time however, many of them did learn something about scripting/programming languages and assorted computer and operating system nitty gritting elements before migrating towards more art friendly disciplines. Many technical artists simply emerge in small game companies, making scripts, toolbars, and other utilities that speed the process of getting their work into the engine so they can see it. They are the saviors of other artists when things don't go quite as anticipated. More recently this has become a specific sub-discipline of artist in many game studios.

The tools engineer, much like the technical artist, has been an accident of history, rather than a deliberate shift of the industry. That said, I must admit my predilection towards the tools engineer, having been one. Tools engineers were typically engineers that found themselves watching designers or engineers continually making the same mistakes over and over getting things into the game. Tools engineers' sole goal seems to be helping others manage the chaos of game development. This has lead to the construction of custom tools for generating all sorts of items in game, many of which may have been previously constructed with the editing of text, ini, or XML files.

Those editors that you see for games are the babies of tools engineers. Perhaps unfortunately for the tools engineers, they have also become the masters of build systems that must frequently perform numerous tasks and integrate the persnickety compilers and tools developed by console manufacturers with little regard to usability.

Ultimately, however, each one of these disciplines has made it their goal to create game development systems that respond rapidly to the work of the developer. Adjusting a slider and being able to see the change in particle system behavior is much more intuitive. Dropping a new texture onto a model or selecting it from a drop down menu is far more responsive. Clicking a single button to perform a model check, export, and load into the game engine takes less time than following a check list. These systems are actually extensions of what I previously wrote about with regard to debug menus and consoles within games.

Their objective is to provide flexibility and make the lives of developers easier. Except that in this case, gamers rarely come into contact with the proprietary tools and pipelines developed by technical artists and tools engineers.

In some cases, when a pipeline or tool chain is effective enough, it becomes a company asset, such as the Unreal Engine and its array of tools. Even XNA Game Studio shows its colors with its accompanying asset pipeline.

Casey O'Donnell has worked as a software engineer and project manager both in and out of the videogame industry. He is a faculty member of the Telecommunications department at the University of Georgia and is currently the Athens Chapter President of the Georgia Game Developers Association.

The Console, Debug Menu, and Gaming Development

In the first article of a series, software engineer and project manager Casey O'Donnell talks about interactive "game design" infused game development.

In its simplest form, game mechanics have been around game design and development for a long time. The "debug" menu or "console" found in many games seems to be one of the foundational means by which developers have attempted to make their tools more flexible. In many games, though the debug menu remains hidden, or actually stripped out of shipping games, sometimes it re-emerges providing players and game enthusiasts with new avenues to examine the roads not traveled in the design and development of a game.

The console, though perhaps the most powerful, is the least intuitive and least interactive. It is commonly used to issue specific commands to the underlying game system. Variables can be assigned new values, thus adjusting the underlying mechanics. Boolean variables can be turned off or on, indicating whether or not particular program paths or options will be executed. But ultimately it becomes a task that isn't easily played. Commands are issued, and the developer returns to the game to see if or how those changes affect the overall game system.

The debug menu, on the other hand, while quite similar, will often offer the player/developer a range of options. Exposed variables will be listed, with current values and the option to change them. In some cases, specific actions can be executed. Characters can be spawned or destroyed. Models, textures, sounds, and other options can be substituted. Levels can be loaded, missions launched, or specific cut scenes played. But, most importantly, the debug menu offers a range of options visually to the user. They need not necessarily know the commands that make a particular action occur. The menu provides the user with the information regarding what can be changed.

Ultimately though, the console and the debug menu were simply a first step down a path of moving design data outside of the core source code of videogame systems. They are simply the most obvious form of a broader movement within game design and development. "Data driven" design is nothing new in the world of software developers, but for many game developers it can seem a relatively new concept. Given than many engineers in the game industry are self taught from books and sample code from others, the idea that design elements should be external to the games underlying code systems can seem foreign. Models need to be loaded, not based on hard-coded source, but based on design data from game designers. Artists need to be able to specify a range of textures applicable to a single model and the frames associated with animations.

In many cases "consoles" are merely the interface into the underlying scripting engines that have been created as interfaces by which designers manipulate the game worlds presented to players. Thus, my next post will focus more on technical artists and tools engineers, whose job it seems to push the envelope with respect to interactive "game design" infused game development.

Casey O'Donnell has worked as a software engineer and project manager both in and out of the videogame industry. He is a faculty member of the Telecommunications department at the University of Georgia and is currently the Athens Chapter President of the Georgia Game Developers Association.

October 2009: Pitching/Creating a High Concept

October 2009's topic, Pitching/Creating a High Concept, was submitted by game designer Tobias Heussner.

Tobias writes:

“It’s easily understood.”

Who doesn’t want to hear this, when he’s pitching an idea?

We as designers are usually faced with this problem of creating nice, colorful, easily understandable pitch docs every once a while. How to’s for creating these docs could fill entire books and it would still be comparable to the quest for the Holy Grail. Since it’s such a complex topic, I’d like to focus on a very small, but in my mind very important part of it within this month's Game Design Aspect of the Month.

The High Concept

The term, high concept or tagline, was developed in the early 1970’s in Hollywood for movie productions. In general it describes the idea of condensing your whole story, or in our case game, down to 1 or 2 sentences. This is usually very helpful; because it shows that you have a clear vision of your project and can serve as the core vision during the development phase. Also another benefit kicks in, which is that due to its shortness it’s easy to communicate.

• How do you communicate your idea, if you only have 5 minutes?
• Do you already use the benefits of a High concept?
• How does a high concept fit in your normal design/pitching/development process?
• What are your steps when creating an appealing high concept?
• Do you have other, maybe better ways to communicate your ideas?

I’m looking forward to your answers, your comments and hope that it’ll help us all to create better games.

Tobias Heussner is a Game/Narrative Designer, currently working as an Associate Producer for Radon Labs GmbH in Berlin, Germany. He has been involved in professional game development for over 10 years, has worked in different design and management roles, and has worked on 15 different, published titles, including top-sellers like Paws&Claws: Pet Vet and the AAA-RPG The Dark Eye: Drakensang.

Gaming the Game Developers Podcast (Part I)

Unfortunately, due to a malfunction in GDAM-IT, the second half of the podcast is elsewhere.

In this podcast, producer Billy Cain, game designer Josh Sutphin, and game designer Grétar Hannesson discuss the topic of Gaming the Game Developers.



To download the podcast: go here.

Games Referenced: Auto Assault, EVE Online, World of Warcraft, Scribblenauts

Billy Cain’s game industry career began in 1992 at Origin Systems. Since then, he has designed, developed, produced, and contributed to many award-winning video games including Wing Commander: Prophecy and SpongeBob SquarePants: Revenge of the Flying Dutchman. As co-founder of Critical Mass Interactive, Mr. Cain has created a world-class game development and outsourcing company that has served Disney, Electronic Arts, Midway, NCsoft, Sega, Sony, THQ, Universal, and many other studios.

Grétar Hannesson is a game system designer and an enthusiastic student of human behavior and choice architecture. He cut his teeth on EVE-Online where he served many roles before that of a designer and is now working on an unannounced title for Ubisoft Montréal. He (sporadically) writes about game design and related workplace matters on his blog.

Josh Sutphin is the design lead at LightBox Interactive (formerly Incognito Entertainment). He also produces mods, indie games, and electronic music, and blogs on game design and politics, at http://www.third-helix.com.

October 2009 Poll

Please come and vote for the October 2009 topic!

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

* Emotive Games
* Pitching/Creating a High Concept
* Mechanics That Artificially Lengthen Gameplay

Please vote by October 18, 2009!

Need More Bookmarks

In this article, programmer Nels Anderson argues that games should use a "bookmark" system instead of outdated save systems that waste the player's time.

Single-play sessions are difficult to design for, because exactly how long they will last is completely unknown. I've played Advance Wars: Days of Ruin for the half-minute or so it takes the elevator in my apartment building to get down to the laundry room floor. We ought to allow single-play sessions of any length, but the inertia of existing save system designs makes this difficult. I believe separating the two similar but distinct purposes of save systems will make this goal much easier to achieve.

Why are most pop songs approximately three to four minutes in length? Classical compositions are rarely that short. The answer is that the original vinyl 78s and 45s could hold about three to four minutes of music per side without sacrificing too much quality. What was originally a technological constraint became integrated into the way music is created. This technological legacy can still be seen today.

There are actually many facets of games that may result from obsolete technical constraints, but I'm going to address just one here- save systems. Specifically, this was inspired by something David Carlton wrote (with Randy Smith's MIGS presentation about saving before that).

The original purpose of save systems was to allow players to finish games that were too long to complete in a single sitting. The first console save systems didn't even use storage on the cartridge, they simple provided codes (or Castlevania's weird weapon grid) that loaded the game in a certain state. Since, they've become more complicated things with numerous implementations. They may or may not be encouraging negative compulsive behaviours (I tend toward yes on this one).

Unfortunately, the original purpose of save systems and the dynamics that emerge from the newer implementations have become confounded. Their original purpose ought to be broken out, leaving the rest of the save system to be addressed independently.

Simply, players should be able to stop playing a game at any point without fear of losing significant progress. To do anything else is to be disrespectful of your audience's time. It's absurd to require the player to wall off a section of their day to play your game. No other in-home media does this and there's no reason why games should get a pass. (As an aside, all cutscenes should also be pausable. Period.)

I like the Metroid series a lot, but I still haven't played Metroid Prime 3: Corruption yet almost exclusively because of its save system. Maybe MP3 isn't as extreme, but previous iterations required about a solid hour of play to make serious progress. Otherwise it would seem like a waste of time, with much of it spent trekking out and back to the save points.

If having that save anywhere/anytime is problematic to the game's design, providing a single "bookmark" save slot that is deleted after it's loaded is sufficient. Many DS games provide this functionality and as someone who has recently implemented a save system, it's not hard to do.

It doesn't even need to load the game exactly as it was saved, but something reasonably close ought to be ubiquitous. David discusses that save/load systems that force repetition of content as a punishment for failure are the reason why he'll save compulsively. And I could not agree more. If you're forcing players to repeat swaths of your game as a consequence for failure, something has gone off the rails.

Playing Little King's Story recently, I can't help but feel that their save system is unnecessarily punishing. You can only save in one place, there are times when you simply cannot save at all and if you fail in combat, you're immediately booted back to your last save. There was a point where I wanted to stop playing LKS but had to continue for about another twenty minutes or be forced to abandon content that could not be restored. And this was just after a boss fight! I can already tell that the LKS save system is going to force me into the compulsions Randy describes because the penalty for not saving is so extreme.

Japanese developers seem worse about this than NA/European studios, but this problem appears everywhere. We've all seen it. It's the save point just before massive, unskippable cutscenes that rolls immediately into a very difficult boss fight. It's the failure that forces you to perform the exact same series of actions again and again. These things don't make the game more challenging, they don't make it more interesting, they simply make the game more frustrating.

Having a save mechanism that's respectful of your player's time ought to come easily if you're empathizing with them. Provide a solution for the original problem the save system was meant to address. Beyond that, we can experiment more with save systems, looking for ways to move away from compulsive save/load behaviour. But unless players believe they can be confident progress won't be lost to punishing save systems, we're never going to move past save/load OCD.

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. A version of this article appeared there.

Memorable moments through reading and gameplay sessions... a contrast (Part II)

In Part I, game designer Keyvan Acosta looks to his experiences with narrative in books to share insights on achieving a meta-gaming language. In Part II, he discuses how to implement play session takeaways that give users the tools to choose how they want to play the game.

Interactive Immersion is one of these game elements we've known to pay attention to when both designing games and measuring play involvement. While trying to maximize immersion, designers should be aware that life will interrupt at any time; hence the pause button's formality! Everyone has a built in “bladder control meter” that nags you and says, “get up and take care of IT before IT gets embarrassing!” However, when crafting a play session's length we don't need to concentrate on the length of time unless we seek to impart the player with a very specific, topical takeaway (dynamical meaning - Jon Blow) where the meaning is required - almost forced - to be understood within that fixed time frame. I mostly find that the summary of the play session, its narrative/story takeaway, mostly occurs between gameplay sessions (to be applied later), while in many art/indie games, the interactive takeaway is presented and employed during play, as if the understanding of it is message is desired to be exploited instantly. Maybe this is because many indie games, many of which are made for online platforms with varying access to drive space and a small length-of-play budgetary constraints, don't rely on saving mechanisms. This is probably a good thing and probably the main functional constraint that is allowing them to further game's meta-cognitive functions more that AAA productions have recently explored.

The following is some advice/suggestions for implementing a play session's takeaway without forcing a rigid play-time clock onto a player.

• Don't just measure the time per play session, measure how the player performs simple tasks and modify the delivery of the most relevant portions accordingly. Player profiles should be used to assist this, taking into consideration more than just the difficulty setting they are usually used to. How long they've been playing? how many times they've started the game? etc.
• How about instead of asking players “how difficult?”, ask “how much time do you have to play today?”... and balance for that! Not parental control like, where it just shuts off. Help them decide to take a break! Wii sports does this, but it should check first if you're in (willingly) for a marathon session...
• Game consoles will eventually have “web 2.0” calendar clients, etc. (Steam client lets you know of clan appointments already) If games already scale and balance their play objectives for co-op, why not balance for a lifestyle? Rock Band has learned from this! At parties their inclusion of a No Fail mode in a way that doesn't make the hard core feel guilty has been a buzzkill saviour. Things like that: just. Make. Sense.
• Game flow is crucial! Take a standard (unique to your game) time to introduce elements and match them with at least as many “chapters”, areas/levels, puzzles as things/verbs the player can perform... that lets them notice an interactive rhythm. If the game is meant to last 3 hours, why not change the atmosphere every hour to help with a perceivable rhythm?
• Vary level transitions, timing, atmosphere, to help them understand that time has actually passed.
• Attach meta-information when keeping an in-game completed objectives list and let players filter it for a character's verb/action meta-tag. For instance, every time you encounter a plot point, stamp the event's entry with tags such as “Hat”, “Ms. White”, “in the library”, “with the rope”, date/time, etc. Later, when the player is looking at their journal, if they select any clothing item, they'll be able to see what they've worn most frequently. Also add these tags to the Achievement you give them in order to increase its uniqueness.
• Avoid grading them if you're just going to show them a report card and ignore them until next “GPA” report. Implement a game mechanic that is a based on that grade, not just unlock some other ending. It's simply a waste to gather information about somebody and never put it to use... especially for our creative, dynamic purposes.
• NEVER PUNISH THEM FOR LEAVING A GAME SESSION. Never, EVER, prohibit the players' interactive ability, i.e. skipping non-interactive cut scenes.

About session time:

• Let the game world mature with the player, like pulling weeds in Animal Crossing. Allow the game world to grow and change as the player spends time with the game
• Don't just change the environment because they got to it, change it according to how long it took them to get there.
• “However harsh the winter, people love going through the seasons”, use a real-time date/clock (NiGTHS' 12/25 Christmas day session).
• •Manage the player's sense of time dilation. Help them modify interface narrative elements like speed of animations, transitions, cut scenes, dialogue, etc. to their liking.

Designers must learn to help the player realize what happened in (or SINCE) their last session; 360 Achievements being one solution. Fallout 3 uses the loading screen in this spirit, but we still have one more layer to go... sharing with the community of your friends how you've accomplished the feat (spectator mode, record a ghost, uploading to YouTube, meta-tags, etc), and making this a universal system across ALL platforms (like cross-referencing a reading session with friends). HALO3 recordings let others see a session from different camera views... Why not create a montage of what they've done in-game up to any point: like Dumbledore's Pensieve? Our Pensieve would need to be a platform/portal wide system (Steam, XBOX Live, Kongregate), where either all games support this, or none do. Let players record in-game play journals, like Valve Software has developer journals in their recent blockbusters.

Hard and extreme difficulty selections artificially inflate the length of a game session; and the quicksave-quickload cycle erodes play sessions by removing softening the impact of choice. If one of our strengths is dynamic construction, why not shift the session's difficulty through different game mechanics, where they'll help the player understand and manipulate "emergence" more directly by exposing the underlying meta-information more readily. Some games already do this (Goldeneye's multiplayer settings, Left 4 Dead's The Director) and help the player understand the game at a meta-layer, but most games let players modify these settings in multiplayer only, not single "parent” mode. “This is the only level!” by Armor games implements this expertly... if you know the play session will require repeat visits, then make the repetitions as meaningful and as uniquely playful as possible.

I believe that games will extend the Input Process Output cycle... breaking through the 6th wall: to show players we know what they're thinking; i.e. Input, Process, Output, Reaction, Acknowledgement. This is where bio-sensors are going to lead to; to a companion medium that truly reacts to and engages you with its awareness of your individuality. Much like how HAL behaved when playing chess with Dave ;-) Just imagine a game that knew how you felt, how to know you and how you're affected by the experience – like a mom reads to a child. It could then heighten or reduce the intensity of a play session; lengthen or shorten its duration, customized for how YOU feel or have indicated you want to feel. Once this exists, we could assist players with a way to interactively earmark any experience in our unique way; nuanced with individuality, meaning, and care. Regardless of the technology being available or not, we need to be designing with this in mind today, some people already are... and it's coming faster than you think.

Repetition creates familiarity with a creator's style... the message AND “voice” in the piece. Just like a good song AND musician becomes GREATER to the listener through more listens, so do games. So, sometimes less (shorter) is more (long lasting) because it lets you revisit it again ang again. A literary example of this “brevity as wit” is Hemingway's “For sale: baby shoes, never worn.” <-that's the whole story! In Jason Rohrer's Passage you can explore the sense of loss and mortality in just 5 minutes... a record of sorts. The authorial voice is loud, which is not surprising since he did it all himself! Yet it takes Final Fantasy 7, more than 15 hours to “kill” Aeris and share with you a similar statement... the grinding being obviously negative; even to SquareEnix. I cannot truly suggest to extend these shorter visions through longer lengths of time, or to spread them across a predetermined minimum number of play sessions; they achieved what they set out to prove within those constraints and succeeded.

We can't pretend to build on our strengths without consensus and common goals; being like giving a foreigner only a dictionary of our local argot and hoping he can understand all our literature. We shouldn't just settle for spell checkers to accept “gameplay”, “multiplayer”, etc without red marks. Of course, the length of time a player will spend on any game will always depend on their enjoyment and understanding of current in-game events along with our ability to communicate these game structures to them. Let's give them tools to bolden and highlight a session and to know what to write on the margins. Let's manipulate that 6th wall and notice how players fluctuate between conscious and subconscious mental models of a game's challenges; i.e. what they explore in the possibility spaces of our creations, that which lies between what they remember has happened, what they're attempting, what they know they could do, what they suppose could happen, and what they want to accomplish; all the while competing against real life – a challenge we should only accept responsibly by teaching them to trust that you or your game is not cheating or toying with their time! Let's borrow “closure” as a main gameplay element and let's notice what we implement at all cognitive layers, so when they explore the game's context and discover a meta-component, we greet them there, with a grin, saying “aren't we clever, and aren't you some kind of genius!”. So don't punish them for leaving you, “if you love them, let them go” with closure! When they come back - and they will... help them reminisce about the good ol' times, as many times as they will need.

Keyvan Acosta lives in Orlando, FL where he is a game designer and musician. He also teaches a 2 month game project at Full Sail University and is also the founder/host of a most excellent game development workshop called theplaymine.com, dedicated to "mining play" through the creation of experimental games, the evaluation of game development techniques, and the joy of working in a collaborative environment.

Memorable moments through reading and gameplay sessions... a contrast (Part I)

In Part I of this article, game designer Keyvan Acosta looks to his experiences with narrative in books to share insights on achieving a meta-gaming language.

Most books are very personal, intimate experiences; and in contrast to video games, very few are meant to be re-ead. The most important voice is that of the narrator, books having a more controlled authorial voice due to typically needing only one writer and only one editor to complete production. Still, from the reader's perspective, the message also relies on the his/her own interpretation of the “voice”: grammar, speech patterns, accents, font use, tone, pace, or the apparent rhythm used when reading the text. All these elements affect YOUR personal interpretation of the text, especially when it's read to YOU by SOMEONE else! When this occurs, the act of reading becomes a shared experience due to that other person's “voice”. For example, I like World War Z as a book, but I found it to be even more of a written achievement as an audio book, because the voice actors performed the accents from the countries the characters belonged to! I wouldn't have been able to “hear” them with much (if any) fidelity when imagining them. I did this with my darling Sarah with Harry Potter and the Deathly Hallows, sans character acting; She was way better versed in that universe than I was. When I'd pause confused, she'd notice and fill in the gaps; when our voices grew tired, we'd stop for the day or take any necessary breaks. Aww, we're so cute... It was a fantastic experience! I think it was as “multiplayer”, and collaboratively assisted as books can get, taking us both about 5 days across multiple reading sessions. The length of this shared experience wasn't that much different than normal, since very few books are short enough for a single reading session. Even fewer are re-readable, and aside from where the reading comprehension and ability is developing or nonexistent (kids, foreign speakers, the blind), most reading is also single reader.

To assist with context and pacing, writers and editors know how to insert deliberate breaks in the form of chapter divisions, titles, abnormal punctuation, etc. These act like reading “landmarks”, little literary bread crumbs that help us find our way back to the main path as we journey through the many roads a book offers. I rely on these because – truthfully – I have never read intending to retain every, single, minute detail between sessions per se, but I both read and play through books and games to grok meaningful moments that move me. Now, save for earmarking, the following list has become my Meta-Reading tactics (the 6th wall)... unwritten “rules” I taught myself to better guarantee continuity though my reading sessions.

• I never go to sleep in the middle of a paragraph or page of any book I'm reading. I try to read from the begining to the end of a chapter, always aware of the number of pages left to read before feeling ok to put the book down
• I keep my index finger pinched between the last page of the chapter and the back cover, glancing at the page numbers just so the last page's appearance doesn't catch me by surprise.
• * When there are no chapters to be found, I try to leave the earmark at the beginning of some dialogue/picture/eye catching text shape.
• If I have to, I prefer to interrupt reading at a good cliffhanger; it makes me want to get back to the book as quickly as possible
• When I highlight/underline, I mostly do so for new vocabulary or quotable phrases; adding notes along the margins, mostly to remember why I marked it and to seem smart to those I lend the book to...Screen-shots in games being somewhat analogue to this.
• It has been a long time now since I was quizzed on a book (I kinda miss it); although, I share books and conversations about them with my friends so that I can cross-reference my interpretation.
• I DREAD the last 20% of any book! I wonder if the writer will pull off what seems impossible: to tie all the loose ends left in the preceding 80% within the remaining few pages.
• I hate backtracking in books more than in games, and I JUMP TO BOLD LETTERS!
• I especially avoid any, ANY, spoilers (game or movie spoilers too)... my interpretation of events being more important than even that of the author; ALWAYS!

Some books have a “how to read this book” preface – books from a different era/language, etc., though most just don't need these "tutorials." Meta-reading develops while reading! It happens subconsciously helping me through multiple, separate, reading sessions; thus preventing my experience from ever feeling too disjointed or interrupted. It has also helped me connect things from different sources (when online going from link to link) and correlate them with the current text; seemingly chaotic to many). Through playing, I've developed a similarly strong meta-gaming language: things I do to make MY experience more emergent and flowing. After all, games also have a language to interpret: a voice/chorus, a narrative and rhythm like any other artistic field. Yet, this language doesn't seem to be of much use at the moment by the majority of game designers (writers) and game producers (editors); we haven't yet come to consensus about things as simple and crucial as the strengths of our medium! We can't therefore guarantee its consistency to ALL players through all sessions. Literature has defined and solved many of its problems as well as found many tools to assist its narrators; and thus its meta is easier to appreciate and manage. Just google “literary elements” and you'll notice a consistent discussion! Until we compile our own defining elements, we'll have to continue to borrow and steal them from other accepted mediums and realize that they may or may not match our specific needs. In other words, the "voice" we're utilizing now is hard to hear and mumbly.

Keyvan Acosta lives in Orlando, FL where he is a game designer and musician. He also teaches a 2 month game project at Full Sail University and is also the founder/host of a most excellent game development workshop called theplaymine.com, dedicated to "mining play" through the creation of experimental games, the evaluation of game development techniques, and the joy of working in a collaborative environment.

Computer Play Sessions of Children Under 6

In this article, game designer Traci Lawson explains the unique challenges of designing computer game play sessions for preschoolers.

When you plan or design a game play session for a preschool-aged child, it’s essential that you step into their world for a moment. See the computer (or DS, Wii, iPhone, whatever applies in your case) through their eyes. For the sake of simplicity, let’s consider a computer game. When a preschooler gets ahold of the computer, it’s a big deal. In many families, children under the age of 6 do not have the freedom to use the computer whenever they want. To them, the computer is something the grown-ups and big kids use. Computer time is something special.

When a preschooler has a mouse in her hand, she wants to use it. She wants something to click on, and something to do. Like adults and older kids, preschoolers have little patience for listening to directions. When they’re in the mood to play, they want to play, not hear directions. The same goes for an opening story. If the child was in the mood to watch a video, she would have sat in front of the TV, or clicked on the video section of her favorite website. When a game has a lengthy animated intro, many preschoolers are impatiently waiting to get to the part when they get to do something. In many cases, they aren’t even really listening to the intro. The best preschool games are those that require no instructions or introductions and instead feature intuitive ways to play. If you do need instructions, it is possible to thread prompts throughout the game. Instead of saddling the player with a lengthy explanation at the beginning, it’s better to have a character give hints just-in-time. Consider that a preschooler’s idea of lengthy is probably shorter than your idea of lengthy. If your intro is longer than 4 or 5 sentences, or 10 seconds of speaking aloud, it’s pretty long.

Game play sessions for children under 6 tend to be pretty short, but this may be because preschoolers become bored with games published for their age group. They may sit at the computer for 20 or 30 minutes, but they often don’t spend more than five minutes with any one game. Preschool websites and CD-ROM titles usually offer several games, not one long experience like an older child’s game. To some preschoolers, clicking around and seeing what’s there is entertainment for them. That may be fine to them, but as game designers, we of course want children to be interested in the game we built for them.

To hold children’s attention and extend game play sessions, it is important to challenge them. Give them something to think about. In games, it’s usually best to dig beyond the basic ABCs and 123s. If they’re old enough to have the fine motor control necessary to use a mouse, and if they have resources that include access to a home or school that has a computer, then chances are good that they’ve already been taught the alphabet, and how to count to 10. Preschoolers may be more engaged by a game that involves working with different quantities, or an activity that develops early reading skills, like using printed words to select items. It may not be easy for a 3 or 4 year old, but it’s something they will hopefully aspire to, and try until they get it.

Just as preschoolers love to enjoy their favorite videos and books over and over again, if they like your game, they’re going to want to play it over and over again. Keeping this in mind, the ideal preschool game should provide its loyal fans familiar comforts in each play session, but at the same time avoid monotony and introduce new challenges to keep that child feeling smart and coming back for more.

Traci Lawson is an independent children’s game designer and researcher based in New York City. She maintains a blog on her Web site.

Saving Time

In this article, game designer Ryon Levitt describes the game designer's struggle between allowing constant saves while at the same time, designing a game challenging enough to keep the player's interest.

Saving the state of a game is the primary means of not losing progress. This can apply to any type of game whether it means not cleaning up a monopoly board in progress, writing down the positions of all the chess pieces on a board, keeping track of score, players, and position during a sporting event, or hitting SAVE on a video game. The main reason a game’s progress is saved is so that if an extended break is needed, players can continue where they left off without having to start over. But in video games in particular, Saving gains an additional uses; a saved state can be restored in the case of failure to allow the player to minimize the setback of defeat.

Unfortunately, saving has been a major point of contention in the video game industry. Under the Designer vs. Player methodology of Game Design, every time the player is given a chance to save before a challenge, the challenge is cheapened because the risk is “effectively removed”. Under the Entertainer methodology of Game Design, however, the job of the designer is to create an entertaining experience for the player, and having to replay the last hour over and over isn’t entertaining anymore.

These two methodologies bring forth a great argument, how often should the player be allowed to save? If the answer is never, then the player is required to beat the entire game in a single sitting. For some games, this may work; in fact, for the original Prince of Persia, it was a major gameplay mechanic – beat the game in an hour or you lose. If the answer is always, then the challenges need to be made more difficult so that even the player doesn’t get bored with trivial chance of success. Now this doesn’t mean that the challenges have to be all but impossible. For example, the original Kings Quest featured an pathway that was narrow, windy, and surrounded on both sides by sheer drops. The average player would deal with this by climbing a couple of steps and saving, then a couple more steps then save, etc. It wasn’t hard, per se, if done that way, but it wasn’t particularly fun with or without saving; it was just an exercise in patience. But, on the other hand, if the player can save at any time, then it’s not unfair to throw a big surprise at them. This works well in most simulation games where anything can go wrong at anytime, so the player can save whenever they are feeling paranoid.

Harder to balance, however, is the middle-ground. The frequency of saves defines how long the player must sit down at the game to play. It is very unlikely to find someone who knows a gamer that hasn’t at one point responded to a request with “Hold on, let me just reach the next save point!” or some variation on the theme. If saves are few and far between, then a player may have to spend many hours before they can stop playing, and if they can’t reach the save before they HAVE to stop, well then they just wasted a lot of time in trying. If the saves are too far from big challenges (possibly with numerous cut scenes en route), the time lost due to a failure can be enough to make a player not want to try again. Many older RPGs were very strict with saving rules, and many long running series show examples of this balance being updated for player ease.

But with the increase in portable gaming, the ability to take a break has become more important and, fortunately, easier to access. Both the Nintendo DS and Sony PSP have a sleep mode that saves battery consumption and keeps the game active in stasis so gameplay can stop at a moment’s notice. But there is still the threat that the battery can run out before gameplay is resumed; it is now less possible, but not impossible. SquareEnix has generally been very good about this in its portable remakes of its Final Fantasy and Dragon Quest games. All of these games now feature a “Quick Save” option (not to be confused with a PC’s one button “Quick Save” feature where saving can be done without using a menu. What makes these games’ Quick Save special is that it can be used anywhere (not just at a save point), the save is stored when the power is turned off (so if the player is worried about battery life, they can save safely), and the save data is deleted if used (or in some cases if willingly not used). By having this feature, the player can stop playing at any point without fear of lost data, but the designers can have the peace of mind that the players cannot abuse saving to bypass challenges.

Granted this doesn’t solve the issue of lost time after a failure (though the Dragon Quest games bypass the issue by making death not mean Game Over, but that seems more suitable to a different GDAM topic), though as stated above, player-friendly placement of save points can fix this – such as right before a boss fight or right after a long sequence of cut scenes. In this day and age, there is really no reason why a player shouldn’t be allowed to stop whenever they want without penalty. It’s up to the designers to make sure that the system is fair and fun for everyone who has a stake in the final product.

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.

Single-Play Sessions Podcast

In this podcast, alternate reality game designer Andrea Phillips, CEO Kimberly Unger, and Creative Director Ryan Wiancko discuss the topic of Single-Play Sessions.



To download the podcast: go here.

Games Referenced: Portal, Lego Star Wars, Far Cry 2, Solitaire, Fallout 3, Ultima 4, City of Heroes, World of Warcraft, Madden, Quake, Advanced D&D, Quake, Halo 3, Starcraft, Wallace & Gromit, Zelda Twilight Princess, You Have to Burn the Rope

Quote From Podcast:
There will always be people who say, 'I plugged the disc in, I played the entire thing non-stop, no bathroom breaks, no nothing, for fourteen hours,' but there are a lot more people gaming than those people. I think from a game designer's perspective, your worry is that you've designed the game too hard... So, I have absolutely no problem allowing people to save and then take two steps forward... because I want them to get to the end.

Andrea Phillips is a freelance alternate reality game designer and writer, and has worked on projects like the award-winning Perplex City, True Blood’s Blood Copy campaign, and Channel 4’s RoutesGame.com. She is the chairman of the IGDA ARG SIG. She writes about games and digital culture at Deus Ex Machinatio.

Kimberly Unger is currently CEO of Bushi-go, Inc. a mobile game company specializing in serialized game titles. Having started as a junior 3d artist and texture painter back in the mid 90's she has worked her way up (and occasionally diagonally) through the title of producer until finally starting her own company in 2008.

Ryan Wiancko is the creative director of SARF Studios, a start-up creating an environmentally conscious, educational virtual world for kids as well as the owner and voice of IndustryBroadcast.com. Whether it's creating the most edutaining experience possible for the next generation of gamers or bringing together the largest collection of articles from the brightest minds in the gaming industry, Ryan is thoroughly immersed in the world of game design 24 hours a day, 7 days a week.

A Case for Mods (Part II)

In Part I, Simon Ferrari, a graduate student in Digital Media at Georgia Tech, gives a short review of “OSGON,” or “one-session games of narration.” In Part II, he suggests that mods might be the way to convince publishers that advocacy games are commercially viable.

Putting aside the idea of an OSGON, I'd like to suggest another type of small-scale project that, if successful, would serve as a proof-of-concept for the public's willingness to engage seriously with an advocacy game: the mod. Mods have always enjoyed a curious existence on the fringes of mainstream gaming. One reason for this is that they are, to date, available only to PC gamers. The other is that they are only advertised on personal blogs and forums. Every once in awhile, a publisher will observe the quality and quiet success of a mod and decide to purchase the idea—the best example being Counter Strike. The makers of another mod, Killing Floor for Unreal Tournament 2004, found funding after the mod gained popular attention in gaming magazines; eventually the makers polished the mod into a standalone game and sold it on Steam this year.

Of course, you can see some problems here: the best examples of profitable mods are shooters, and as online games they demand the kind of replay addiction Reid avers. What hope does a political or educational game have in such a market? On the other hand, mods have been popular in the academic and artistic game design circles for quite a while. Mary Flanagan's [domestic] is another Unreal mod that takes players through the interior of one of her traumatic childhood memories. One day, while walking home from church, she saw smoke billowing from her home in the distance... she knew her father was inside. [domestic] allows players to move through an expressive 3D recreation of her burning home, the walls textured with prose and the ever-present FPS gun replaced by a fire extinguisher. Escape From Woomera (Source mod, I believe) was designed by an Australian art collective in order to expose the machinations of a government-run camp for illegal aliens. The press wasn't allowed inside the camp, so the game was pieced together from accounts by those who had been interred there. Finally, Medieval Unreality (Unreal mod) is an abstract trek through a nightmarish landscape designed collectively by some of the victims of the infamous Albanian blood fueds.

All of these games take less than an hour to play, and the replay value is fairly little. Also, they fall into the problem of being a bit too “serious” or “boring” for the average player (with the exception, perhaps, of Woomera). Another possibility would be to build the political mod into the existing structure of an open-ended game. Humana, the health insurance company, recently realized that it pays to keep their customers healthy rather than letting their health deteriorate to the point that supporting them becomes cost-prohibitive. Thus, they have begun inviting student interns to design health advocacy games for them. Many of these are ARG-types, but one is a mod for (you guessed it) The Sims that helps elderly men and women understand the importance of basic monitoring and medication. The mod also makes it easy for the player to understand the purposes and uses of any medical devices the insurance company or doctors may have suggested for them. Again—this is an admittedly boring example, not exactly what you'd show a publisher to pitch a larger game. But who's to say that somebody like Reid couldn't make a similar mod that simulated the lifestyle choices he had to make on learning that he had Crohn's disease? Such a mod could be used, at the very least, to prototype mechanics that would prove that it would be intriguing to have a AAA protagonist with a disability, disorder, handicap, or disease (this was, I believe, attempted in Condemned 2 with alcoholism).

One of the reasons I only have boring examples to show you is that, for the most part, these mods weren't made by working game designers. Although the lives of most designers are already strained by hours on the job, more and more professionals are leaving the big companies to start their own or work independently. In the coming years, I think we'll see more short-length mods with mainstream appeal and “serious” aspirations coming down the pipe. People are already willing to pay between $1-$8 dollars for an iPhone game... so I think the acceptance of micro-sized, niche-interest games can only be considered to be on the rise. Thanks for reading, and if I've gotten any specifics of the life of working designers and publishers incorrect here I hope you'll take the opportunity to educate me instead of flaming: I'm only a wide-eyed, naïve student filled with hope for the future, after all.

Simon Ferrari is a graduate student in Digital Media at Georgia Tech. He works closely with Ian Bogost on the Knight Foundation's News Games project. His primary research interests are political games and MMOGs.

A Case for Mods (Part I)

In Part I of this article, Simon Ferrari, a graduate student in Digital Media at Georgia Tech, gives a short review of “OSGON,” or “one-session games of narration.”

Reading Reid's article, I found myself agreeing with everything he was saying (except perhaps the knock on physicians for their love of pharmaceuticals, which I'm sure he and I can debate heatedly some other place, some other time). That said, I found it sorely lacking in one practical consideration: convincing a publisher that it would be worth their money investing in an advocacy game. Although The Sims shows that a boring game can move units, but Maxis takes a decidedly apolitical stance incongruous with the idea of making a game strictly for advocacy. I'm a fledgling academic and designer, so I don't have the industry experience to speak here with certainty; however, even in academic game design high merit is placed on the idea of the proof-of-concept. I imagine this works quite the same when pitching a game commercially—a working prototype does persuasive wonders that even a thorough design document could only dream of. I'd like to suggest a form of one-session game that would do wonders toward convincing people that advocacy games are commercially viable (at least on a small scale).

One relatively early text in the theory of political games is “Ephemeral Games” by Gonzalo Frasca, who later went on to design the first newsgames September 12th and Madrid. In the article, Frasca asks a question that has been circulating in game design blogs (especially Clint Hocking's and Manveer Heir's) recently: how does it effect the impact of a game's ethical decisions if we allow the player to take them back by loading a save? His answer was the “OSGON,” or “one-session game of narration.” The idea was to make it clear to the player that they would only be allowed to play the game once, after which their copy of it would lock them out. This, he thought, would ensure that players made decisions carefully and would forever reflect on the consequences.

Interestingly, in the past few weeks two such games were created. One by Terry Cavanagh, called Airplane Adventures, asks the player not to release their mouse. When they eventually do, their plane crashes; on reloading, players receive not another chance to play the game but a message, “YOU HAVE CRASHED.” Another game by raitendo, You Only Live Once, tells the story of a Mario-type who goes on a quest to free his girlfriend from a Bowser-type; when the player dies and tries to hit continue, they are treated to a series of humorous cartoons depicting the aftermath of their avatar's death. Neither of these games can be played again without clearing out your Flash caches. Raitendo explored the same idea with Free Will, which endlessly cycles the player's failed attempt at the game after they die (though this can be reloaded). Note that neither of these games feature ethical decisions, cues that the game cannot be replayed, or could be considered models for profitable advocacy games. To my knowledge, a politically-minded OSGON has never been created. Frasca himself opted for games that almost demand replaying.

Simon Ferrari is a graduate student in Digital Media at Georgia Tech. He works closely with Ian Bogost on the Knight Foundation's News Games project. His primary research interests are political games and MMOGs.