Lessons learned from Prince of Persia 3D

I worked on Prince of Persia 3D from the beginning of 1997 to mid 1999 -- first as Assistant Producer, then as Co-Designer, and finally as Lead Designer. It's been billed as everything from "an absolute gem" to "underdone and disappointing". It was a crazy experience, where we went through 2 company acquisitions, did umpteen dog-and-pony shows for previewers, demoed at many trade shows, and endured a 16-hour, 7-day-a-week crunch time that lasted longer than I care to remember. While the game never came out the way I wanted, I did learn a lot, and I hope to get some of that down on paper (or computer screen... whatever) here.

One thing that surprised the whole team about Prince of Persia 3D was the huge range of opinions in the reviews. On the high end, you had IGN with a very kind review, and Gamespot UK who gave it a 9.5 out of 10⁽¹⁾. On the other end, you had CNET's Gamecenter, who reacted to the game as if, upon removing the game from the package, it proceeded to kick their dog, set their office building on fire, and hit on the editors' spouses. Other reviews were somewhere in the middle. But, as is usually the case, I tend to agree most with Gamespot's review of the game. (The brief summary: There's some good stuff in the game; it's a shame it's overshadowed by all the bad stuff.)

And there are some aspects of the game that came out great -- the levels were beautiful, and the charater animation was some of the best I've seen. But in the end, though, I feel the game was a disappointment. And this took a lot out of me, emotionally. When you work two-and-a-half years on something, only to have it come out kinda lame, you start to question your abilities to accomplish anything. Every negative review I saw I took personally⁽²⁾. At some point, I probably blamed every aspect of the project -- from our unforgiving schedule(³), to other people on our team, to, of course, myself. A couple of months after the project shipped, I left the video game business. While part of it was because the walls of the company were pretty much caving in around us (thanks to the shady accounting practices of the Learning Company), I'm sure that if the game had done well, I would still be in the business.

Anyway, enough self-serving violin playing for me. Now that enough time has gone by, I think I can look back at Prince of Persia and at least share what I learned in a mostly objective point of view. Many of these things seem like common sense -- but the fact that we somehow missed them should be a warning to anybody else working on a game. There were a lot of very talented people on the team, and while it's tempting to dismiss us as a bunch of boneheads and think, "That won't happen to me!" realize that it probably will.

With that being said, here goes...

1. Work on a game you're interested in yourself.

On the surface, this seems pretty obvious. After all, people join the computer game industry because they like games, and it's generally more fun to be working on a product that you would enjoy using yourself. (If I didn't, I'd probably still be writing database applications for Oracle) If you're interested in a particular type of game, you're going to know the genre inside and out. You're going to have a better sense of what makes it fun. You're going to know what other games have tried, and whether they've worked or not. More importantly, team morale will be hurting at crunch time, and it'll help you out a lot if you can still be enthusiastic about the final product.

Yet this often does not happen. It's a luxury that is generally available to small, independently-funded development teams. For us, anyway, the choice to make Prince of Persia 3D was decided from above. I think it should have been a warning sign to us that very few of the people on the Prince of Persia team had played the original Prince game, and that only one person on the team had actually enjoyed playing Tomb Raider (which had been described by many as Prince of Persia in 3D). Yet we accepted this idea without a lot of fuss. Not because we thought, "This'll be a really fun game," but because we thought, "This will sell well."

So before you take on a project, stop and ask yourself if you're doing it because you want to, or because you think it will sell well. Sure, you've gotta eat, but remember that you're going to be spending many many months on this game. You might as well make it something you'll enjoy.

2. Zombies, Robots, and Animals make great enemies

AI will never be perfect. And it takes quite a bit of work to even make the AI seem even reasonably good. In Prince of Persia 3D, the enemy AI was rather poor when it came to chasing the prince around the world, but in the end I believe that was a proper decision on our part. The game was about navigating a tough environment, not having guys chase you all around the world, and it's important to know where to spend your engineering time. Plus, we've got a world that, by its very nature, is designed to be difficult to navigate. If a human player needs to use all their ingenuity and reflexes to get around the world, how could we expect a computer opponent to do the same?

However, this does not negate the fact that the enemies in POP 3D look like idiots. They stay in their little rooms and don't chase the prince beyond their invisible "boundary that I'm supposed to stay in" area. But our mistake was not in making them too dumb -- our mistake was in making them too human.

People interpret what they see in context. If you have a human opponent, people will expect them to do human things. They will expect them to be intelligent, make rational decisions, think and improvise based on their situation. Now, think of a game like Resident Evil. I've seen zombies walk into walls, get stuck behind tables, and do all sorts of brain-dead (heh) things. Yet nobody has ever complained about the AI in Resident Evil. Why? They're zombies! Nobody expects anything more from them -- when was the last time you heard of an intelligent zombie? Similarly, look at Tomb Raider. In the first game, there were few complaints about the animal AI. Yet in Tomb Raider 2, when Core included human opponents, the complaints increased dramatically.

Admittedly, it would be tough to make zombie swordsmen in Prince of Persia. But if I had a chance to do the story again, I would have made the bad guy an evil sorcerer who conjured up an army of wooden golems or animated statues to do battle with the Prince. Nobody expects much out of wooden golems.

3. Remember your audience

This is another "duh" point, but one that we certainly forgot. It's a simple fact of nature that we make things to impress our peers. Artists want to create work that impresses other artists. Programmers want to create things that impress other programmers. And designers want to do things that will impress other designers. Of course, the majority of our customers art not artists, programmers, or designers, and we forgot about that.

I feel one of our big mistakes in Prince was that we made too many sacrifices in control for the sake of making him look real. For instance, almost every 3D action game includes something called a "wall slide" -- when you're running into a wall at an angle, your character will continue to run and slide along the wall, making it easy to navigate through smaller rooms -- the drawback is that your character's feet generally slide along the ground when you do this. We didn't include a wall slide, because many people on the team believed that making the Prince's feet slide along the ground would destroy the sense of realistic movement. So when the Prince ran into a wall, he stopped. And while this saved the animation, it made it extremely frustrating to navigate through hallways (as one reviewer put it, "The Prince must be wearing a suit of velcro because he sticks to everything he runs into").

Granted, to some degree, this was a necessary evil. Prince of Persia had a legacy of realistic animation, and we had to deliver on that. But I think there was also some personal pride involved there - we wanted to show everybody that we had the most realistic moving character in a videogame ever. It's a worthy goal, but nobody really stopped to think that our customers would gladly give up a realistic character in exchange for being able to control him a little better. Along the same lines, we tried to make our cameras behave in more dramatic ways to impress our fellow movie-buff friends, without really thinking that our customers just wanted a plain, boring, camera that let you see what was in front of the guy.

Indeed once the reviews came out, very few of them even mentioned the animation. But they almost unanimously complained about the control scheme.

Of course, this is said with perfect 20/20 hindsight after reading lots of reviews and realizing that nobody really cared about the animation nearly as much as they cared about being able to control the Prince like the Quake guy. While developing the game, we misjudged our customers, assuming that they would be willing to make more concessions in order to get better animation or more dramatic camera angles. If we had known otherwise, we could have changed the game accordingly. Which leads us to our next point…

4. Don't neglect the user testing

It's hard to create time for user testing. You don't want to show the game too early (whether internally or externally), because you're afraid in such a primitive state, it will create bad buzz. Not to mention the fact that you need a minimum of functionality working just so a player can play through a level. And later on, when you're in crunch mode, the time set aside for user testing is usually the first to get chopped in favor of things like finishing the game.

With that being said, I wish we had done a whole lot more user testing. Not just QA checking for bugs, but honest-to-goodness usability testing. Regardless of how bad the game might look early on, it's important to get some user testing in, because that's the time it's easiest to make changes. And don't just rely on the opinions of people within the company - it's like asking your friends if they like your haircut. They're inclined to like it from the beginning, even if they would hate it on a total stranger.

5. Present the story in an inexpensive format

Take a game, any game, that has an excellent story, and you'll find that in 95% of the cases, the story was presented in an inexpensive manner.

For example, let's look at Starcraft. While the game had several expensive fully-rendered cutscenes throughout, the vast majority of the story was presented through "Mission Briefings" - these mission briefings consisted of a little visual conference call as people appeared in television windows and had much plot-heavy dialogue. The great thing was that this came almost for free - the animations were simple looping ambient or talking animations that could be re-used for each mission briefing. The only new asset needed was the recorded dialogue. System Shock 2 presented much of their story in terms of Email. All you needed was a little portrait of the author, and a voice recording of their speech. They managed to include dozens of little subplots and breathe a lot of life into their story for very little cost.

I think if I had to do Prince over again, one of the first things I'd do would be to present the plot in a totally different way - maybe have one high-quality intro cutscene, but create all the plot-heavy points in a less asset-intensive fashion. Whether that's in the form of a book with illustrations, a voice-over with occasional images in a crystal ball, or (as is quite common these days) in-game cutscenes. Then we could write a much more interesting plot with more color and intricate details, and we wouldn't be paying thousands of dollars per second of story.

6. Put off voice acting and localization as long as humanly possible

When we released Prince of Persia 3D, the company decided (for various financial reasons that I didn't really understand) to release the game in several different countries all at once. This meant that all the in-game dialogue and all the in-game text (such as menus) had to be finished long before the shipping date so that our international people had enough time to localize it in several different languages.

This was a real pain in the butt. It was only when we were close to shipping that we realized we needed hints or additional verbal cues to help the player -- especially in the beginning levels. At that point, it was too late, because we had already recorded the dialogue and the localization people would have killed us if we had changed anything.

So if you find you're working on a game -- especially one with a strong adventure element -- that requires voice actors (and most of 'em do these days), try to find talent that you can easily call back for a second round. And fight those localization people as much as you can. You'll be glad you did.

7. "If I give up being effective in order to be liked, I'll be neither"

I think I messed up the exact working of the quote, but you get the idea. We all want to be loved. Is that so wrong? Well, it is, sometimes. I think one of my weaknesses is that I was still kinda new as a designer and, as such, wanted the approval of my team members. That would have been okay, except that my need to be liked often made me back down from a disagreement when I should have stood my ground.

Of course, there's a fine line between standing your ground when you believe in something and being stubborn. There were some really bad ideas I was talked out of, and I'm glad I was. You should always question yourself and make sure you're not just saying you're right in order to save face. But if you believe you're right, don't back down. Maybe if I had stuck to my guns, we might have had a Prince you could actually control.

8. Get members of the development team to play the game, whether they want to or not.

Seems like an obvious one, doesn't it? But it's not. I think one of the most painful moments working on this game was, one day before we were supposed to ship, we made everybody on the development team test a level. As we're starting up the game, I hear one of the guys on our team call out, "Which key is the jump key?"

This killed me. I don't care how you have to enforce it (see point 7 - it's okay to be a jerk), but make sure everybody on the development team plays the game. And without cheat codes.

For one thing, it's free (although biased) game-testing. For another, you're working with a bunch of smart people. They may easily find solutions to a problem that you hadn't thought of - especially if they have the ability to change it themselves. You could spend an hour explaining to an artist or programmer why you need something changed. But it's so much nicer to have them realize the problem and come up with a (better) solution themselves.

9. Keep the design documentation up-to-date

This was an area I know I fell behind in. And it's a vicious cycle in many ways - the documentation gets out-of-date, so people stop reading it, so you stop updating it because people don't read it. Then you spend lots of time fielding questions or helping everybody because the documentation is out of date, which means that you never have time to update the documentation. In any case, if there's ever a time to get yourself an assistant, it's when you find yourself in this situation.

Incidentally, I generally found that I was better off with several smaller design documents than one large one. It certainly seems less imposing to deal with a small document on a specific subject than a giant tome containing every piece of dialogue, level description, or sound.

Oh, yeah, also update your version numbers and include a history section, so people don't have to re-read the entire document in order to find out what's changed.

10. Include a hook

This is a Dave Perry idea, and I happen to think this is a pretty good one. When your typical gaming magazine is previewing a product, they want to like your game. (When was the last time you saw a negative preview?) But they need something to latch on to and write about in their previews. You can't just tell them the attention-to-detail or the AI or the play-balancing is going to be better; everybody says that. They need something different; a hook. Whether this is actually an integral part of the game or not doesn't matter. (If you've been playing games a while, you remember the hoopla about the "flies around the dead body" in Quake 2. Or, for that matter, the curved surfaces in Quake 3.) It at least gives people some starting point from which they can get excited about your game.

11. Experience is a good thing.

I think we did a lot of reinventing-the-wheel when we set out to create Prince of Persia 3D. Almost everything -- from level design, to character movement and animation, to AI, to optimizing geometry so it would display fast -- was done from scratch. We really hadn't done anything in the realm of a 3D action game before, and when you stop and think about it, it's pretty amazing we had finished this game at all.

Yet we did spend a lot of time figuring out things other companies had already tackled years ago. And I think it would have helped us out a lot if we had hired somebody who had done some of this before. (We did eventually hire on a programmer with some 3D knowledge who helped optimize our graphics engine. Unfortunately, we did it a little too late in the process and some of his most ambitious work never made it in.) Granted, this was the time when dot-com fever was at an all-time high, and it was hard enough keeping the guys we had, much less recruiting new people. But while I thought it was a great rush being lead designer on the project, I might have been happier (or at least much less of a stress case) if I had started off my designing career playing second fiddle to somebody like Brian Raffel.

The bright side, though, is that we did get a lot of experience. I remember our lead animator talking about going down to another development company who was working on a similar title and how he was immediately able to help them out. Most of the guys on the Prince team have gone on to other computer game companies and I'm sure are having an easier time of it with the knowledge we gained on the project. I just wish we could have picked up some of that knowledge from other people.

12. Accept the fact that you might not have a hit

There was an interesting article on Slashdot a while back about why being a computer game developer sucks. While I didn't agree with all of it, there was one paragraph that hit home.

The economic realities of developing games induces what I call "The Lottery Mentality"... In the games industry, this takes the form of lying to ourselves about the potential chances of creating a "hit" game. We all know that our game has only a small chance of becoming a hit and thereby making a profit, yet we fool ourselves into thinking: "Yes, but MY game is going to be the ONE". As one producer put it: "You don't think anyone intentionally tries to make a mediocre game?" ... But the fact is that your game is almost certainly going to be mediocre, in sales if not in quality, whether you like it or not.

I think we were guilty of the Lottery Mentality. (Or, at least, I was.) Which is why it was such a bummer to end up with a game that wasn't the ONE. While it's pretty silly to go in with the attitude of "we're going to make an average game!", just be prepared for the fact that it might not happen. That'll cushion the blow if it does come.

I suppose I'm just trying to mirror the point I made back at the introduction. We were a team of smart people who were trying quite hard to make a good game -- we just made some mistakes along the way that really hurt us. This could just as easily happen to you. So don't say I didn't warn you.

Update! Last year, UbiSoft published Prince of Persia: The Sands of Time. I've played it and, all-in-all, it's a really well-done game. Really, my only complaint about the game is that it came out the same time as Beyond Good and Evil, banishing that game into the bittersweet category of "Great games that nobody played."

I will note, though, that all the enemies in Sands of Time are Sand Zombies. Now, maybe that was a coincidence, but I'm kinda hoping that maybe somebody at UbiSoft read this article.

⁽¹⁾Generally speaking, Europeans liked the game more than Americans. (As I like to point out, it was the #1 selling game in Holland) Our theory was that Europeans are more into adventure games than Americans, and therefore might be more patient with a less responsive main character than Americans, who expect Quake-like twitchiness.

⁽²⁾Of course, this works both ways. If the game had been a hit, you can guarantee that it would have gone to my head and I would be a pompous ass.

⁽³⁾ I remember when our producer got yelled at by higher-ups for shipping the game one day late. His reason? You couldn't actually play the game beginning to end. And he got yelled at because he decided the game couldn't ship this way.