malvasia bianca

Not a great day for me. The morning was postmorterms for games I’ve never played; I basically enjoyed the postmorterms, but in retrospect I should have tried something else. And both afternoon talks were actively disappointing.

Or at least not a great day for me in terms of talks: I had a lovely lunch with Jorge Albor and Richard Clark (the latter of whom I’d never met before), and a lovely dinner with many people. I think I’m more talk-focused at GDC than most bloggers, but still: it’s always great to see people in person.

Anyways, here are my notes; I haven’t bothered to particularly polish them this time, they’re more or less straight off of the iPad into here. (With, of course, appropriate <cite> tags added…)

10:00am: Timothy Cain, Classic Game Postmortem: Fallout

Development began in early 1994; shipped in October 1997. Team size of about 30 people when it shipped; total budget of around 3 million dollars. Doesn’t know exactly: he never went through a formal budgeting process.

No license; no engine; no budget (he didn’t have to go to producer meetings); no staff at the start (he’d talk to people over pizza in the evenings); no plan/specs.

Amazing team. (Once he got a team!)

Influences:

Computer games: XCOM; Crusader (one of first 640×480 games, graphics looked super sharp); Wasteland (huge influence; no morality, no restrictions); Ultima series.

Paper and pencil / board games: GURPS (classless, skill-based RPG); WizWar (shuffle board pieces every time you play); Gamma World

Books: A Canticle for Leibowitz; I Am Legend (and the movie Omega Man: last normal person on Earth); On the Beach (movie, too; group thinks they’re the last survivors of a nuclear war until a sub shows up)

Movies: Road Warrior; A Boy and His Dog; The Day After; Forbidden Planet (technology based on what the 50’s imagined the future would be like); City of Lost Children (huge art influence); La Jetée

Challenges:

Team: no resources. Just him for the first six months. 1 artist and 1 scripted for the next six months. (Both named Jason…). Couldn’t tell the artist what to do: he hadn’t picked a genre yet, he just had an engine. In year 2, they went up to 15 people. 30 people in year 3.

Early development was rough. They had a hard time conveying the idea of the game (once they got the idea!), to new people, to marketing, to administration. It was very bleak, sounded not fun. And they worked nights and Saturdays, even from the start; for the last half-year, for six months they’d work 12-14 hours every day of the week. They were in their twenties and didn’t know any better. QA volunteered to work on weekends for free, even though they could get paid overtime.

Setting: considered fantasy at the start, but there were a lot of a fantasy games coming out at the time. Second idea: epic time travel, dinosaurs to space. Seriously considered it, but another producer convinced him it was crazy. Then: invading aliens, taking over the entire planet except for one city. (That one city home base morphed into the vault.) Finally: post-apocalyptic, initially hoping to use the Wasteland license.

Threat of cancellation: Interplay acquired the D&D license, with Forgotten Realms and Planescape, in 1994. Fallout was considered as a B product, competing with those others.

View: 3rd person, isometric with 30/60 degree angles. (“Cavalier oblique”.) Chosen because it worked well with a hex grid that underlay he tiles.

Game timer: for a sense of urgency, players had to finish the first quest in a limited amount of time. Controversial within the team, and removed in the first patch; he wished they’d removed all timed quests.

Cultural references: there were a lot, but he was worried about losing players and feeling dated. So the rule was: people who don’t know the reference don’t even notice that a reference is being made.

Naming: started with Vault 13. Marketing didn’t like it, because it didn’t explain what the game was about. Alternate ideas: Aftermath, Survivor. Came across the final name 6 months before shipping. Also wanted to name the system; attributes’ intials spelled out ACELIPS, rearranged to SPECIAL.

Diablo: released late 1996; realtime, multiplayer. Spent a while seriously considering that, but ultimately decided not to.

Technical Challenges:

Flat memory: chose a linear memory model. No expanded/extended memory, no near/far pointers. Easier to work with, but couldn’t use old code.

Super VGA: 640×480 with 256 colors. Art assets started off as 16 bits, reduced to 8, color cycling reduced it further. Until VESA in 1994, each chipset was separately coded.

Sprites: polygons weren’t detailed enough. But sprites led to lots of memory.

Talking heads: fired a clay head in a kiln, used a 3D scanner to get a point mesh, added polygons/color/lighting. And then phoneme matching for talking! Took about 4 months per head.

Followers: not in initial spec, no time to code, so done through scripting. Lousy AI, full of bugs, but very well received.

Win95: failed certification because it worked on Windows NT, instead of failing gracefully. He recoded the installer to detect NT and fail; hand installation still worked.

Simultaneous Mac version: OS calls were isolated in a library, Mac version was written in a weekend. Interchangeable save games, which was stupid in retrospect.

Legal Challenges:

GURPS: originally based on this license. They didn’t like the violence and the art style; too late to change these, afraid they were going to be cancelled. Instead, they tore it out: redesigned/reimplemented the combat/skill system in 2 weeks, were allowed to survive.

Music: chose Inkspots. Wanted “I don’t want to set the world on fire”, negotiations took forever before falling through, picked “Maybe” mostly at random, worked well.

Ratings: went for T initially for some reason, but was inappropriate; ended up M, which was fine. Also allowed child killing (at a penalty); had to be removed for Europe.

Legacy:

Shipped in October 1997, seen as a big risk that paid off. (Though it didn’t cost that much, so maybe not a big risk?)

Open world / sandbox, with a non-linear story. Multiple solutions to quests/story: at least two of fight, talk, sneak. Quest and story endings based on your choices; sideshows reinforced this. (Consequences were sometimes horrific, people replayed to get a new ending.)

No morality: grey-area quests, player can be good or evil, but you have to live with consequences.

Perks: wanted more than skill raises, invented/implemented in two days, players can grow and differentiate. Influenced a lot of subsequent games.

Called shots: added variety, allowing multiple reactions to the same attack. And a place to fit in humor.

Faces / voiceover: detailed faces, famous voices. People really liked it; expensive, though.

Ambient music: don’t actively listen to it, just hear it, miss it when it’s not there. Reinforced bleak environment.

Reusable software: OS abstraction, scripting engine.

The game as experience: box, survival guide manual, logo, interface, splash screens, web page.

Amazing team: talented, worked crazy hours, egoless, focused on the same goals, the same game.

11:30am: Luke Muscat, Depth in Simplicity: The Making of Jetpack Joyride

Chapter 1: A Game in 4 Weeks

Fruit Ninja doing great; Monster Dash doing okay. Liked the machinegun jetpack in Monster Dash, decided to make a 1-button game based on that in 4 weeks, release it for free.

1 button, super accessible, play session fits in an ad break, depth for the hardcore.

Put together a prototype in one day; whoever gets the high score the next day gets a free candy bar. People tried really hard, so there’s enough there to support interest.

Next: jam stuff in, rip stuff out. (Got that term during GDC last year.) 3-day prototype looks better, has more stuff: coins, lasers.

Decided to try procedural levels: only one designer across two projects meant that they didn’t have resources to do lots of levels. Procedural levels take a lot more time at front, but pays off. Came up with an interval system, with every type of entity having a chance of fitting in the next slot. But how to design the intervals? Regular is boring; totally random is occasionally crazy. So random with minimum and maximum interval length. Really easy to change, which has dramatic effects on the difficulty of the game.

Minimum intervals let you decide how unfair the system will be. All their games are deliberately designed to be a little bit unfair: e.g. in Fruit Ninja, the bombs sometimes overlap somewhat with the fruit. Works well with high score games: place some of the blame on the game, “if only that bomb wasn’t right there, I’d have done a little better”.

Costs of failure: time lost; feeling of failure; friction in retry loop. Help with feeling of failure by rewarding on failure: happy results screen, fruit facts. Fade the end of failure by having your corpse bounce along for a couple of seconds, hoping to collect a few more coins. For restart friction: every single thing in the game involving progressing is in the bottom right corner, can start a new game without thinking.

Internal playtests; but learned a lot by handing it to people on the street and asking them to play it for two minutes.

Christmas: already spent more than 4 weeks. Fruit Ninja was picking up steam, didn’t want to release a half-assed game after that. Really intense and simple, but intensity ramped up too fast, and it was too simple. Tried moderating intensity with hearts, but it didn’t feel right. And tried regenerating health; but could only kill the player by making the game too hard.

As to too simple: need variety. Brainstormed ideas for powerups, but it was really hard to come up with good ones. Maybe change the controls; but takes a while to learn the new controls, players die too fast. Solution: powerups are vehicles, so if you get hit, the vehicle explodes, putting you back to your original state. So vehicles are special bonus segments, and you can ramp up the difficulty in those segments. Also helped inject character into the game.

Last year’s GDC was the first big playtest. People often made critical mistakes right after control changes; added explosions when entering/exiting vehicles to give breathing room. Then added coin sequences, as mini-tutorial playground area to explore the controls.

How many vehicles? Everybody has a favorite; want it to be rare enough to feel special, but frequent enough that you don’t go too far without getting it. Tweaked probability to not have long gaps before getting vehicle needed to complete a mission.

That’s a good foundation; what are next goals/experiments? Make an ultra-sticky game; try out in-app purchases; learn something.

Shop: provide incentive other than beating friends. Allow players to express themselves. First started with a standard costume shop, but it felt too dry. Added flavor text, but didn’t fit together well. Screens were too busy, too many words. Pulled categories out to top layer; gave more space.

Mission system: inspired by Tiny Wings. But don’t want to get stuck on a mission. They’ll come up with something in a week, right?

Tried a few different ways to structure this. One, daily system: each day, get easy / medium / hard missions. Always something new, something you can succeed at. Second option: optional system. Always have two missions, one of which can be done through grinding. Third option: progressive system, always three missions available. (I think the main difference is that the missions you didn’t complete would stay instead of going away after you completed one?) Progressive is closest to final version.

Mission rewards. Originally had a choice between coins and a random box, but it was very hard to tune the box as people completed harder missions.

Eventually, missions turn into a crazy surprise mega feature. Massive draw, many many layers of goals, crazy addictive.

What about really hardcore players? Borrow a prestige system from Call of Duty, but with mixing and matching parts, allowing 125 different medals. (Even a single medal was supposed to be very hard to get.)

Getting the game out the door. Wanted it to work at 60 frames a second on all machines, and look good on retina screens, iPad, all fitting under the 20MB limit. Ends up upconverting sprites on the fly the first time you boot it on a retina phone! And scaled down to get smooth performance on old devices.

Change the game from Machine Gun Jetpack to Jetpack Joyride right before the end. Old name not quite causal enough, and got truncated inappropriately on the app store.

Final result was great: took forever, but instant success, worth the extra effort.

2:30pm: Adriana Lopez, Ownership – Dragon Age Style

Games are great, starting with a wonderful idea; if you’re lucky, you have talented people working with you. But it’s also a business: you need to get something done in limited time with limited resources. How do you get the best result?

One typical idea: ownership. Let people do what they’re best at. But it can be lonely. (Not sure I entirely understand what she was saying here.)

Metaphor: pirate ship, adventuring into unknown waters together.

What is ownership? Passion meets skill. Not just hard skills: they’re necessary, but need soft skills, too. Strongly caring about something; ability to drive to success; being accountable; taking decisions; communication. It is not: being territorial or possessive; being a lead or a scrum product owner.

An owner can be anyone, independent of their title and level. And they can own anything: an asset, a feature, a part of a project, a vertical slice or demo, a project, a platform. Any portion of development that requires special attention.

Ownership and delegation: you are fully responsible for your area, but someone has your back.

Make it formal! Ownership behind the scenes is useless. Announce it broadly; define area of responsibility and expectations; provide training and mentoring.

Expectations: what is your job? Formulate a clear vision. Define the scope. Prioritize features. Accept or reject work results. Work with the rest of a team.

Vision should be clear and concise, should be aligned with the main vision, should be inspiring.

Scope defines what’s in, what’s old. Shoot for the moon, but start with something attainable. And keep other areas in mind: it’s not about you, it’s about the game.

Prioritize: if you don’t decide what the priority order is, someone else will decide it for you!

Seek feedback. Create a culture around feedback.

Work with other owners. Delegation means you’re not working in isolation, you’re part of the team. Guest speakers, wiki pages, ownership meetings, dependency charts. When in doubt, talk.

How many owners do you need? As many as the number of risks, ideas, features, other that you have in your game.

Ownership keeps top talent engaged. Delivers great games. Ensures a lasting franchise.

Editorial comment: she and I have quite different ideas about what the term “agile” means, I think. And she never gave a clear view of what she saw as the alternatives to ownership, and why she preferred an ownership culture; in particular, I like collective ownership a lot more than individual ownership, and I don’t think she even addressed that as a possibility.

4:00pm: GDC Microtalks 2012

The speakers: Richard Lemarchand, David Sirlin, Erin Robinson, Cliff Bleszinski, Alice Taylor, Mary Flanagan, Brandon Sheffield, Heather Kelley, Dan Pinchbeck, Amy Hennig.

By far the weakest GDC microtalk session that I’ve been to. I expect several of the microtalks to be more poetry than talks, but none of them reached that this year.