Game Design: Theory & Practice- P13 ppsx

They use meaningless descriptions like “gameplay will be fun” and “responsiveness will be sharp.” In these documents, many comparisons to other games are made: “This plays like Super Mar

Inauspicious Design Documents

As I previously recommended, it may be useful to try to get your hands on someprofessional game design documents in order to give you an idea of what the indus-try expects in such specifications However, you must be careful It is likely that thedocument you obtain will not be any good Many of the documents that have beenused for published games and which were written by experienced professionals aretruly terrible By way of example, and in order to best teach you what to avoid, Iwill explore a few of the different types of horrible design documents, and why theyfail so miserably at what they are supposed to accomplish

The Wafer-Thin or Ellipsis Special Document

These thin little volumes, certainly none longer than thirty pages, startle and amazethe experienced game designer with their total and complete lack of any useful con-tent whatsoever They use meaningless descriptions like “gameplay will be fun” and

“responsiveness will be sharp.” In these documents, many comparisons to other

games are made: “This plays like Super Mario 64” or “The game has a control scheme similar to Quake.” While such comparisons can be slightly useful, as I have

discussed, the writer of the Wafer-Thin Document almost always fails to go on to

explain the control scheme of Super Mario 64 or Quake in any detail, let alone the

scheme to be used by the game in question

Often these documents spend a lot of time, maybe half their pages, talkingabout back-story Usually this back-story is very weak and poorly developed and isonly tangentially related to the game being developed The Wafer-Thin Documentalso spends a lot of time talking about how the menus will work Not the in-gamemenus, but the system menus where the user selects what type of game he wants toplay, sets his options, and so forth Many mock-ups are made and options carefullylisted What exactly the options will affect in the game is seldom described in anydetail, since the game itself is barely defined Figuring out the menu system issomething best pursued once the game is working, when the designer knows whatsort of options might be important and what different gameplay choices the playerwill have; it is certainly far from the most difficult part of game design, nor themost important system to nail down first

Wafer-Thin Documents are often constructed by managers who like to thinkthey are game designers The reason these can also be called Ellipsis Special Docu-ments is that they are often littered with ellipses For example, the worlds the playerwill encounter in the game will be described in the following manner: “JungleWorld is a very hot and sticky place where the Garguflax Monkeys swing aroundand torment the player ” And that will be all the document provides in way ofdescription for the world, ending at an ellipsis, as if to say “insert game design

Team-Fly®

here.” It is unclear whether the writers of these documents plan to come back andfill in at the ellipsis later or that perhaps they do not deem it worthy of their valu-able time to actually explain how their game works They just assume someonesomewhere will fill it in and make them look good.

Another example of the content found in Ellipsis Special Documents might be:

“The player will be given an option of many cool weapons For example, the gantuan Kaboom does twice the damage of the player’s other weapons and has aspecial effect The Barboon Harpoon will allow the user to kill enemies at a dis-tance with a nice camera effect Other weapons will be just as fun and cool ”Here the writer of the Ellipsis Special fails to describe the weapons the game willhave to any useful level of detail, and then, having listed two weapons, decides toleave the rest up to the imagination of the reader Of course, readers are very use-fully told that the other weapons will be “fun and cool.” The writers of the EllipsisSpecial mistakenly thinks that is all the description necessary to develop a game.The only advantage to the Wafer Thin or Ellipsis Special Document is that itallows whoever gets to implement the design to pretty much take over the projectand turn it into her own I say this is a good aspect, since usually the ideas the man-ager included in the Wafer Thin Document are beyond ridiculous and do not makefor viable gameplay But one must be wary Problems arise when the managershows up six months later and complains: “But that’s not what I wrote!”

Gar-The Back-Story Tome

Unlike writers of the Ellipsis Special Documents, the designer who writes theBack-Story Tome spends a lot of time working on his document These books (it ishard to call them merely documents) usually stretch into the hundreds of pages—300-, 400-, even 500-page documents are not out of the question There’s a lot ofinformation in there

The first mistake these documents make is usually a poor table of contents andthe lack of an index In a design document, well-ordered information and a goodtable of contents can replace an index, but the absence of both is a huge error The

problems are compounded when the document is as long as War and Peace The

primary reason for the existence of game design documents is to allow team bers to quickly look up information about a section of the game they are working

mem-on If a programmer wants to know how the AI for a particular enemy is going towork, she needs to find that information quickly and easily If she cannot find it,she may just make something up Similarly, when an artist wants an idea of the tex-tures that will be needed for a given area in the game, he wants to be able to findwhere that area is described as quickly as possible Design documents are not readlike novels No one starts at the beginning and comes out at the end Primarily,design documents are reference materials, and if team members cannot easily

retrieve the data they are seeking, they are liable to give up.

However, once one starts hunting through one of these Back-Story Tomes, one

is startled to find that, indeed, there is no information about the gameplay in there

It is all back-story And at five hundred pages, it is far more back-story than mostcomputer games will ever use The history of all the characters in the game, thefriends of those characters, and all the relevant parents and siblings are alldescribed in minute detail It may be very interesting stuff (though usually it is adisorganized mess), but in the end the reader is left with very little idea of how thegame is supposed to function A lot of games make storytelling one of their centralconcerns, and a story bible can be quite useful to game creation In such a case, itmakes sense to discuss the game’s story in the design document to some extent Butfirst and foremost, a design document is supposed to contain the game’s design,which is very different from a game’s story Though these Back-Story Tomes arevery impressive in terms of weight and will probably impress the venture capital-ists, the programmer who has to work with such a tome as his only guidance isgoing to end up designing the game himself

The Overkill Document

Some designers think they can describe every last aspect of a game in the designdocument It is certainly true that many design documents lack the necessary detail

to be useful, as we found in the Ellipsis Special Document discussed above, but atthe same time, going to an excessive level of detail can be a waste of the designer’stime as well as the person who has to sift through all of that excess information.Furthermore, excessive documentation can lead to the illusion that the designer hascreated a complete, thorough document, when in fact he has gone into far too muchdetail about certain subjects while skipping other areas that need to be addressed.For example, suppose that the game being documented has a number of charac-ters who perform certain actions in the game-world Say the game has townspeople,and they need to walk around, sit down and stand up, talk to each other, and sleep.The document should describe these behaviors in the AI section A truly thoroughdocument might break this down into separate animations: stand from sitting, sitfrom standing, idle sitting, idle standing, walk, converse with hand gestures, and so

on Probably this is not necessary, since a good animator and lead artist will be able

to break this down better than a designer can But some designers may go board and actually sketch or list the individual animation frames This is absurd.There is no way to know in the design document stage how many animation frameswill be required for a given animation This sort of decision can only be made andadjusted during the game’s production Not to mention that listing animation frames

over-is insulting to the animator who will only feel demoralized by thover-is degree ofmicro-management Furthermore, the design document should stick to gameplay

design, and not veer into the territory of the art bible or other art documentation.Another example might be what I call “balancing data.” These are the actualstatistics for the weapons, items, and characters found in the game The design doc-ument should probably list what different attributes weapons and characters willhave For instance, a weapon might have a range, an accuracy, a number of shots,and a rate of fire Furthermore, the design document might want to describe thequalities of a given weapon: “The Double Barreled Shotgun has a short range and alow accuracy, but does a large amount of damage in a large area.” However, actu-ally listing the values for a weapon’s attributes is not very useful in the designdocument Saying “Shotgun Accuracy: 2” does not really serve any purpose sincethe number “2” does not have any context and therefore no meaning These valuesare best determined when the game is actually functioning, when a designer canbalance the weapons as they will be used by the player and thus the designer canexperiment with different settings to achieve the desired effects Creating largetables full of data before this information is actually testable is by and large a waste

of time

As with animation minutia and precise balancing data, source code also doesnot belong in the document Designers who start writing out algorithms in theirdesign documents are going too far It does not matter if the designer is also a pro-grammer There should be no code, not even pseudocode, in the design document.Including code will only serve to bloat the document and distract from omittedinformation which needs to be covered If there is any useful information in theOverkill Document, it is so hidden in the river of useless data that team memberswill be too intimidated to look for it The author of the Overkill Document thinksthat he can preplan everything, and that he is far more talented than any member ofhis team While such excessive attention to detail can be impressive to those who

do not really know what they are doing, a design document that goes too far willonly infuriate the team that has to work with it

The Pie-in-the-Sky Document

These design documents often have noble intentions with grand ideas for truly nificent gameplay Sadly, the writers of them typically lack any technical grasp ofwhat the computer is capable of or what a team of twenty people is likely to accom-plish in a year and a half As a result, these overambitious documents put forthfancy ideas with no basis in reality or feasibility and end up frustrating and infuriat-ing the teams assigned to “make them happen.”

mag-Pie-in-the-Sky Documents include ideas such as “a fully modeled replica ofManhattan will be the player’s primary game-world, complete with AI agents repre-senting all of the city’s seven million inhabitants in real-time.” The authors ofPie-in-the-Sky Documents do not want to be bothered with messy details such as

the reality that no existing computer system can simulate seven million humans inany sort of reasonable time frame (let alone real-time) Another feature suggested in

a Pie-in-the-Sky Document might be “a natural language parser will be includedthat allows users to type in full, complex English sentences which the characterswill respond to with their own dynamically generated dialog.” The guilty designerdoes not want to hear that research institutions have been working for decades onnatural language processors that still have trouble with short, simple sentences.Pie-in-the-Sky Documents are often combined with Ellipsis Specials into trulywretched design documents, where the guilty designer outlines a completelyimpractical project without bothering to go into much detail about it

The Fossilized Document

Any of the above flawed design documents can also be a Fossilized Document.Indeed, a design document which does not necessarily suffer from any of the aboveproblems and was once a fine reference tool will become a Fossilized Documentover the course of a project if the designer is not diligent in her efforts to keep thedocument up to date I know of no original game project whose design has notchanged significantly during the course of its development, and when the designchanges but the design document does not, that document starts to become a Fossil-ized Document

Suppose a programmer on the development team looks something up in theFossilized Document Say the information that person finds is out of date Theymay start implementing the old, long-since-modified functionality At some point, adesigner or producer who is aware of the changes that have taken place in thedesign will notice that the programmer is creating a system that is no longer appro-priate, and will chastise the programmer for doing so This creates frustration forboth parties, not to mention wasting the programmer’s time Furthermore, when-ever the programmer needs to know something about the design in the future, hewill not trust the design document, and instead will go hunt down a designer or pro-ducer to find out how a given system is supposed to function Of course, thisdefeats the purpose of the document, as the designer must stop whatever he isworking on to explain the system to the programmer This new system may bedescribed correctly in the document, but the programmer is not going to get burnedagain by using the Fossilized Document When the designer fails to update the doc-ument when design changes occur, the entire document becomes useless No onecan trust it, and as a result no one will bother to read it

A Matter of Weight

It is often joked that design documents are not read, they are weighed This is notsurprising given the heft of many design documents and the lack of desire amongteam members to read them Shockingly, this statement is often true I once heard anex-producer from a major gaming publisher talk about her experience with designdocuments and the project approval process She said that the “decision-makers”would bring a scale to their “green-light” meetings When it came down to two sim-ilar projects that were both relatively worthy of funding, they would take the designdocument for each project and place it on the scale Whichever one weighed morewould get accepted, the other rejected Much as it pains me to tell you, if you are inthe commercial gaming business and groveling for dollars at publishers, you need tomake your document hefty You need it to be impressive to pick up and flip through.Many will never read it at all Others will read only the Overview and Table of Con-tents at the beginning But everyone will pick it up and remark on its weight

Of course, many of these super-thick documents contain a lot of information ofnegligible value toward the actual development of the project They may be a stel-lar example of one of the failed types of documents I discussed earlier, such as aBack-Story Tome or an Overkill Document It is your challenge as the gamedesigner to make the document as practical as possible by providing only usefulinformation in the document, while making it hefty enough to impress the suits.One might want to include a large number of flowcharts or concept sketches orchoose to use a bigger font, all while not being too obvious Indeed, a great game(though a simplistic one) can have a perfect design document only ten pages long.One wonders how many great, simple games have been cast aside by publisherswho were unimpressed with the mass of their design documents

of contents, and limiting yourself to practical, accomplishable gameplay elementswill help If your team members sample your document and find it to be of superiorquality, they are more likely to return to it for reference when they are actuallyimplementing a given system or working on a particular piece of art As with anywritten document, you need to earn the trust of your readers if you hope to keepthem reading

Another key method of getting your design document read is to make it easilyavailable to anyone who wants to read it Keep it in the same source-control systemthat your team uses for asset management You want your team members to be able

to get the latest version of the design document as easily as they get the latest build

of the game Since you will be constantly revising and updating your document tokeep it up to date with the project (and to prevent it from becoming a FossilizedDocument), source control will be a valuable tool for keeping track of the previousrevisions

When you check in the latest version of the document, send your team ane-mail telling them that it is available and explaining what has changed That way,people can easily skim over the changes If one of the changes is relevant to theirwork, then they can get the latest version of the document off the network and readover the relevant updates Updating your document does not do any good if no oneknows you have updated it, or if people are still reading old revisions It is probably

a good idea to use a version number with your document, such as 1.3 or 2.7

Include this version number, along with the date, in a header on every page Oftenpeople will print out a design document and not realize how old or fossilized it is Ifthey can quickly compare a date and a version number, they will know which ver-sion of the document they have and whether they need to get a new one

Documentation is Only the Beginning

Some designers seem to think that a thorough design document is, by itself, enough

to build a game It also seems to be the case that companies have bought designdocuments from designers, with those designers moving on to write other designdocuments while another team actually executes their design A design document is

a rough outline, more the suggestion of a game than anything else, and withoutbeing involved in a game’s creation until it goes gold master, one cannot truly beconsidered to have designed the game A designer who takes any pride in his workwill want to be there throughout the project, ready to change the design as necessary

to make it the most compelling game possible and updating the document as thedesign is changed and revised (and rest assured it will be continuously changed andrevised) A committed game designer will want to be there to balance the weapons,the AI, the controls, and certainly the levels, to make sure the game follows thefocus through and the initial vision is realized

If a designer writes a design document and then passes it on to others to ally build, the people who do the actual creation will change the design to matchtheir own interests and artistic drives The design document will be a springboardfor their own act of creation, not the original designer’s The design document is anintegral part of the game’s creation, perhaps, but a design document is not all that isrequired To claim any sort of meaningful authorship on the project, a designer

needs to be involved for the duration In a way, writing the design document is theeasy part of computer game design Actually taking the document and creating acompelling gaming experience is much, much harder.

finds in the world of computer games But the game industry has had to

do without Mechner for several periods of time while he pursued hisother great love, filmmaking Indeed, it is Mechner’s knowledge of filmthat has helped to contribute to the quality of his games But this qualitydoes not come through the epic cut-scenes and barely interactive gamemechanics that so often come about when developers attempt to mergefilm and gaming Instead, Mechner has blended film and game tech-niques in unique and innovative ways, helping his titles to tell storiesvisually while still retaining the qualities that make them great games

346

This interview was originally conducted around the release of The Last Express for Inside Mac Games magazine For inclusion in this book,

Mechner was kind enough to fill out the interview a bit, expanding it tocover the full breadth of his fifteen years in computer game development

What initially attracted you to computer games?

Well, it was 1979, and I was a sophomore in high school The first computerthat I ever got a chance to play with was the PDP-11 that we had in our high school.But it was very hard to get any time on it, and the teacher who was in charge

wouldn’t let the students read the manuals, for fear that would give us the ability to

go in and change grades and stuff like that So it was this guessing game of trying tolearn how to get the computer to do anything So when a friend of mine showed mehis new Apple II, it was just like a dream come true, to have a computer in yourown house that you could use whenever you wanted And it was completely open;you could pop open the top and see how it was made and you could read all themanuals that came with it And of course, the irony was that at that time I didn’tknow of any manuals that explained assembly language So I was just kind of look-ing through the assembly code of the computer’s operating system to try to figureout what the different commands meant Over the years I picked that up, and morebooks came out It was just this great toy

Did you always want to make games with the computer?

Well, I guess games were the only kind of software that I knew They were theonly kind that I enjoyed At that time, I didn’t really see any use for a word proces-sor or a spreadsheet I played all the games that I could find, and in my spare time Itried to write games of my own That was just the first use that occurred to me

So that was the origin of Karateka?

It took a few years to get there The first really ambitious project I did was a

game called Asteroids That was my attempt to do for Asteroids what a game called Apple Invaders had done for the other most popular coin-op game of the time I fig- ured that if Apple Invaders was a big hit because it was exactly like the coin-op game, then I could do the same thing for Asteroids But my timing was a little off I actually finished an assembly language, high-resolution version of Asteroids and

signed a deal with a publisher But just about then Atari woke up to the fact thatthese computer games were ripping off its hugely profitable arcade franchises, so

their lawyers scared everybody off and that Asteroids game was never published.

So then you did Karateka?

No, then I did a game that bore a strong resemblance to Asteroids except that

instead of rocks you had brightly colored bouncing balls, and instead of wrapping

around the edge of the screen they bounced off, hence its name: Deathbounce I sent

it to Broderbund (this was 1982, I was a freshman in college) and got a call backfrom Doug Carlston, who was at the time handling submissions as well as runningthe company I was very excited to get a call from someone in the computer gamesindustry He said, “It looks like it’s well programmed, we’re impressed with thesmoothness of the animation and so on But it feels kind of old-fashioned Take a

look at our new game, Choplifter.” Doug was kind enough to send me a copy of Dan Gorlin’s Choplifter, which was the number one selling game at the time, along

with a joystick to play it with That was the game that really woke me up to the ideathat I didn’t have to copy someone else’s arcade games, I was allowed to design myown!

Karateka came

out of a lot of ideasall kind of converg-ing at the same time

Choplifter showed

me what was possible

in terms of smoothscrolling and an orig-inal game design

Meanwhile, I wasgetting megadoses ofexposure to cinema;

Yale had about adozen film societiesand I was trying to

see in four years every film ever made Seven Samurai was my new favorite film of

all time My mom at that time was heavily into karate, and I had taken a few lessonsduring the summer down at the local dojo Finally, I was taking film studies classes(always dangerous) and starting to get delusions of grandeur that computer gameswere in the infancy of a new art form, like cartoon animation in the ’20s or film in

the 1900s So all those sources of inspiration got rolled into Karateka What made

the big difference was using a Super 8 camera to film my karate teacher goingthrough the moves, and tracing them frame by frame on a Moviola It was

rotoscoping, the same trick that Disney had used for Snow White back in the ’30s.

That made the animation look a lot better than I could have done by hand and better

than the other games that were out there I worked on Karateka for a couple of years

between classes, and sent it to Broderbund at about the end of my sophomore year.They were pleased and published it

Karateka

Team-Fly®

So one of your goals was to merge cinematic techniques with an action game to create a unique hybrid?

Very definitely The accelerating cross-cutting to create suspense had been used

by D.W Griffith in 1915; I figured it should be tried in a computer game The

hori-zontal wipe for transition between scenes I lifted from Seven Samurai The scrolling

text prologue at the beginning And silly things, like saying THE END instead ofGAME OVER I used the few techniques that I could figure out how to pull off inhi-res graphics on an Apple II

Karateka’s actually quite short Was that a deliberate decision, to keep the game

focused?

Well, it didn’t seem short to me at the time Actually, when I submitted it toBroderbund it only had one level: you’d enter the palace and have the fight One ofthe first things they suggested to me was to have three different levels: you’re out-side, you’re in the palace, then you’re down below I wasn’t thinking in terms ofhours of play, I just wanted to make it cool

The ending is a pretty devious trick, where if the player approaches the princess

in the “attack” stance she’ll kick him How did you come up with that?

It seemed like a

fun little trick You

only have one life in

that game: you get as

far as you can, and if

you’re killed, it’s

“The End” and you

have to start the

movie from the

beginning again So I

figured that most

players, when they

finally got to the end,

would just run right

into her arms But it’s

not a total cheat,

there’s a little clue there, where she puts her arms out to you, and then if you runtowards her she lowers her arms So that’s a sign that something’s not right

Karateka

But I don’t know that anybody ever played that game and did it right the first time.

Yeah, in retrospect that was pretty nasty I don’t know if we could get away with

that today The other thing that we got away with on Karateka was that if you

played the flip side of the disk, if you put the disk in upside down, the game playsupside down I was hoping at least a few people would call Broderbund tech supportand say, “The screen is upside down, I think something’s wrong with my monitor or

my computer.” That way the tech support person could have the sublime joy of ing, “Oh, you probably put the disk in upside down.” And the customer wouldhappily hang up thinking this was true of all computer software I thought it wasextremely brave of the publisher to increase the cost of goods by twenty-five centsjust for a gag

say-So did Prince of Persia grow out of your experiences on Karateka?

Well, there was a big gap between Karateka and Prince of Persia in terms of

my own life I finished school and I took a year off I wasn’t sure that I wanted to doanother computer game The most direct inspiration there was a game by Ed Hobbs

called The Castles of Doctor Creep, which didn’t get too big a circulation, probably

because it was only available on the Commodore 64 My college dorm mates and Ispent a lot of hours playing that game It had these ingenious puzzles of the RubeGoldberg sort, where you hit one switch and that opens a gate but closes another

gate, and so forth So the one-sentence idea for Prince of Persia was to do a game that combined the ingenuity of The Castles of Doctor Creep with the smooth anima- tion of Karateka So when you ran and jumped you weren’t just a little sprite flying

through the air, your character actually felt like it had weight and mass, and whenyou fell on the spikes it felt like it really hurt

Another inspiration was the first eight minutes of Raiders of the Lost Ark I

wanted to make a game with that kind of action feeling to it And then there was the

Arabian Nights setting I was looking for a setting that hadn’t been done to death in

computer games, and a couple of animators at Broderbund, Gene Portwood and

Lauren Elliot, suggested this one I went back and reread the Arabian Nights and it

seemed to offer a lot of promise It had all those great story possibilities which havebeen absorbed into our collective unconscious—genies, the voyages of Sinbad,Aladdin’s cave It was just crying out to be made as a computer game

You said you had taken some time off before making Prince of Persia What

finally made you want to come back and do another game?

That was the year I wrote my first film screenplay It was optioned by Larry

Turman, a very nice man who had produced about fifty films including The ate We had a year of meetings with directors and studios and came close to getting

Gradu-it made, but in the end Gradu-it didn’t come together Later I found out that for a first-time

screenwriter, that’s

not considered a bad

start at all But I’d

been spoiled by

computer games,

and I thought, “My

God, I’ve just spent

six months here in

Los Angeles waiting

for something to

happen, and the film

isn’t even getting

made.” In

compari-son, I knew that if I

finished Prince of

Persia, it would get published So I figured I’d better stick with that At the point

when all this good stuff had started to happen with the screenplay, I was about six

months into Prince of Persia, and I’d put it aside for almost a year to focus on

screenwriting It was pretty scary going back to programming after so much timeoff; I was afraid I wouldn’t be able to remember my own source code But I wentback, picked it up again, and finished it

One thing about Prince of Persia is that it takes this finite amount of game

ele-ments and stretches them out over all of these levels Yet it never gets dull or repetitive How did you manage that?

That was really the challenge of the design It was modular in that there were afinite number of elements that could be recombined in different ways It’s the samething you try to do in a movie You plant a line of dialog or a significant object, andfifteen or thirty minutes later you pay it off in an unexpected way An example in

Prince of Persia would be the loose floors The first time you encounter one it’s a

trap: you have to step over it so you don’t fall Then later on, it reappears, not as atrap but as an escape route: You have to jump and hit the ceiling to discover there’s

a loose ceiling piece that you can knock down from below Later on, you can useone to kill a guard by dropping it on his head, to jam open a pressure plate, or—anew kind of trap—to accidentally break a pressure plate so that you can never open

it again

It was necessary to make Prince of Persia modular because the memory of the

computer was so limited The smooth animation of the character, with so manyintermediate frames and so many moves, was taking up a huge percentage of that64K computer When efficiency is not an issue, you can always add productionvalue to a game by throwing in a completely new environment, or special effect, or

Prince of Persia

enemy, but when you’re literally out of RAM and out of disk space, you have tothink creatively Which in turn forces the player to think creatively There’s a certainelegance to taking an element the player already thinks he’s familiar with, and chal-lenging him to think about it in a different way.

Prince of Persia is really a simple game to control, especially compared to modern

action games Was that a design goal of yours?

Absolutely That was a very strong consideration in both Karateka and Prince

of Persia, and I spent hours trying to figure out how to integrate certain moves.

Should it be up with the joystick, or up with the button? Personally, I have a strongprejudice against games that require me to use more than one or two buttons That’s

a problem, actually, that I have with modern action games By the time I figure outwhether I’m using A, B, X, O, or one of those little buttons down at the bottom ofthe controller pad that you never use except for one special emergency move, I’velost the illusion that it’s me that’s controlling the character

Ideally, youwant to get theplayer so used tohandling the joy-stick and thebuttons that theaction starts feelinglike an extension ofhim or herself Thetrick there, obvi-ously, is that whenyou bring in a newmovement that youhaven’t usedbefore, you wantthe player to somehow already “know” what button or what combination of actions

is going to bring off that move In Prince of Persia there were moves where I

thought, “This would be great, but I don’t have a button for it, so let it go It would

be cool, but it doesn’t help the game overall.” A major constraint was keeping thecontrols simple and consistent

Prince of Persia