GDC Report – Friday

Friday

15 Games in 15 Years

This was a different sort of game design lecture. The speaker has a tradition of designing one game a year for his two kids, and these games never see any kind of commercial release. I won’t go into all 15 games, but here are some takeaways.

Understand your design goals when creating a game. Not every game needs to have a “simple to learn, hard to master, engaging and hours of entertainment” kind of goal. Some can be explicitly designed for purposes of “distract a 3-year old,” “teach the alphabet,” or even “give me an excuse to buy this awesome monster statue.” Be honest about your goals!

The pieces matter. Everyone says “just give me gameplay, I don’t care about pieces or graphics!” They lie. Stuff is fun, it captures the attention and the imagination. Cool pieces can’t make a terrible game great, but they can make a decent game great.

Likewise, story matters! A splash of narrative can make it easier to understand the gameplay specifics, and makes the whole game more engaging. People want to know what they’re accomplishing by playing the game!

Give your pieces personality, too. Just giving a piece a name and a catch phrase can help the player understand its personality, and also its game function. (You tied the game function into the personality, right?)

Cannibalize other toys and games to make your own. Plenty of games give you a cheap source of square tiles (Scrabble, Carcassonne), ships and tokens (Twilight Imperium) or figures (Heroscape). Steal them!

We’ve heard it before, and here it is again: iterate! Make a prototype, then improve on it! Especially when you’re making personal, non-commercial games, you can iterate for months and years on an idea. Keep tweaking!

If you have a mechanic you’re not sure about, put it on a character. Then, players can choose whether they want to use that mechanic or not. He gave an example of a ‘Witch’ piece which could start a 30 second timer, causing the current player to lose their turn. The Witch was created to combat a friend of his with analysis paralysis, who took forever to make a move. When that friend comes by, the Witch comes out; otherwise, she might not be chosen.

Use Excel to track complex games. When you’ve got a lot of numbers, you want to see them all in one place and neatly organized.

Having no randomness to a game makes it slow. No matter what designs he tried, the result was always the same: no randomness = slow and analytical.

Balancing is easier if the game automatically balances itself. An example is Puerto Rico; any role that doesn’t get chosen gets a bonus token on it each round. Hypothetically, the designers could create a terrible role, even one harmful to the player, and it would eventually get chosen due to the accumulation of bonus tokens.

3D printing is exciting! Who knows what new games we could make?

Personal games are a unique experience. They’re a direct reflection of you, and the only people you have to impress are the ones closest to you. Think long-term, no deadline, no stress, just enjoy the act of making a game.

The Story of Cave Story

This panel was pretty good, but nothing really surprising. Pixel worked hard, put a lot of his own creativity into his game, and got a great result.

The most interesting fact was that the game was nearly done – Pixel had done two years of work – then he completely scrapped it and started over because it just wasn’t working right.

Audio data is massive, but composing in MIDI has its own limitations. I think I heard him say that his process was to record a sound or music on a microphone, then look at the waveform and try to get close to recreating it with MIDI notes. Hopefully getting the variety of real sounds and the size-savings of MIDI.

Pixel identified five elements of a game:

• Visuals
• Interactivity
• SFX
• BGM
• Story

Early stages should be simple and linear, then you can expand the complexity of the game once the player understands it.

Boss battles should try to outguess the player – make it seem like the boss is anticipating their movements.

Sound effects are useful. They’re cheap and easy to implement, and create a very responsive scene. You don’t need to animate something if you can use a sound effect to convey it instead. (Good example: you approach a door. The screen fades out, you hear the creak of a door opening, then the screen fades in on the next room.)

Music changes the impact of the visuals without needing to tweak the visuals at all. Cave Story has an example of this: early on you visit a village, with soft, welcoming music. Later on, after a tragedy, you return to the village, and empty, ominous music plays. Same visuals, but perfectly conveys the changing mood of the story.

Pixel talked about why the main character has amnesia – it helps the player be the main character, and creates a connection. I agree, but considering all the game characters who have amnesia at the start of their adventure, I think it’s time we buy our heroes some helmets.

Players don’t like long and forced tutorials. Design starting levels that encourage exploration and trying things out, and let the player feel like their cleverness helped them overcome the problem themselves.

Charles Black

No, Charles wasn’t a panel, but he’s a friend of mine from college. We caught up for a while, had lunch together, then went down to the Expo Floor.

Speaking of which, the expo floor was decent, but nothing really amazing. Conventions don’t really wow me anymore. If you want a full report of the expo floor, I’ll just say that there were a lot of companies there showing off a lot of shiny tech. There were also a lot of indie developers, a lot of people selling monetization plans for Facebook, and a few slot machine companies in attendance.

While we were wandering the expo floor, Charles and I got to talking about programming. I’ve been doing some basic Unity work, but I’m still baffled by programming – how to start a program, how to know what code to write, what all the different aspects of programming are. More specifically, I’ve always been confused by middleware – like, when I buy a license for Havok physics, what exactly am I buying? How do I use that? They keep saying I can just plug it into my games, but I looked at my computer and it didn’t have a Havok plug socket.

Charles was totally patient, and helped me grasp a lot of concepts. Like, I generally had an idea of what a language is, but he helped me understand why a language is. Same with classes, libraries, engines, APIs, and variables. It helped me get a lot more confidence that awesome coding is something that I could eventually learn how to do.

Classic Game Postmortem: Raid on Bungeling Bay

I only caught the first half of Will Wright’s look back at Bungeling Bay, but there were some interesting elements. It really called back to the idea of game design by accidents, and playing to your own personality. Will wanted to do a big game, and he wanted to do something with helicopters. He worked out some interesting tricks with his computer, and actually making it into a game came later.

Bungeling Bay is also notable for giving birth to SimCity, as Wright realized that he was often having more fun making islands and building cities than playing the game.

It was also interesting to learn about the depth of the game’s subsystems – that resources appear in the ocean, and boats pick them up, then tanks take them to factories, then the factories repair things you’ve damaged in a certain order. The world has a pretty involved economic system, but the player doesn’t need to know anything about it to enjoy the game.

From Student to Start-Up: Case Studies

I wanted to catch the last panel of the Game Career Seminar. It was pretty much what I expected: a lot of people looking for that golden nugget of advice on how to break in, and the presenters pretty much reiterating “Work hard, get your foot in the door, make stuff.” Cliff Bleszinski pretty much said it directly – “You’re all thinking that there’s just this one thing, one secret where if you can figure it out, your whole future will make sense. I just don’t have that answer, and I wish I did.”

The End!

And with that, it was the end of my GDC adventure, time to put away my badge and head home. It was definitely worth it – I made a lot of contacts, and drew a lot of inspiration. Coming out of the conference, thought, the weight of the work I need to do still hit me pretty heavily. Inspiration, research, and making mental connections are all incredibly important, but I really need to just get off my duff and start making something!

Well, I’ve taken a few steps in that direction. The first step has been to move my computer upstairs so I can have a standing desk. (I recommend it.) The other steps, well, they’ll be in the next few posts.

GDC Report – Thursday

Encouraging Cooperative Behavior in Co-Op Gameplay

There’s a difference between having two players in a game space, and having truly cooperative gameplay. The Splinter Cell series has become well-known for the latter; missions that really reward cooperation between two agents.

Players respond to collective agency. When they feel like they’re both making an impact on the situation, they want to hold up their end of the bargain.

Players will work together to optimize their output. This can be a challenge, because two agents can interact with a system in unpredictable ways, and really be more effective than one player. Or, they can screw up.

Twice as many players = way more that twice the chance of detection. Creating meaningful stealth opportunities when you need to conceal two agents is much harder than concealing one. But, players can use their knowledge of the game to improve their odds, making it an interesting challenge.

Allow players to express themselves through gameplay. Let them develop their strategies, make plans, and take risks. Make both players feel smart and effective.

Players dislike forced cooperation, but enjoy meaningful cooperation.

Cooperative dynamics are how the mechanics influence the player’s inputs, and the outputs they receive.

Many mechanics were introduced.

• Gating/tethering: The most basic mechanic. No player can proceed unless all players are present. It’s usually pretty obvious.
• Exotic challenges: One player has a unique perspective/controls, and other players need to cover them. An example is manning the minigun in Left 4 Dead: you’re more powerful, but you can only aim in a 180 degree arc, and you can’t melee to defend yourself.
• Punitive systems: One player is trapped, and requires rescue/help from another player. Too much of this can feel like punishing the player just for trying to play the game their own way, but it can also create cool situations where players can keep the team alive even after a normal failure condition. These systems can be a little weak at creating coop play, because they’re avoidable by skilled play. Don’t let a smoker get you, and you never need to do the smoker rescue mechanics.
• Buffing systems: One player makes another more powerful, usually sacrificing their own effectiveness to do it. This can create cool coop gameplay, but you can’t rely on it too much, because players can always choose to just ignore it and fight on their own.
• Asymmetric abilities: Each character has special abilities and/or weaknesses, and you work better as a team. MMORPGs are a good example of this.
• Combined Actions: A situation requires different player skills at once. This is different from character skills; you’re not limited by your character, but you need to specialize briefly. The classic example is the Warthog: one player driving, one player shooting.
• Survival/Attrition: The game continues as long as one player is alive. Death is permanent (at least until the next checkpoint), so defending each other to ensure that at least one person get through is a victory.

Overall, high-level plot isn’t as important as character events. Players don’t talk about how they stole data and transferred it to the U.S., but they do talk about how they totally elbowed that guy just in time for you to get a clear shot on them and it was awesome.

Don’t put a lot of effort into prescriptive systems, like needing to hoist a friend over a wall. Players understand these things. They know you need these coop points. Trying to mask these points as natural parts of the gameplay will just result in players getting confused about what they need to do.

Give players the tools they need to support each other, and be reliant on each other.

Focus on readability in your gameplay mechanics, path, stealth, etc. Two players in the environment creates lots of sensory, system, and social noise. Make it all easy to read.

Trust that groups of players will naturally find improvise their own solutions to hard problems.

Biofeedback in Gameplay

Valve did a cool panel on using biofeedback systems to gather data and/or control gameplay. Biofeedback means stuff like heart rate tracking, eye movements, and such. It should be the most natural form of input – you don’t need to think or do anything, you just need to be human and get into the game!

Exposing biofeedback data to players can create a feedback loop. They get nervous, and they see that they’re getting nervous, which makes them more nervous…etc.

Controls map player intent to the game.
Biofeedback maps player emotion to the game.

You get to factor in not just what the player is explicitly telling you, but also what they’re feeling about the game.

Emotion is a response to external events. It has a vector, with an intensity, and a direction (positive/negative emotion).

The biofeedback methods presented were:

• Heart rate: Cheap, easy to measure, but prone to errors due to movement, and delayed. It takes several seconds for your heart rate to change due to stimuli.
• Skin Conductance (SCL): Very cheap to measure, and short lag time, but the range differs between subjects, requiring evaluation and calibration.
• Facial Expressions: Great for getting an exact emotional response, and expression is usually instantaneous in response to stimulus. But measuring expressions generally can’t be done in real-time, is intrusive and expensive to record, and requires training to interpret.
• Eye Movements: Very good measure of exactly what the player is paying attention to, and for how long. It tracks player thought processes fairly well. However, it requires very expensive gear to track, and gaining data from eye movements requires later review and evaluation.
• EEGs: Measure the electrical potentials of the brain. You can get a good measure of arousal, and a general idea of what kind of thought the player is doing. But EEG setups are very expensive, very intrusive (a big metal thing on your head), and it’s difficult to really get clear data out of all the signals.

Valve showed three demos:

1) Left 4 Dead 2, with the director’s estimated tension level replaced with an actual, measured tension level from the player. Valve’s data showed that players had more fun, as the game reacted more naturally to them.

2) Alien Swarm. A stage was created where players would kill 100 enemies in 240 seconds. However, if they got nervous or agitated, the clock started ticking faster. They definitely saw a feedback loop – get nervous, the clock speeds up, which makes you more nervous.

3) Portal, with eye tracking to control the crosshairs. I was impressed by this one – the player’s gaze flicked rapidly from surface to surface, firing portals with pinpoint precision. This has the potential for perfect control in shooters, instantaneous reactions and perfect headshots. But is that desirable? It takes time to raise a gun, sight it, and fire. On the other hand, it seems wrong somehow to suggest that what we want is less accurate, less responsive controls than are possible.

Valve knows that biofeedback isn’t coming to the consumer level any time soon, but their research still served an important role. Is there an optimal arousal pattern, which leads to an optimal gameplay experience? Can we use biofeedback to make good gameplay become great?

Rise of the Power Creative  – Cliff Bleszinski

Cliff’s talk on the power creative has been covered pretty well in other locations.To give a quick summary:

“Power Creatives,” like Peter Jackson and John Romero, are rare. They get to call the shots, they have diverse skills, and they bring value to any project.

How can you get there?

Know your weaknesses, and bring in partners to fill the gaps.

Delegate. Learn what you can do, and what you can’t.

Make it personal. Make games for you, about your experiences.

Design is sales. An idea has to sell. Not just money – you have to be able to sell it to your peers, too, so they’ll be excited about developing it.

Understand PR and marketing. You have to be public, brand yourself, and capture attention.

You’ll catch a lot of criticism, too. Take it and make it your own. Be distinctive.

You’re the frontman for your company’s band. Take that role and be distinctive.

Stay in touch with marketing, and keep control. You know your game’s image; don’t let them present the wrong one.

Understand your audience. Keep up with where videogames are going, and who’s playing them.

What’s in the future?

Games that reward multitasking. Devices that talk to each other. Carry a part of the game with you.

Reward often, and in the long-term. Create a visible calendar that keeps players anticipating the next piece of news or content.

In the future, AAA isn’t going to die, but it’ll be challenged by social games. Create long-term games, experiences that your players want to marry, not just date as a short fling.

Steam will help – more digital downloads, more instant gratification.

Tap in to the feed. This means Twitter feeds from characters, viral videos, and deeply buried Easter eggs. Get people talking! Get that free press coverage!

A power creative builds IP. Think about your game and your brand:

• Can you give a one-sentence pitch? Tweet it – 140 characters or less?
• What tattoos would people get from your game?
• What quotes will people use?
• What memes will you start?

The best ideas have cool gameplay, reinforce the game’s fiction, and show off your unique art/technology.

A Power Creative understands the business – or else the people who understand money will be happy to take yours!

Innovate! Never fall back on “Traditionally in this genre…”

Keep your IP sacred, it’s your most valuable asset. Parents introduce your IP to their kids. Fans write stories and make fan movies about your IP. Protect it, keep it, own it.

It’s risky to stick your neck out. Eh, whatever. Just do it!

Design in Detail: Tuning the Muzzle Velocity of the Assault Rifle on Legendary Difficulty across the Halo Franchise

I enjoyed this session a lot. Instead of vague design principles, it was about one single decision in the Halo games, how they came to that decision, and how the answer changed throughout different games.

Jaime Griesemer had done a lecture last year which was about balance, but this one was all about tuning. The difference is that balance is about longevity, keeping the game playable forever, making it fair, and making multiplayer work better. It has nothing to do with fun.

Tuning, on the other hand, is all about fun, making an experience feel good and immediate. It has nothing to do with making something fair or balanced.

Before we can come up with ideas for the speed of the assault rifle shots, we need to understand the context of our decision. The assault rifle is the most common enemy weapon, which means that it’s the most common shot that will be coming at the player. It also means that the player will scavenge lots of assault rifles, so they’ll be firing this gun often, too.  The speed of this projectile really defines the feel of combat across the entire Halo series.

Fun actions have three things in common: they’re reactive (the player starts them), they’re repeatable (they’re not one-shot events or complicated to pull off), and they’re reliable (you get a nice impact and a cool result from this action every time).

To start, guess at what the extremes might be, then start narrowing in on the right value. They started with muzzle velocities from 1 to 20 unit/sec, and then tested and repeated until it felt right.

Jaime said that making the game harder just by turning up damage/turning down health is a mistake. Increased damage doesn’t make the game harder, it just punishes failure more. The shots are coming in at the same speed, it’s just that a mistake is lethal instead of just inconvenient. Making a game actually harder involves increasing the speed of the action, increasing enemies, increasing AI, and requiring better skills.

When tuning, avoid habituation – it’s easy to get on the wrong track, and start micro-tuning something that was the wrong idea to begin with. Take breaks from a project, then come back and see if the idea still feels fun. Try intentionally breaking things – set the values to a number that you know is completely wrong, then see how it behaves. Maybe you’ll realize that there’s another approach you should be taking.

GDC Report – Wednesday

Wednesday

Keynote – Satoru Iwata & Reggie Fils-Amie, Nintendo

The keynote was decent, but not exactly mind-blowing. Iwata’s sections were pretty much “I’ve been doing games for a while.”

Reggie’s sections were pretty much shills for the 3DS. Basically lecturing on how the 3DS was going to revolutionize gaming forever. I’ll post my thoughts on the 3DS later, but it was a pretty short-sighted keynote, considering that the majority of your audience of game developers has played games on and developed for mobile devices and web browsers.

Overall, it wasn’t really inspiring. I feel like a keynote should raise awareness, bring up issues – be something that people are talking about for the rest of the conference. In that sense, it makes the conference run smoothly, by giving the attendees common ground for conversations. This keynote wasn’t really thought-provoking…more of a press conference, really.

Game Works of Yu Suzuki

I left this one. In retrospect, I didn’t realize that they had translation earpieces available, but I was picking up enough Japanese to realize that it was a pretty boring, Japanese-style interview. As in,

“Is it true that Space Harrier originally had a plane, but then you put a person in?”

“Yes, we did a test with a plane, and it did better when we put a person in.”

“Ah, I see.”

Not exactly hard-hitting journalism. Some podcasts I’ve listened to said it was a great panel, but I don’t regret leaving, because it let me catch the panel on Dynamics, which I heard people talking about for the rest of the con.

I missed the beginning, but here are the notes I caught.

You want to choose how your story is told. It can be strict, forcing the player into a specific experience, or loose, allowing the player to be creative and find their own experience. Either method can work, but it definitely changes the theme of the game.

Changing the fiction of the game can change the meaning and dynamics, even if the mechanics don’t change. Clint gave the example of making Tetris about shuttling trains off to a concentration camp. When completing lines means killing innocent people, does it change the meaning of the game? Does it change your playstyle?

Meaning is:

Synthesis: A combination of players’ views. Meaning comes from multiple impressions across the course of the game.

Rigorous: The stronger the concern about the outcome, the more meaning.

Instantial: You can’t talk about the meaning of a game, but you can talk about the meaning of an instance of the game. That is to say, I can’t exactly say “Mass Effect 2 means this” but I can say “my playthrough of Mass Effect 2 meant this to me.”

…you know, I don’t really like my writeup of this panel. I think there was a lot of terminology I didn’t completely grasp, and I’m probably using wrong.

GDC Microtalks

One hour, ten speakers, about five minutes each. How did it go?

Richard Lemarchand

Introduced the panel. I should read Kill Screen, and play Sleep is Death and In a Star-Filled Sky. (The advertising is working!)

Michael John

Is the father of computer games computers, or games? Michael argues it’s computers. Computers have given us an expression of games that games could not have created alone.

All games are played, not all play is games.

Kids should code. All kids should try making computer games. He recommends Scratch to start.

Jamin Warren

We need a language around gaming. A lexicon.

We have experiences in games, but if we don’t share them, they disappear. Don’t keep your experiences to yourself. Share them.

Naomi Clark

The Fantasy of Labor: Keep playing, keep buying, keep grinding. It will pay off. Is this true? Have games led us astray?

David Jaffe

Getting into a console game takes too damn long. We’re not talking about the tutorial; we’re talking about system boot, logo, select the game, load, logo, logo, logo, press start, loading, accept legal agreement, loading, go. When I put a disc in that I’ve already played, just skip all that and start right from my most recent save.

This is why people are going to the DS and iPhone for gaming; you can get gaming and have a meaningful experience in 20-30 seconds.

Colleen Macklin

Playtest.

Look at Farmville and Minecraft, games which are in a state of perpetual playtesting.

More playtesting = better games.

Asi Burak

Text adventures were great. We had more direct control, more freedom, and less cutscenes.

What happened? When did we decide that we wanted to emulate movies?

Can we change the direction games are headed?

Jason Rohrer

My notes aren’t great for this one.

Jason condemned thoughtful, artsy games for being boring. He looked to other modern games that can keep you focused for 8 hours at a time.

He noted games where there’s survival value in staying focused – where paying attention helps you succeed.

Brandon Boyer

Games help us explore our dreamscapes. We should remind people why they used to play, and how they could get lost in their own imagination.

Brenda Brathwaite

Everything can be a game. If you can play it, it will become a game.

Pro Guitar in Rock Band 3

When making design decisions, always go back to the One Question about your game.

For Guitar Hero, this was “Is this Rock?”

For Rock Band, this was “Is this an authentic band experience?”

They narrowed down their scope by choosing a definite target: Hard/Expert Rock Band players with no previous guitar experience. They wanted to teach these players the ‘campfire versions’ of their favorite songs, and let them graduate to the real versions at their own pace.

They spent 3 months on early concepts, 7 months prototyping, and 13 months in production.

Concepts: They had to narrow down a massive space of possibilities to a few possible ideas. What information did they want to convey first? How realistic would it be? What compromises were they willing to make?

Prototyping: Harmonix used a small strike team to prototype. The designers are also the implementers; if you have an idea, you have to figure out how to make it real.

They didn’t worry about hardware. They figured they’d make the feature, then figure out how to create the hardware they needed later.

They essentially created a new way of noting music; it’s not tabs, musical notation, or chord charts. Pretty impressive!

They found an issue when they tested; people said it was interesting, engaging, immersive, but not fun. They thought about it, but realized that for Rock Band, fun was what they needed to be testing for.

Suggestions from the prototyping phase:

• Reduce your team size.
• If an idea keeps coming up, even if it sounds stupid, you need to try it! It’s stuck in everyone’s head for a reason.
• Don’t skimp on the low-hanging fruit. It’s tempting to say “we’re short on time, and we know how we’ll do X. We’ll do it later.” But putting those easy features in place can give you more insight into how the hard features can work.

– You can’t make a good design decision just by debating it. Make prototypes!

Production: This took much longer than expected. Their team expanded, and they became more reliant on external resources. The actual Pro Guitars were slow to be manufactured, and the final RB3 song list was finalized fairly late.

To get back on track:

• Refocus on your target market. Pro Guitar is for new guitar players. Prioritize your features based on that market.
• Switch to short-term deadlines. Keep people focused on iterating in the short-term, and quickly.
• Use placeholder content for rapid development. Jury-rig whatever you need to get your ideas tested.

The Failure Workshop

Stories of the games that failed, and what you can learn from the attempts.

Robot and the Cities that Built Him

Went 6 months before doing a gameplay prototype, then realized that despite all the polish, the gameplay just wasn’t fun.

No amount of theming will save a bad idea.

Also, trying to live up to a previous game is paralyzing. Let go of your expectations for yourself.

Cat Mouse Foosball

George Fan designed a game, did some sketches, and thought it would be amazingly fun. When he prototyped it, he found that it just wasn’t any good. There was a total disconnect between how he thought it would play, and how it worked.

The difference between artists and designers:

Illustration takes place primarily in the mind. You imagine the total image you want, then make it.

Design can’t possibly imagine all the aspects of gameplay and the interactions between the systems. You can’t just think up good gameplay, you have to try it out!

Start prototyping as soon as you can!

Off-Road Velociraptor Safari HD

First off, calling it HD was a mistake. It builds a particular set of expectations. ‘Remix’ might have been more accurate.

They thought that doing an updated version of an old game would be easy, but it was a grind. Don’t confuse comfort with happiness – you may know how to improve these textures and remake these models, but that doesn’t mean it’ll be fun.

They lost sight of “games should be fun.” The game stopped being made for the players, and started being made for other purposes, to keep up with other games, to show off, etc.

Elemental

Unlike the other games on the list, Stardock actually released Elemental.

They had a small-company structure, and when they increased the size of their team, they didn’t improve the structure. What works for 7 doesn’t work for 25.

It’s hard for a small studio to swallow the need to pay for a full-time producer. He’s not contributing, making art or code! What good is he? Well, you need someone objective to keep the project in line, and to have no personal involvement in any of the production. You need someone who can kill those unnecessary features.

Come down hard on scope creep. Keep your design focused, and don’t let people add new features without the producer’s say.

Rock Climbing Game

Chris Hecker kept adding more and more systems to the game: body physics, fatigue calculations, balance calculators…eventually, he realized that he was scared of the game’s design. He was retreating into his comfort zone – technical systems – as a way of avoiding the issue that he didn’t have a game yet.

NBA Jam Postmortem

How did they make such a strong sequel to NBA Jam? He cited the rule of thirds:

1/3 the same. Give the fans the things they remember.

1/3 improved. The same, but better. Don’t mess with the formula, but improve it.

1/3 new. Give them new features and ideas, but don’t violate the spirit of your source material.

Always stay true to your source material! In their case, they chose a specific example – the first arcade cabinet of NBA Jam – and based all their decisions on how to recreate that feeling.

On Voice Actors: Help them get into character. He referenced that the voice of NBA Jam had this really exuberant Scottie Pippin poster that he tacked up in the recording booth, and it helped him drop into the NBA Jam voice instantly. Think about props, posters, concept art, and lighting that you can use to get your voices in the zone as quickly as possible.

Overall, find your fun as quickly as possible. Identify your core gameplay, and make it shine.

Independent Game Festival Awards

Lots of good games I need to check out. Fract, Amnesia, Nidhogg, Desktop Dungeons, Bastion, Dream Machine, B.U.T.T.O.N., ByteJacker, Limbo, GameDevStory. I’m going to be busy!

Game Developer’s Choice Awards

Red Dead Redemption is game of the year! It wouldn’t have been my choice, but there’s no denying that it’s a great game.

Double Fine revealed their next game, Trenched. The trailer doesn’t do a lot for it; it’s a mech shooter. If there’s a cool twist, I didn’t see it in the footage they showed.

Gamespy Party

Met with a friend from UCI, Charles Black, and got into the Gamespy party. Talked to some people, exchanged some business cards. It was fun, although the food and the drinks both ended far too quickly. What’s up with that?

GDC Report – Monday

From February 28 to March 4, I spent most of each day at the Game Developer’s Conference at the Moscone Center. I took in a massive number of sessions and lectures. Here’s the chronological list of what I did, and what I learned from each event.

Monday: Indie Gaming Summit

The Humble Indie Bundle

This panel discussed how the Humble Indie Bundle came to be, and their learnings from pricing the bundle. If you’re unfamiliar, the Humble Indie Bundle is a website that, for the last two holiday seasons, has offered a bundle of Indie computer games for any price. You enter any value, from $0.01 to infinity, and get your games.

Interesting points:

It took about 6 months from the concept of the Bundle to actually launching the website.

Bundle 1 sold $250,000 in the first 24 hours, and made $1.27 million total.

Bundle 2 sold $500,000 in the first 24 hours, and made $3 million total.

Mac and Linux represented about 50% of the revenue, despite being much less of the total in terms of bundles sold. Moral: Support Linux, those guys are willing to pay for your games.

For HIB2, they did a promo where you also got HIB1 if you donated more than the current average. Unsurprisingly, their average saw a huge boost!

Marketing: It’s not hard to get on sites like Digg or Reddit. You just need a compelling story that people will want to share.

Care and Feeding of your Indie Game Studio

The first part of this session was a sort of mini-rant at casual game portals, for accepting too many games, having too many clones on them, and reducing the quality to the point where people couldn’t find the gems. It sounds a lot like the iPhone these days.

You can do low-risk indie development. Make a small game. Use the proceeds to make a bigger game. Use those proceeds to make a bigger game. It’s very slow, but you can do it without selling out.

Think of your products in terms of IPs – the individual products/SKUs don’t matter. On that note, port your game to as many platforms as you can, too.

The trick is to get your game to stick anywhere. If your game does okay everywhere, but does great on Android, you can leverage that, cross-promoting to other platforms.

Don’t outsource your game design and development, but you can outsource translations.

He recommended that indies don’t start on Facebook. It’s too easy for other companies to buy your users away from you.

Feel free to try different business models: packaged, freemium, subscription. Who knows, maybe one will work!

Perfect a single mechanic, publish it, and keep improving it. Pretty soon you’ve got a really good game.

Innovative design protects you from cloning, gives your games a long lifespan, and gets you more media attention. Go for innovation!

Keep it small, keep it all!

Game Design By Accidents

Some classic games, such as Tetris and SimCity, came from accidents. The designer was working on a different idea, and stumbled across something interesting – like “rotating pieces is fun!” or “the level creation is more interesting than the game. Hmm.”

The speaker suggested you start coding before you have a really solid game idea. Just start messing with code. Eventually, you’ll stumble across something interesting and fun, and that will launch you into a game.

An extra bonus is that, when you stumble across a neat feature while coding, you don’t have to figure out how to make it happen – you already programmed it!

He suggested Ruby as a programming language that lets you make lots of interesting code quickly and see the effects.

Super Meat Boy Meatmortem

Super Meat Boy was just the right project at the right time: they wanted to do something for consoles, and Meat Boy was doing well as a Flash game. Super Meat Boy was just going to be a small test, but then they discovered they had something compelling, and decided to expand it.

On conventions: going to cons and preparing demos for shows can totally mess up your schedule, but they’re good for your confidence when you see people having fun with your game.

Another lesson they learned is to do your own promotion as much as possible. You should get outside promotion as much as possible, but don’t rely on it. Microsoft made a bunch of promises to Team Meat, and they pretty much all fell through…but Super Meat Boy was successful because Team Meat had gone out and made themselves visible, and drummed up excitement on their own.

Leave Enough Room

Designing games with enough room for the player to express themselves. The speaker defined expression as any time a player makes a choice from a range of valid options. The trick to games is to give enough valid options that the player can choose from. Character appearance is an easy one, as long as there are many good choices. Same with weapon selection – as long as you can finish every mission with every weapon, then weapon selection is an expression of a player’s personality. It’s interesting to think of expression as meaning more than just ‘branching storylines.’

Don’t tell the player what to do. Score can be dangerous in this sense: making one path worth more indicates that it’s the ‘right’ way to play.

Lower the minimum threshold for success. Allow any idea to be successful with effort, but also allow the player to go above and beyond the minimum requirements if they want.

Make elements that are agnostic, and react to the player’s actions. Is this character a friend or enemy? Is this item a tool, or a hazard? It depends on what the player is doing.

Give the player tools to say things. Or to phrase it more technically, empower the user to generate data. Then, react to that data. Let the player see what they made, share their choices, and give unique gameplay reactions or events based on their style.

Turning Depression into Inspiration

Indies work long hours, often alone, on repetitive tasks. It’s not surprising that they get depressed. However, indies can’t afford depression – making games is what they do, and you can’t just say “I don’t feel like being fun this month.”

Depression is self-reinforcing. You feel worthless, so you don’t want to do anything. But then you haven’t done anything, and you feel worthless.

Ways to combat depression:

Highly rewarding projects. Get to the gameplay. Do a project you love working on. Don’t get bogged down in details. Just be careful – it’s easy to do all the fun stuff on a project first, then have nothing but months of slog left before it can ship.

Create progressive gameplay. Progressive gameplay can be played at any time; you just keep adding features to it to make it more fun. On the contrary, complete gameplay needs to be fully developed and realized before you can try it out. As an example, in a platformer, you just need to code in movement and jumping, and you can start trying it out. But to really try out an RTS, you need resources, resource units, buildings, a building queue, unit production, unit pathfinding, attacking, tech trees, fog of war, etc.

Work on awesome ideas, stuff you really believe in. Design for yourself, and enjoy your day to day work. What do you love? What do you hate? Use your personal skills and interests, and express them in the game – and create a design that doesn’t require things you hate. (Don’t like doing server code? Don’t make a multiplayer game!)

Stop being a perfectionist. You’ll never get anywhere if you aim to make the perfect game. Get other people playing your game. Call another designer you know, and ask them how they’d solve the issue you’re stuck on.

Get on Steam and play indie game demos. You’ll get new ideas, and you may find that the quality bar for a finished title is lower than you thought.

Measure the hours you spend on the game. The speaker recommended Procrastitracker. When you’re depressed, it’s easy for your work hours to start shrinking, without you even realizing it.

A game is the result of thousands of choices. When you’re an indie developer, all of those choices are yours, and every choice is affected by your mood, no matter how much you try to avoid it. Game design is experience design, and expression is an experience. Let your experience come through – make a dark game if you need to – and let your depression carry your design until you climb out of it.

From AAA to Indie

Stories of developers who went indie after being in the industry for a while.

Jake Kazdall from Skulls of the Shogun laid out the pros and cons: you avoid executive mismanagement and gain creative control, but you take a huge financial risk! Also, you’ll have to go outside your comfort zone. As an indie, you’re doing art, programming, PR, business development…you can’t be just an effects animator or whatever anymore.

Jake emphasized style guides. Create a vision, then document it. Keeps everyone on the same page, and helps anyone new get up to speed quickly.

Build a brand. Market the idea of your game, and market yourself. As an indie, your success is entirely dependent on you!

Show your game to people. Watch them play. It’s easy to accidentally make a game that only the developers can play.

Old cartoons are a great visual style for 2D games – characters that are distinctive, even on a fuzzy black and white TV.

Create a vertical slice: take a piece of the game and make it perfect, to understand how long the perfection process is going to take for the rest of the game. Another developer later at GDC also mentioned vertical slice, but he recommended keeping the visuals and gameplay separate: make a polished piece of gameplay, and a polished visual presentation, but they don’t need to be the same project. The reason he gave was to be able to keep as much of the vertical slice work as possible, and to throw away as little as possible.

Get playable! A good playable game is better than a hundred great unplayable ones.

Daniel Cook from Spry Fox stepped up next, recommending a portfolio approach to indie game development. Have several games in development, so you’re not relying entirely on the luck of one game – and it’s more interesting to move back and forth between projects.

Get people onto your own website. Web portals can get you started, but players coming directly to your website gives you a bigger piece of the pie.

Too many designers are like too many cooks. Have one designer, and just follow your instincts.

Teams should try to iterate daily – have something new to show every day, and play it. Every iteration is an opportunity to find the fun and cut out the problems.

Most games are disposable experiences. Building a long-term, meaningful hobby is hard. Ask yourself: will anyone play my game in 10 years? Multiplayer and community features are very important, but not many indie devs know back-end development. Developers who know back-end/multiplayer code are gods.

To hire new people: give them a short project, test them out. See if they have the skills…but more importantly, do they finish the project?

Great teammates are reliable, can see the big picture, work well with others, and respect the game designer (and don’t constantly try to insert their own design ideas into the game without asking.)

Great teams make the impossible possible. Sometimes it’s good to look at the games of today, and ask, “What is impossible…and how can we make it happen?”

Also, Realm of the Mad God is really good. And addictive.

Ichiro Lambe, from Dejobaan Games.

His advice:

Think holistically – meaning ‘as a whole system.’ It’s often said that indies wear many hats. How can you make your many hats into one hat?

For example, you might have to do both marketing and customer service. However, if you can think of them as the same task – communicating with people outside the company – it helps you understand how they’re connected, and lets you do more with less effort.

Tie marketing into design. Marketing is not “convincing people who weren’t going to buy your game to buy your game.” The best marketing is to create a product that people want – to make something so wonderful that people will give you money and talk about it. You can save a lot of time and money by making a game that can make an impression without being forced in front of people.

Pick a game you want to make, AND a game people want. Follow your instincts…but also listen to the market’s instincts, too.

Next, he emphasized planning. Trust that your team is competent, but also understand that creative people need budgets, plans, and schedules. Make sure you allocate time for postmortems, too; understand why a plan worked or didn’t, then put it aside and move on to the next plan. Learning takes time.