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!