Mark Cerny’s Keynote

Mark has been in the industry for 27 years, consulting for 10 years working across a variety of roles from programming to production. His games have sold millions of copies. Works at Naughty Dog on their stable of titles.

Joined Atari games in 1982 (their coinup division), 11 years into the videogame industry.

Originality is KING! Was the motto – every game had to be a new genre. If it already existed, it was not an option. For example Super Sprint was considered selling out by many as it was an update to the original Sprint and therefore not original.

Industry was booming at the time – 6 billion dollars in quarters going into machines. 80% of that money was going to the operators. As a result, the industry was tiny. 15 programmer artists, 1 artist and a handful of business people = Atari at the time. The entire business was only 20x this size in total!

Sequels didn’t sell.

Asteroids sold 60,000 units – Asteroids deluxe sold just 10,000 units. Making a game that was similar to the first but shortened the gameplay experience (people were playing for an hour on the original on a single quarter) was an epic failure.

Process:

· Make game up to 80% point

· Put in a test location

· Measure income

· If it sucked, cancel it

2 of 3 games cancelled at this point!

Rapid hardware evolution was happening at the time. Mark’s first game (Qwak!) was one of these casualties. Marble Madness was the first use of the 68000 CPU, C and FM sound synthesis.

Back then, no assets!! Asteroids had about 15 simple assets.

Alpha & First Playable were roughly the same (1982ish), with Alpha often hitting within a week of first playable.

There was a deep management structure at Atari, all of whom typically wanted to be involved in the creative process. One of their sayings was “Success is random” (!).

Credits in 1982 – “the game is a corporate creation”. After a game had shipped, you were highly discouraged from mentioning you were even involved, in case you were head hunted by another company.

Arguments against credits: Too much memory, implementation time is too great, hurts team spirit…

Production methodology lessons learned:

· Not much

· Starting from scratch each time

· Complete chaos

Lessons learned:

· Slow and steady can and does win the race

Did not learn

· Estimation – games took an arbitrary length of time

Mark moved to Sega in 1985 to work on home console games. Sega’s motto was to make MORE games than Nintendo – they were behind, with around 40 games compared to Nintendo’s 80.

Production methodology: WORK YOUR ASS OFF! 1 programmer +1 artist x three months = 1 game. Sweatshop environment very literally, down to the layout of desks.

Despite this awesome approach, Nintendo had 94% market share compared to Sega on 4%, with 2% left for Atari.

Production methodology lessons learned

· Simple production does not equal easy scheduling

Mark joined Crystal Dynamics in 1992, making games for the 3DO Multiplayer. Suspected that “3DO” was short for “3Don’t”, as it was poor at doing 3D. Actually it was poor at 2D as well…

Production Methodology

· Venture Capital based

· 12 SKUs by year 3

· “Make ‘em fast”

Used the “proper process”

· Design it!

· Plan it!

· Produce and manage it!

And yet it didn’t work

Mark joined Universl Studios in 1994 as Vice President of development. Was given 3-6 months just to figure out what he wanted to do, with a budget of millions of dollars and no pressure on release.

Myth: It is possible to plan and schedule the creation of your game

Myth: Working productively means throwing out nothing

Myth: Frequent project review is essential to good management

Myth: Alpha = First Playable

Myth: A cancelled project is a sign of bad management or a bad team

Myth: The more defined your initial vision, the better. I need a 300 page document describing my game!

Myth: If you want to make a hit game, listen to the consumer

Method (1995) was a production methodology that defined the stages of production and pre production: First playable became the publishable first playable, the vertical slice. This pushed the chaos into the front period and ensured that production was more manageable and predictable.

Many projects won’t make it out of pre production – this has always been true and is likely to remain true.

Avoiding large design documents is good project management. You need one but it shouldn’t be out of whack with the scale of the project.

In 1982, Mark knew exactly what the player experience was in his game.

In 1995 he knew nothing about the player experience

With this in mind, Mark set about coming up with a production methodology to help understand the player experience.

Issues with Diifficulty, Comprehension and Bugs

Bug testing now is about finding bugs before release but no testing is done on how bugs affect the consumer experience. Once it’s shipped, testing and bug issues are over for the developer / publisher.

In 1995, you found out what the consumer thought by focus testing. Focus testing (concept testing version) is not great at finding truly successful concepts. Gameplay testing as a focus testing method is also extremely limited in applicability or as a real world measure of game quality.

A playtest, on the other hand, comes much later in the process and is much longer, focusing on difficulty and comprehension.

A playtest allowed you to check qualitative and quantitative issues, collecting metrics on where people die / get lost and how long they spend in each area, where the puzzles are difficult etc. You can also ask how they feel just be careful! It’s not a statistically significant sample and it’s subjective, don’t knee jerk react to this stuff.

In 1995, you could test your game in your engine quickly. By 2001 it was getting harder – tech takes so much longer to come online. So it made sense to start using other engines or tech to get gameplay polish in before the tech was ready. Now, however, that’s much harder thanks to the subtleties of the actual engine, including animation and visuals, having a massive impact on gameplay – see: Drake’s Fortune.

It’s hard to know what you’ve got until you’ve nearly got it. In the future, this should improve, taking us back towards where we were with regard to being able to prototype gameplay.

Our first “new” problem: TECH

Initial systems: difficult to predict time

· No legacy

· High “productivity”

· High wastage

· Low “effective productivity”

Mature Systems: Difficult to predict time

· Many internal interactions

Our second “new” problem: GOALS

There’s a conflict between perceived goals and actual goals

· Artist: best environment ever! = most visually complex?

· Programmer: Best AI ever! = most scripting options?

· Designer: Best puzzle ever! = hardest to understand?

· Writer: Best story ever! = most plot twists?

Good PM methodology: Bounding and directing the creativity

This is going to get harder and harder as teams and budgets increase – a tight feedback loop is a boon in ensuring that people work on the right stuff.

Final rant: NONE of this MATTERS

Culture trumps process

· Embrace the right kind of risk

· Support the true believer

The funnel – don’t be afraid to throw things away if that’s what helps you find the best option to move forward with. If that’s your culture.

Supporting the true believer:

· Focus tests

· Project cancellation

· Frequent management review

Is this Good? Or Bad?

Eyes on the prize…

· Play it!

· It’s a game!