Things I Learned at GDC (Ozzy)

A summary of the notes I took while I was at GDC attending various seminars and round tables. Not very organized, but do enjoy.

The trek to San Francisco began around 2:30pm EDT in Sarasota. Jeremy, Shannon, and I headed north to Tampa Intl for our long flight to SFO. We met up with Jamie, chatted over dinner, stressed over a delayed flight, and somehow managed to land in San Francisco ten minutes early. A short hop to the hotel, taking in the street-lit city was delightful, and reminded me of Istanbul in the vaguest sense. At the hotel we met up with Dan, the last in our group of four, and realized that none of us had eaten in a rather long time.

As we soon learned, nothing in the Market District is open past 9pm, except for one shining beacon of Eatery. King of Thai, open until 1am. ‘Twas like until heaven to find the place, after a fair bit of searching. This would set the precedent for the gastronomical layout for the remainder of the trip, much to the chagrin of Martinez.

Our hotel was pleasant, albeit somewhat cramped. Among the lessons for next year, I learned that a bed/floor rotation plan should be set out from the beginning of the trip. We also learned the value of power strips, no matter what hotel, no matter where, four people with at least three electronic devices apiece cannot possibly be accommodated by 2 outlets.

In the morning, we endeavored to arrive at the convention center early, so as to quickly facilitate registration. By the time that had been sorted out, we decided getting down the street to Satoru Iwata’s Keynote would be the best choice, considering our expectations for it to fill up rather quickly. It did, and we were glad to have been so close to the front of the line.

Iwata-san focused a part of his speech on assuring developers that everything Nintendo released and did was to help increase the install base of the Wii, so developers would be able to his a wider market. Iwata-san was keen to point out that the majority of the industry-wide sales growth in the past three years has been primarily on the part of the explosive expansion of the Wii. His major concern was not the hardware, but the software not meeting the expectations and capabilities of the hardware.              Iwata-san pointed out that many developers put themselves into a death spiral manner of game development. First, they face financial difficulties in developing a game, and they lose time, which means quality slips, which means they enter the next game with less revenue, and so on and so forth.

Nintendo, however, develops differently. Miyamoto starts each project by finding something that people enjoy doing in the real world. Miyamoto leverages these into opportunities for a game. He analyzes this activity, and finds the core element of the fun. He never gets bogged down in writing a GDD, instead preferring to communicate with his team. By focusing on developing the core fun of a game to near perfection, through a clear and focused prototype, Miyamoto avoids surprises and redirections midway through development. The process relies heavily on trial and error, because not everything can be thought out ahead of time. Before the team considers a timeline, they must have this core concept nailed down.

Iwata helps facilitate this process by never asking for milestones, he feels that milestones force teams to cut corners to meet deliverable deadlines. He is also willing to change the timeline if, heaven forbid, the core concept of fun changes. Miyamoto makes sure he explains everything very clearly, and if someone doesn’t understand he finds another away to communicate his message. From this clear need for communication and solid prototype, the team never worries about starting over.

By valuing the work of each employee, and never completely shelving assets or ideas, Nintendo is able to keep its employees in a better mood because the employees know their work is never completely wasted.

Once the game reaches a playable stage, Miyamoto kidnaps an unsuspecting Nintendo employee. Miyamoto is handed the controller, and told to have fun. Miyamoto never asks questions, does not ask for the kidnapped to speak. He simply observes from over the person’s shoulder. Without words, he can see what is frustrating or confusing.

Iwata went on to discuss the development community as a whole. He emphasized that the game developers, first and foremost, create entertainment, and if the player isn’t having fun the developer is to blame. In order for the consumer to be surprised by our products, we must surprise ourselves. We have to know our subject matter, and go through much trial and error before we can see the light.

The growth of the industry should not only be derived from expanding the market, Iwata cautioned that we shouldn’t lose sight of our core market. Expanding the size of the install base must be tantamount to all other console manufacturer concerns. After this, Iwata and friends went on to demonstrate a few new titles, software updates to the Wii, and updates to the WiiWare and DSi Ware systems. At the end of it all Iwata gave a copy of Rhythm Heaven to everyone in attendance, and showed a trailer for the latest installment in the Zelda franchise, closing with “it is the responsibility of developers to create things the players have never seen before.”

Fault Tolerance

After this inspiring keynote, the group went its separate ways. Having played a fair amount of Far Cry 2, and being enamored with its gameplay, I attended the first of many Far Cry 2 talks. The first one was on Fault Tolerance by Clint Hocking. The talk focused on the interaction of mechanics in Far Cry 2 to allow for emergent solutions to missions.

• Players start out with the intention to have an understanding of the mechanics and the ways in which they interconnect
• Emergence is created through the robust interaction between mechanics.
• Players go through two rough phases in games:
• Composition:
• The player makes observations about the situation and formulates a plan of action
• Execution:
• The player executes the plan he formulated in the composition phase
• Hocking discussed the debate between designing for Intentionality and Strategy
• Intentionality is focused on player’s expression
• Strategy is a subset of that, which is focused on the player winning
• Hocking said that with Far Cry 2 the designers thought that an even balance between time spent in composition and execution would be optimal for the player. Hocking also pointed out what happens if time spent in each phase is altered and off-balance:
• Favoring execution is more ride-like. Hocking likened it to driving a car, most of the planning takes place relatively quickly, and most of the action is physically driving. Most shooters fall into this category.
• Favoring composition is more puzzle-like. Similar to sailing a boat, much time is spent planning the action, and possible outcomes, and the execution of the plan is relatively quickly.

Building the Airplane As You Fly: Production at Bungie

Being a bit of a Bungie fan boy, I decided to check out this talk. I was rather curious how Bungie handled its production pipeline, and looking toward leadership positions, I knew it would be important to start gleaning some knowledge in this department.

• At its core, Bungie holds to three basic principles:

1.    Focus on Quality First

• Non-negotiable polish. Bungie always allots 2 to 4 weeks per person of polish time. This time is never eaten into, a constant at the end of a production timeline. During this polish period no new content is created.
• Planning for crunch is vital to success. The scope is predefined with deliverable milestones so employees can see incremental changes in work.

2.    Focus on People First

• Take care of your people to get them to do their best work. Don’t cut open your golden goose to get a concentrated dose of product. They’ll be dead in the end and you’ll end up with goose guts.
• Producers focus on conditions in which the team can do their best work.
• Producers only offer feedback, and that feedback is never a mandate
• The team trusts each other, so they can focus on fundamentals
• Producers primary function is conflict resolution
• This helped develop the modular floor plan of their new studio, sitting different disciplines in close proximity.
• Handle cross-discipline conflicts
• Producers never sit together

3.    Be Extremely Adaptable

• Be able to readjust the schedule on the fly.
• Be able to rework, add, and cut content on the fly
• Allen Murray, the producer giving the talk defined “Bad Crunch” as:
• Prolonged, with no predefined goal
• Ends with no evidence of progress
• This is the producers fault for not planning ahead
• Murray also defined “Good Crunch” as:
• Used sparingly
• Preplanned
• A team achievement
• Only lasting 2 weeks to 1 month
• Only adding 10 hours to everyone’s schedules
• Bungie operates off a “Scrum, but” model. They take the pieces of Scrum that work for them, and cut the pieces that don’t.
• After detailing Bungie’s methodology, Murray went on to discuss Bungie’s production process, and their model for overlapping dependent pieces of process work.
• Murray emphasized the importance of feature-driven milestones, and that all creative tasks can be quantified. By being transparent and honest about the time required to complete a task, the team is able to increase accuracy and efficiency.
• Suck it up and crunch through it.
• Bungie lets the team make final decisions on cuts, and these decisions are made much earlier in the production process.
• Always track your progress against your estimates. Be wary to not use this system to scold people for not pumping out work fast enough; simply use the data to readjust your expectations.
• Culture trumps methodology, but the process must be structured.
• Bungie’s 7 Pillars:

1.    Creatively led studio

2.    Put quality and people first

3.    Be flexible

4.    Take pride in applying your methodology.

5.    Schedule is a means to an end, not an end itself

6.    Empower and enable team ownership of schedule

7.    Set dates and above all, ship on time.

Tech Artist Roundtable

This roundtable started off with a short conversation with Rob Galanakis of Bioware Austin about tech artists, Ringling, and Bioware’s need for a combination of the former two. This was my first encounter at GDC with people’s awareness of Ringling and its reputation, and the attention it engenders. I was quite flattered, and simultaneously saddened to disappoint Rob by reminding him that Jeremy and I were, in fact, sophomores.

At this roundtable I picked up on a few things, like which languages which studios are using.

• Tech Artists get technology out of the way for artists to better facilitate the creative process.
• C# opens up a wide array of possibilities for tool functionality.
• Learn fundamental concepts behind scripting, and you can map those to any language you want.
• No one has any love for MEL whatsoever.
• Never hardcode paths
• Find the critical path of the production pipeline, script tools to make that more efficient to allow for rapid iteration.
• “Blender is the thing everyone downloads and looks at for 10 minutes, then forgets about it.”

Wednesday Non-Talk Activities

Lunch on Wednesday proved my first real networking encounter. Standing around looking at Intel’s new Brain/Machine Interface system with a dumbfounded and fascinated look upon my face, I was approached by a man, we conversed, then the man’s friend joined us, and before I knew it the group had doubled in size, and I was conversing with these men. Everyone was very friendly, and excellent to hold discourse with. Through all my networking I made sure to pimp the Game Design Club blog, as well as my own.

When folk heard that Ringling had a Game Art and Design program, they asked how we handled the curriculum. I explained that instead of focusing solely on art, or solely upon design, we focused on learning design in order to inform our artwork. This drew a number of reactions in the “pleased profoundness” category, which I take to be a good thing.

After the Tech Artist roundtable, Robert and I decided to bop around the Expo floor. Walking around, I made it a point to speak with the folks developing Bot Colony. I had read the interview with company founder Eugene Jones on Gamasutra a few weeks back and was absolutely fascinated with the concept behind their game. As it so happened, Joseph was there, and he and I spoke for a short while, he offered Jeremy and I positions in the closed beta, and I got a t-shirt. Walking around the expo I was further reinforcing that GDC is for folk in the industry, and not the hoi polloi. Most of the booths featured tech or middleware for game development. I want Scaleform, the possible enhancements in immersion we could achieve with that functionality is rather enticing.

Prince of Persia: Art Direction

This was a dual talk first about the manner in which the team arrived at the art direction for the latest installment in the Prince of Persia franchise, the second about the method for achieving the art direction. The goal of the game was to be akin to a high-detail painting. From afar, it appears to be real, but when the viewer closes the distance he can see the individual brushstrokes.

The team spent a lot of time looking at and gathering stylistic reference, from architecture to art style, to character design. They wanted to buildings to feel as though they were built by craftsmen, a high level of love and detail work. Emphasis was placed upon finding the soul of the game, in order to inform everything that comes afterward in production.

• Keep your concept art on hand at all times, use it as a touchstone.
• Focus test your concept art with emphasis on its purpose
• When iterating concept art, focus on adjusting around core, iconic elements of the concept art. A character’s props, a building’s features, etc.
• Develop a world your player WANTS to explore (more on this in the Disneyland talk)
• Strong concept art can rally your team behind the project
• Make stylistic changes with tech and tools, with the help of T.A.s and 3D programmers
• The game uses an aggressive diffuse ramp to get nice, block shadows, and renders characters with their own sun and ambient lights.
• To accomplish the outline, the game re-renders the frame, this time rendering the backfaces of the models, increases the screen size, and lays that into the frame.
• Test your UI in Flash

10 Traits Great Designers Exhibit

10. Passion for Games

• Passion doesn’t mean skill at games
• This carries through in your work
• Must have a broad range of game interests
• Will hire the guy who sees games as a calling

9. Breadth and Depth of Knowledge

• What is your level of game knowledge?
• Many other kinds of games, knowledge of which you can bring to the table
• Don’t’ restrict yourself to one platform
• This expands your ideas
• What can you bring to the party OUTSIDE of games?
• Innovation is the synthesis of old knowledge
• Know a little about a low, with a few key areas of deep knowledge
• By which he means be able to hold a decent conversation on the subject

8. Problem-solving and Analytical Skills

• Do you logically deconstruct problems?
• What other patterns of problem solving do you utilize?
• Hiring Managers want to understand how you think
• How do you put your analytical skills to use?
• Don’t over analyze, or make a solution overly complex

7. Flexibility

• Constraints are frustrating, but all design is done under constraint
• And constantly-changing constraints at that!
• Don’t get hung up on one idea
• Match business and players’ constraints
• Constraints create innovation, be able to work within them

6. KISS

• Not “Keep it Simple Stupid”, this implies that keeping something simple is easy.
• Keep It Super Simple, iterate elegance. Simple, accessible, and easy to learn.
• Don’t throw more and more into your design
• Focus on the fun, know your audience
• “If some is good, more is better” is not the case.
• Suck less.

5. Player Empathy

• See the game from their player’s viewpoint
• Can you understand the player’s mental model of your came?
• How do they see the world?
• Watch players playing your game
• Don’t use friends, they’re too nice

4. Continuous Learning

• Designers are never masters of their domain
• Singing up for design is signing up to be learning for the rest of your life
• The world is ever-changing, and so is the development cycle
• The subject matters little, simply be learning
• Don’t innovate farther than your players
• CONSTRANTLY get input from the outside world
• Be conscious of what you hear in critique, it is always important.

3. Teamwork

• Everything is done in teams these days
• MUST be able to play nice with others
• Bury your ego
• People aren’t paradigms, they are people, treat them as such
• Get close to people to understand their value to the creative process
• If someone isn’t working so well, is it because they were miscast in their role in the process?
• Work toward a common goal

2. Positive Mental Attitude

• You want to be around these people
• No one wants to be around a grump
• It’s much more difficult to work when you’re angry
• Enthusiasm is infectious
• Will think about ways to do something, rather than all the ways you can’t
• Important to be practically “Can Do”

1. Clear Communication

• Design is communication
• Communicate well with the team, and the PLAYER
• Translating ideas to reality and functionality. This drives rapid iteration and implementation if your team isn’t bogged down in trying to understand you.

• When being hired as a designer, emphasize that you are committed to solving THEIR problems. Show them finished pieces, that you can take something from start to finish.
• Ideas that start on the edge will, over time, move toward the center
• MANAGE YOUR PROJECT”S SCOPE. Everyone designs a mansion and end up with an outhouse. Great designers see the outhouse, and plan for it.

Puzzles as User Interface

Randy Smith, the speaker for this session, encouraged those in attendance to seek out different kinds of puzzles to utilize in games, specifically citing Indiana Jones research-type puzzles.

• Puzzles make players feel smart.
• They involve the player in the story
• Puzzles motivate exploration
• Puzzles are novel situations
• Players are not dumb.
• The difficulty in designing puzzles is how much guidance you offer to the player
• How well does the player have to solve the puzzle?
• Use playtests and cognitive walkthroughs of the puzzle to get a better idea of how to better the puzzle’s design.
• Work backwards from the solution
• Puzzles must have a 99% success rate

Principles of Puzzle Design

• Visibility: Does the player know the stuff to solve the puzzle exists?
• Does the player know the state of the stuff?
• Make visible intangible ideas
• Visibility can be increased by motion, sound, light, particle effects, and gameplay
• Don’t make everything completely obvious, though
• Call attention to the pieces of the puzzle
• Affordances
• Every objects affords a certain action,
• Avoid affordance clutter
• Buttons afford pushing
• Be conscious of what the USER thinks an object can do
• Feedback
• Communicate when something has happened or not
• Use objects and the world to do this
• Give the player multiple layers of feedback on their actions
• This is how the game talks to the player
• Worst thing you can do is give no feedback at all
• Mapping
• Physically or conceptually connect parts of your puzzle.
• Map buttons to what is controlled
• Conceptual Models
• Be conscious of how the player thinks things work
• Get the players to have a good conceptual model of puzzle elements so they can solve the puzzle
• Puzzle structures
• Ordered series of steps, following the 7 stages of action to predict the next step the player will take
• Described what you’ve created and the solution thereof
• Work backwards along the “right track”
• A step consists of what you can do, and each element based on the conceptual model.
• When players get off the right track, design a solution around that, or find a way to keep them on the right track.
• If players are on the WRONG track, use feedback to show the player they’re on the wrong track
• Feed the player steps to constrains the players to the right track
• How do they get to that step?
• Reuse familiar steps, chunk steps
• What are the KEY steps of the puzzle
• Develop a strong up front design so you have to do less trial and error. Create information the player must know, but don’t be exhaustive.
• You’ll never be completely right in advance.
• Let a few things be NOT there and ask the player to deduce the information. This is what makes a puzzle challenging.
• Offer guidance on demand as the player interacts with the puzzle; it gives them more information, and scales to the player’s needs. Activity makes the player feel involved.

Read Me: Closing the Readability Gap in Immersive Games

As valuable as this talk was, Patrick Redding of Ubisoft Montreal spoke at breakneck speed, and I had very little time to write cohesive notes. I’ve parsed through my notes to get the below to the best of my ability to understand my rapidly-scrawled handwriting.

• Narrative problems stem from readability issues
• The problem is not with the accessibility of information, but instead with the legibility of the information being presented to the player
• A readable interface exposes the games systems for the player to grok
• Consistency of design should trump graphic fidelity
• Add informational depth to games to make a more complete representation of the game world to the player
• Representational depth has been increasing at a faster rate than the complexity of the systems it represents.
• Games cue players through the interface, and need to provide logical responses to the player’s actions.
• Players know when the game is telling them something.
• Keep the game consistent, players develop expectations of how the game operates
• Players use the information they glean from the game to build a model of the world
• Designers communicate to the player through mechanics, which, through dynamics, which are generated by aesthetics.
• Changing one simple factor has dire consequences for the rest of the game’s systems
• Games are a place people can explore the world through dynamics
• Designers should be able to program
• Core Activities -> Identify what the player can do
• Player verbs -> set of verbs, actions the player can do to interact with the world
• Inputs -> Controls, range of meaningful input, parameters that affect gameplay
• Choices supported by level design, gameplay,
• Visibility -> Can the player look at all the info they have affected
• Be subtle about the information you put into the game world
• Don’t add aesthetic content that doesn’t add to readability, this is just noise.

Everything I Learned About Level Design, I Learned from Disneyland

Inarguably the most valuable talk of the conference, especially in the context of our current assignment. Scott Rogers, Creative Manager at THQ, presented lessons in level design from Disneyland.

Questions to ask when starting design:

• What is the level about? What is the story that takes place within the level?
• What is the moral arc of the level?
• What do you want the player to learn?

• Design down from the game, to the world, to the level, to the experience
• Work your interests into the world the player experiences
• Disney was always interested in urban planning, how do you move people from one place to another through their own volition.
• Disney operates on the “Weenie” system
  • Points of interest that draw your player’s attention
  • Navigational reference points, let the player contemplate his options
  • Gives player choice between long and short term goals
  • “Kodak Picture Spots” – A place for players to stop and go “that’s really freaking cool”
  • Let the player marvel in the grandeur; catch their breath before continuing on.
• Your first weenie should act as the hub of the world, a symbol of your level
  • From here you present the player with a choice of which way to go
• Draw the player toward the goal geographically and visually, leading lines and whatnot
• Altitude changes can enhance the drama and scale of a Kodak moment
• Back tracking lets players find another path to the weenie, and explore areas they may have missed on the last run-through.
• Use light to draw players’ eyes to areas of interest.
  • Enhance weenies with lighting
  • Absence of light has a powerful effect on moving players OUT of an area
  • Use squint tests, the main path should be the brightest
• Treat locations as activities, not just destinations. What is the player doing at each location?
• Foreshadow dangers the player has to deal with
• Get the player excited about options, so they plan ahead
• Preview the rest of it and show the relationship of levels
• Diversify each of your levels and areas, make each one unique and distinct so players know where they are in the world
• Give the player major arteries along which they will movie, with some minor arteries sprinkled throughout. The player feels smart because the discovered these paths, and new possibilities for exploration
• On each side path, offer a reward at the finish, and hint toward another side path further along in the area
• Add surprise and fun moments for the sake of having surprising and fun moments
• Each level should have a thematic goal:
  • Escape and Survive – the player is put into peril and must get out
  • Exploration – The player traverses the world at this own pace
  • Education – Teach the players something along the way
  • Moral Lesson – Teach the player the result of an action
• Not every attraction has to be a major thing, sometimes players just want pleasant distractions
• Provide frequent checkpoints for your players to make use of
• Use the player’s expectations of the level as a spring board for your design
• Make mundane objects even just a little interactive
• Generic objects should fit thematically within the level, even If it’s just a new paint job
• Players like the feeling of overcoming long odds
• Warnings and implied threats add to the player’s sense of danger, don’t let it lose its impact
• Surprise is much more effective if the player is anticipating the surprise
• Use text, images, sound, and puzzles
• Let the player discover the story, don’t just tell them, you can use puzzles as a way to tell the story
• Let the player see the goal, but don’t let them get there just yet.
• Spatial contrast adds to the effect of each section.
• Story guides the design of the environment
• Maximize emotion through safety and unaffecting danger
• Nobody reads the manual

Stretching Beyond Entertainment: Role of Games in Personal and Social Change

A panel of Will Wright, Peter Molyneux, Bing Gordon, Ed Fries, and Lorne Lanning discuss the social and personal impact of games on society, and the responsibility game developers have to society at large. I was just excited to be in the same room as Will Wright and Peter Molyneux.

• Games are not just trivial entertainment
• Games DO have a responsibility to the player
• Games must, to be successful, entertain the player
• We should be able to create games with an intentionally designed positive impact on the player
• If you give players the freedom to interpret the message, they will
• Entertain, don’t preach
• Bait and switch the players, show them what they want, and switch it out for something meaningful. Blindside the player with profoundness.
• Take. Risks.
• Different generations see the world through different lenses
• People enjoy interesting failure, populate the failure space with different options
• Put the stories in the hands of the player, give them ownership.
• Users don’t feel guilt in books or movies; this is the advantage of our medium.
• How can we design a game that makes players feel bad about their actions, while incentivizing the bad actions?
• Show the consequences of violence, pain, jail, etc. Push realism beyond simple graphic fidelity
• More and more titles are developing around cooperative player, linking people all around the world, and those people bring their cultural distinctiveness to the game.
• Bing Gordon says that “Should” must be removed from the dictionary
• Kids learn stuff best through games. MMOs teach leadership and fiscal responsibility
• Use games, not textbooks, Games
• Games are a renegade medium; this is what plays into our popularity. How do we do all this without losing our renegade status?
• Embed meaning through gameplay
• Incentivize certain activities
• The nothing that it must be profitable to be successful is ass backwards.
• Lorne Lanning proposes a console-based education system
• The United States Government doesn’t invest a single dime in game development
• Start small, and use your audience to shape your game
• Is there some way we can mix old and young folk, and glorify their uniqueness
• Don’t just distill war to fun
• The best game designers have the best bookshelves
• Use incentives and disincentives for player actions
• Make games more accessible to the nay sayers
• Have children sit down with their parents to discuss what their thought process is while playing games.

Vast Narratives and Open Worlds: The Big Huge Problem

In this talk, Ken Rolston and Mark Nelson gave a premortem of their latest game at Big Huge. Previously, Rolston and Nelson had been the guiding designers on Morrowind and Oblivion. They’re great at designing RPGs. They also worked on these RPGs at Bethesda, who knew RPGs. Now they’re developing at Big Huge, who has done RTSes to exclusion. One of the first things they realized is that you need to have a team that knows what they’re doing. Through the talk, the two Internationally Renowned Designers talked about what HAS gone wrong, what they’re doing to fix it, and what lessons other studios can learn from their mistakes.

• Know your scope
• Vast narratives are like biogas role-playing games
• Seed your world with plot hooks to keep your player interested
• Story and character are what make people stay in the game
• Designers must have a strong willingness to synthesize new ideas from old
• Making a next-gen RPG world is HAARD
• Manage your blunders, don’t out think yourself, move between complacent and overwhelmed, a lot of blunders are really smart people doing really stupid things
• Scope management is a constant challenge; people expect more than can be reasonably provided from developers.
• Shifting focus and changing ambitions is part of the design process
• When you lose focus, go back to your vision statement, which must be well defined, and well communicated with your team
• Find the fun through iteration, while being mindful of your focus
• Be honest with your team, argue constantly
• Tell your team what you’re thinking
• Everyone on the team must keep everyone else updated, you can do this through blogs, wikis
• Know the core objectives of the project
• Overdesign a small set of things, as Rolston says, “Design 400% of your game, cut 350% of it, and at the end of the day you’ll have 100% of a game”
• Collect and study anecdotes of failure
• Refuse to do too much
• Vast scope leads to information blackouts, which is never good
• Play to the strength of your team
• You don’t really know something if you can’t explain it to a 10 year old
• Be brutal and energetic in educating the innocents
• Give people domain over a certain aspect of the game, from concept to completion, makes people experts in the entire pipeline
• Everyone person must be mentored differently
• CROSS DISCIPLINE SEATING IS A NECESSITY
• Shorten the time between reviews, give constant feedback so your team can grow quickly
• Constantly monitor individuals on a project
• Promote learning readiness
• Content must be vast, modular, and extensible
• Balance planning with improvisation
• Stop making art, start making fun, fun is the ultimate responsibility of designers
• Dialogue in games is atrocious, and vitally necessary
• Don’t write the narrative before the systems have been nailed down, otherwise you won’t know the constraints on your narrative. Quests are informed by the systems, and quests are just opportunities for writing gameplay
• Faction design can be a vital component of a game. These provide many hooks, and excellent possibilities for relationships.
• Three factions is more interesting than two, the conflict is no longer binary
• Do the easy stuff first, then get everything down to a polish and shine
• If you have a predefined character in an RPG, you’ve lost the point
• Systems support the narrative, and narrative uses the systems
• Make a decision, any decision is better than no decision
• Grant domain ownership in areas your team members are likely to succeed
• Use the main quest to give a tour of your game and its systems. This leads the player to find interesting side missions.
• Players feel their choice is ignoring the main quest
• Ending the main quest kills the character, it’s over, there’s no further purpose to the game
• There’s no way to finesse preventing your player’s choices in the world.
• Focus on combat, story, arbitrary collection, personalization, and player choices

Tech Artists: Tools and Techniques

This talk was a more focused panel on the different pipelines at specific studios. Sadly it was a two hour talk, and I had more interesting design talks to which I was beholden to attend. I was still able to glean some useful tidbits.

• When planning a content tool, analyze the wants and needs, and compare that to what is feasible in the time allotted.
• If artists aren’t being creative because of technical issues, there’s a problem worth solving
• Grow tools organically, improvise, but keep everything not so cluttered. Constantly add functionality, with an original plan for basic features
• If you don’t test your tool, you’re doing it wrong, although this lengthens the iteration time
• Find ways to build an error database, artists get scared by blocks of text and don’t want to deal with that.
• If possible, the DCC App and the Engine should have the same control scheme, so as to not confuse EVERYONE WHO USES IT
• Reuse code, it makes you more efficient
• Learn concepts of object-oriented programming
• Tech artists were initially force multipliers for artists, and they’re now transitioning into force multipliers for tech artists as well
• It’s cool for artists to be able to do basic scripting, but they shouldn’t lose the focus of their job

Player’s Expression: Level Design in Far Cry 2

Last talk of the conference, this was also the last in a number of talks focusing on lessons that can be learned from Far Cry 2. In the first session, Fault Tolerance, I asked how the level design of Far Cry 2 supported the player’s improvisation, and I was deferred to this talk. Far Cry 2 teaches so many lessons, and shows what can be possible with that type of game; the many lessons of the game had to be broken up into multiple talks. In his talk Jonathan Morin, the Lead Game Designer at Ubisoft Montreal asks: Are we respecting the player?

• Do we, as designers, think about who is using our games?
• Everything we do as humans is learning a language and a manner in which we can express ourselves. Games are no exception.
• Humans are what we repeatedly do, our habits
• Exploration leads to discovery, which leads to interpretation, which has an influence on our exploration
• Our emotional habits prevent us from cultivating our character
• Emotional buildup based on mistakes from the understanding of the game helps us understand our anger
• How do we control players? Let them fight their habits
• Far Cry 2 dealt heavily with microdecisions from the player, the buildup of which created a unique experience for the player, much like jazz music
• The game had three core aspects, Cause and effect loops, micro-decision buildup, and world exploration, which all blended to create the game
• Each of these systems was expressed with, risk, imperfect information, and environmental impedance; player condition and needs; and missions and side quests respectively.
• Player has plans, and the game fraks them all to heck. Each step of their plan has elements of uncertainty
• Know the way your players will want to play your game:
  • Planning & Approach: The Strategist. Heavily invests in reconnaissance and planning before executing a plan
  • Combat: Rambo. Their goal is to shoot shit, and spend precious little time in the planning phase
  • Escape and Evasion: Actively avoids confrontation, utilizes hit and run tactics, and can be interesting to try and support this space.
• Level designers don’t control the player’s decisions, the player controls the pacing
• Cover density plays a huge role in supporting the player’s microdecisions
• Designers mapped out how each play style would react in each cover density, against enemies in each cover density
• This made it easy to predict from which position each player will make which move, and make sure as many decisions are possible in that space
• All the play styles loop together, no one is completely one, all players must make use of each aspect to some degree
• In an emotional and tense game, your player will want the option to breathe. They will want to do this of their own accord, as designers we never know perfectly when the player will want to change their own pacing
• Hint to possible locations for the player to explore in high tension areas, give them something to look forward to.
• Planning and Approach, Combat, and Escape & Evasion all blend together to create the experience. It’s more of a network than a loop

Final Notes about GDC

• Nobody is hiring sophomores as interns. Spend most of your time just MEETING people.
• Everyone there is really friendly, and very willing to converse.
• Don’t be an arrogant prick, don’t misrepresent yourself. Know your place in their world.
• Business Cards should have your name, what you’re currently doing (title, organization), and contact information. Favor a readable business card over a flashy one. Have them printed on quality paper.
• Bring a portfolio; you never know when you can get someone to look it over.
• The Ringling name has a lot of pull in this world; they respect the institution, and the quality Graduates it produces. Continue that excellence.
• Wear. Comfy. Shoes.
• Try to get your swag earlier, rather than later. You’ll get a wider variety of t-shirts and GDC branded Stuff.

In the end, the conference was definitely worth the cost. I look forward to going the full week next year, spending time in tutorials and whatnot. I’d also like to spend more time networking, which I feel is something I can always improve upon. Jeremy and I soon realized that playing a card game with a d20 really attracts people’s attention, which I want to leverage into networking opportunities next year. I think my biggest disappointment of the conference was that I didn’t spend enough time networking in the morning; I did all my networking in talks. In 2010 I’ll definitely look forward to spending a little more time exploring the expo floor, there’s some really interesting and exciting stuff going on there that I just did not have the time to explore because I spent the entire conference in sessions.