Omikron Game: Postmortem: Indigo Prophecy

Postmortem: Indigo Prophecy

[Published in edited form in the June/July issue of sister magazine Game Developer with magazine-exclusive concept art, Gamasutra is proud to present the full, extended postmortem for Quantic Dream's fascinating Indigo Prophecy/Fahrenheit, as described by creator David Cage.]

Introduction

Working on an original project is both the worst curse and the most exciting thing that can happen in this industry. It's a curse because you go through periods of terrifying doubt. For two years you abandon all notions of a private life and forgo many hours of sleep because you are permanently looking for the right path, being simultaneously haunted by the idea that you may be completely mistaken and may be taking enormous risks.

It's also a fascinating experience because an original project allows you to construct your own vision, to test your convictions on the ground, to experience an extraordinary professional and human adventure with a team, with all the alternating periods of torment and euphoria that this implies.

Indigo Prophecy was all of that. This adventure taught me an enormous amount of things by forcing me to think about my vision of the future of this medium and how to make it evolve, sometimes by remaining true to its still-young traditions and sometimes by breaking away from them.

To sum up such a rich and intense experience in just a few pages by dividing it between positive and negative is a challenge that is almost impossible to meet. If I nonetheless try to do so, it is first of all because I have a special affinity for the impossible and also because I imagine that others may be able to learn from this experience with its share of successes and errors.

What Went Right

1: The Story - Playing with Archetypes

The writing of the scenario itself required a considerable amount of work (the final game design ran to more than 2000 pages…) and it was very well received (except for the end of the story, a point I will soon get back to).

Creating Empathy

My main aim was to write a story that would be capable of "absorbing" the players into the experience, making sure they kept a firm grip on the controller until they knew what was going to happen. The story thus became the driving force of the experience, both the main motivation inciting the player to play and the reward for playing.

I deliberately chose simple and popular starting points: an American city today, an ordinary man who finds himself confronted with extraordinary events, a series of unexplained murders. It seemed to be essential for the story to be easily and immediately accessible, without any need for explanations.

Characterization was my second priority. Initially I set out to create strong empathy with the main character without the players even realizing it was happening.

The idea of the hero being a murderer in spite of himself generates spontaneous sympathy in the player. The stress situation imposed from the very beginning immediately plunges the player into the story and simultaneously making him Lucas Kane's accomplice (I had to fight hard with the Marketing Department, convinced that the player would not feel any empathy for a murderer, which proved to be wrong as it turned out. The narration enabled us to get over this difficulty without any problem).

But I still had to convince the player to take an equally rapid interest in the other characters (apart from Lucas Kane, the player could also control the two other main protagonists, police officers Carla Valenti and Tyler Miles). My goal was obviously for the player to have no "favorite" character, but to be equally pleased each time he encountered them.

I chose to use classic archetypes in order to work on my characters: Carla is a tough young police officer but discreetly sexy, totally immersed in her work to compensate for the lack of any emotional life. Tyler Miles is a cool young black cop who is sincerely attached to Carla, full of humor but serious in his work.

Many other secondary characters followed the same rule, the gruff police captain, the still-in-love ex-girlfriend, etc. All these simple characterization elements enabled us to present the characters very quickly while giving the player the impression he has always known them.

The danger with archetypes is that you have to avoid caricature (I hope I succeeded), otherwise the story loses all credibility and the player loses all interest. Most of my work on characterization consisted in enriching the initial archetypes in order to give them some real depth. Lucas Kane has self-doubts and has a complex relationship with his brother, a priest. Carla suffers from claustrophobia and chronic anxiety. Torn between his strong sense of duty and his love for his girlfriend, Tyler is involved in a complex relationship.

I also presented the main characters in their personal lives to give an idea of their context and emotional relationships. This aspect of the writing enabled us to quickly give them an added dimension: the player could see them operating in the context of the story, but he could also discover their private and personal lives, which helped contribute to the illusion that they actually exist.

Thanks to these simple techniques the player quickly feels close enough to the characters to share their feelings on an emotional level.

Bending Stories

Among the writing techniques that I developed for Indigo Prophecy, Bending Stories definitely received the most attention from the press. The basic idea was to solve the classic difficulty of telling a truly interactive story without generating an excessively complex tree structure. I had to find a way to enable the player to make significant choices with consequences while still maintaining the quality and pace of the story, as well as feasibility in terms of production.

The idea of Bending Stories consists in considering the story as a sort of elastic band that the player is free to stretch depending on his actions. The story retains its structure but the player can modify its length and form and thus participate in the narration. In reality the story does not change diametrically from one game to the next, all that changes is the way it is told. However, the player can see parts of scenes and obtain different information depending on the particular path he follows.

Another important decision was the option to work with small, closed sets rather than trying to model all of Manhattan. This decision was no doubt the hardest of all to make. However, my choice was based on solid conclusions: above all else I wanted to offer the player a sustained paced, brisk action, short scenes and frequent changes of location and context. The last thing I wanted was to have the player wandering about for hours in sets that had actions every hundred meters.

I therefore decided to opt for smaller, more closed sets but with a higher action ratio per square meter. As it so happened, this decision worked out well.

2: Concepts and Game Design

The Director, the Only Project Head

People often oppose creation and production, creators being supposed to have great ideas but no consideration for production constraints, producers wanting to be on time and on budget but having no interest in quality.

This opposition becomes particularly palpable in an original project, where many unknowns derive from the nature of the concept.

I chose to structure the project around two simple ideas:

- GAME DESIGN RULES! (GDR) (Yes, I love silly acronyms…): it is the experience that dictates what is going to be developed. It is a reasonable and rational dictatorship of the game design in terms of technical choices and artistic direction, based on the initial budget and time constraints.

- THE DIRECTOR IS THE ONLY MASTER ON BOARD AFTER GOD! (DITOMOBAG).
He is the guarantee of the global consistency of the vision. He makes sure all the elements of the game contribute to creating the same emotion. His choices can/must be subjective. They may be debatable when taken individually but it is imperative that they form part of a global vision that is clear and consistent.

The purpose of this organization was to have an "auteur" approach to game creation i.e. to create a context that gives one person full power to express his/her vision. This specifically made it possible to adopt strong-willed stances without constantly seeking compromises at all costs, which would have been disastrous for a project that claims to be innovative.

For me it is fundamental to have the director embodying the vision of the project: it is extremely rare for a truly original game to be developed without the creative vision of one person (from Shadow of the Colossus by Takeshi Ueda to Psychonauts by Tim Shafer or Killer 7 by Gouichi Suda, or also Metal Gear Solid by Hideo Kojima).

For me this is going to be a strong trend in the industry in the years to come, making it necessary to question a certain number of preconceived ideas.

Reconciling Narration and Interaction

One of the key points in Indigo Prophecy was the idea of getting interactivity and narration to work together. Most games oppose these two concepts or rather, they develop them in turn: a cut scene to advance the narration, then an action scene, then another cut scene for the narration. The structure of this narrative process is very close to that of porn movies.

The greater part of my work consisted in reconciling these two, first of all by eliminating the dichotomy from the design. More often than not a game is designed by a game designer who establishes the game play mechanics. A screenwriter is then called in to find a story to make the link between the levels.

More than anything else I wanted to break with this logic by designing the story and the interactivity simultaneously. My aim was to allow the player to "play" the story, to enable it to progress directly through player actions rather than jumping from cut scene to cut scene.

It was very difficult to find a solution to this problem, particularly because it demanded that each scene contain an interesting proposition in terms of the scenario and game play.

One scene in particular was a veritable revelation for me, the one where Tyler wakes up in his apartment at the start of the game. The player shares in Tyler's personal life in the morning before he goes to work: showering, getting dressed, drinking coffee, putting on some music, having a serious discussion with his wife, then kissing her before taking his coat and setting out for work.

When I wrote the scene on paper I spent whole nights in a cold sweat: what was the player going to play in the scene? Where were the mechanics, why should such a scene have even the slightest interest in terms of game play?

After months of soul searching I was very surprised when I finally saw the scene assembled, with dialog, animation, music and directing. And to my great surprise, the scene worked. It wasn't based on the traditional mechanics of video games (objective, obstacle, ramping, reward) but on something else that I still find hard to define.

I believe the scene is based entirely on the interest of sharing in the character's personal life, developing an attachment for him, becoming slowly immersed in his story.

In my opinion this is one of the most interesting scenes in Indigo Prophecy. No stunts, no artifice, just "being" a character in a simple context.

That scene finally convinced me that it is possible to create an interesting experience without weapons or cars.

Getting Rid of Patterns

The unnecessary character of game play mechanics was also a great discovery for me. Most video games are based on a series of patterns that the player has to acquire in a certain order in accordance with a certain timing and over different levels (e.g. press at the right time the right button to shoot, run, jump, move about, etc.).

The logic of patterns is totally opposed to the notion of narration, which evolves and is therefore non-cyclical by its very nature. It is therefore essential to abolish the rule of patterns in order to tell a story.

Of course Indigo Prophecy is not totally devoid of all patterns. The action sequences are a classic example of patterns and certain game play gimmicks also reappear regularly in the game. But generally speaking, the narration is based on a structure and a mode of interaction that is essentially contextual or, to be more precise, driven by the story.

In one scene Lucas has to hide evidence while in a split screen he can see a police officer knocking at his door. In another scene he explores the scene of the crime by alternating between Carla and Tyler. In yet another he will have to combine the actions of three characters in real time by switching from one to the other. What is the common denominator of all these mechanics? They serve the purposes of the narration, are not repeated at regular intervals and occur only once in the game.

Pacing/ Structure of Scenes

For me the pacing of the experience was an essential element in a game based on the narration. I had to avoid a slow and laborious narration at all costs and give priority to changes in pace, climaxes, and dynamics. I also had to rethink the adventure format in order to adapt it to consoles.

Two elements were essential in this respect. The first was to structure my scenes differently. I wanted short scenes that followed each other in quick succession so that the player would not have the time to get bored. Sets, characters and situations had to change quickly in order to kick-start the narration regularly, exactly like editing a film.

Each scene was structured as a mini film with a "hook" (to get the player immediately into the scene), two climaxes with increasing dramatic intensity and an epilogue.

We can see this structure in the very opening scene with Lucas in the Diner: the murder constitutes the hook, the climaxes are the waitress' call or the police officer standing up (depending on the player's actions), the scene concludes with Lucas' departure. The scene is a mini story in itself.

The player could thus turn on the console to play for ten minutes and have a satisfying experience, whereas most narrative games necessitate considerably more continuous investment before they provide satisfaction. This structure provided a sustained pace and very considerably contributed to the impression of fluidity that the game gives.

The other decisive element was the increased number of pace changes. Generally, I left relatively few scenes in free time. I did not want the player to wander about for hours in a set and thereby destroy the pacing of the narration (thus the quality of the experience). This is why there are many events in each scene to break the pace.

I tried to multiply the situations where the phone rings, someone enters or an unexpected event takes place, in order to set the pace, but also because they create the illusion that the other characters really exist and behave in their own right.

Interface

The interface was also the subject of intense reflection all through the project. My first intention was not to turn it into a remote control as often happens in adventure games, nor an exercise in skill but rather a tool for immersing the player physically in the world.

The idea of MPAR (Motion Physical Action Reaction, did I tell you about my silly acronyms?) developed quite naturally. It consists in offering the player the possibility of accomplishing the same movement with the right analog stick as the character on the screen. The system enabled us to unfold the animation progressively, providing a feeling something close to Inverse Kinetic but without the disadvantages. The system also had the enormous advantage of being easily contextual, enabling us to use the same interface to take an object, open a door, have a drink or play yoyo.

The principle of MPAR then governed all of my reasoning with regard to the interface. With the help of the controller I wanted the player to physically feel the same thing as the character. The Track&Field interface (derived from the eponymous game) applies the same principle: as soon as an action requires force or endurance, we ask him to tire himself out alternately on the triggers. The bodybuilding scene is a fairly good illustration of this principle, with the player suffering alongside the character in order to finish the series.

The conclusion of this work on the interface was that we could create real physical immersion thanks to the interface. More than just a control mode, it becomes the physical link between the player and the experience.

After a few minutes' play most players have completely forgotten the existence of the interface because it is simple and intrudes minimally on the screen, allowing them to concentrate solely on the story and the characters.

3: Iterations Under Control: Be Ready to Change the Plan

First Goal: Make the Plan

It is a nearly impossible challenge to preserve one's initial vision over two years of development and an incommensurable number of difficulties of all sorts. It is absolutely essential to protect what constitutes the essence of the project without being sidetracked by the innumerable unforeseeable factors of development.

I always have very detailed and complete game designs before I begin production. The way the game operates is described on paper in the smallest detail and overall the final result differs quite little from the initial document.

I tried to have a maximum number of certainties on paper before starting production, particularly so that asset development could start on healthy bases. I also needed them in order to be sure that I would not run up against a brick wall in the middle of the development.

For the aspects that caused me to have doubts or questions I worked on setting up a functional solution while allowing for some iterations in the course of development. They related very largely to playability aspects or the interface, for which it was difficult to make decisions without having progressed with the development.

This approach proved to be particularly effective for this type of project: it enabled me to have a solid base while still retaining sufficient flexibility to make discoveries in the course of development without perturbing the production.

Second Goal: Improve the Plan

These iterations took different forms during the development, ranging from methodological research to rewards for perseverance and including accidental discoveries.

MultiView and Mental Health are two of the very rare fundamental ideas of the game that came into being during the development. One morning a member of the team came in with one of the very first episodes of the TV series “24”. The first scene of one of the first episodes hit me straight away: we saw a character using a computer, with a window showing the screen, another showing the worried face of the character, a third showing a general view of the room. I was won over by the idea that we could show the interface and the emotion on the face of the person using it. I also quickly saw the full potential of such an interface for game play, particularly by showing several places at the same time while still leaving the player in control. MultiView was interesting both in terms of narrative and game play, making it a particularly interesting feature for a game like Indigo Prophecy.

Convincing the team to implement it was another story. I have to admit that when I got the idea, the PS2 engine was running at 5 frames/second with a single set. The idea of opening as many as four windows simultaneously seemed to be science fiction at the time, not to mention the loading and memory problems that would necessarily be involved.

At such a stage in development, it is a serious asset if you are both lead designer and CEO at the same time… I decided that MultiView was going to be one of the key features of the game and that it was essential to adapt the game design, the technology and the production in order to accommodate this, which the team accomplished at the cost of much work and an amazing feat of determination and faith in the future.

Mental Health is another example of a feature that appeared in the course of development. My initial stance was that it would not be necessary to integrate life or morale gauges because the player's feeling would be enough. He would feel spontaneously encouraged or demoralized depending on his actions.
When the game was assembled it quickly became apparent to me that this would not be the case and that we would have to materialize the emotional state of the characters in some more concrete form for the player. The addition of this little gauge was finally quite important for the experience of the game by making the psychological state a simple game play mechanic that was perfectly consistent with the narrative aspect.
The decision to implement it was based on the fact that it had few consequences on the development and a significant impact on the experience of the game. The main interest was that all the actions were already present in the initial game design. All we had to do was give them an economy and consequence with Game Over sequences.

The implementation was particularly well scheduled and organized and everything went very smoothly without any glitches.
From a Game Design point of view, this somewhat late implementation gives a slightly superficial result in places. I would no doubt have given it more importance and would have integrated it more profoundly in the game (particularly by giving it more repercussions in the rest of the game) if I had had the idea sooner. But in the end of the day, Mental Health constitutes an interesting mechanic that improved the experience of the game.

The Game as a Living Entity

To conclude, I consider the game during the development phase as a living entity. It must be given solid bases but we must also give it room to breathe and remain on the lookout for discoveries that can happen along the way. Exploring a fascinating pathway that opens up in the middle of development is always a risk that has to be evaluated impartially, particularly in terms of its repercussions for the production. It is always a question of a "vista", even daring, for the project manager who makes the decision, and he cannot afford to make any mistakes in terms of the consequences.

In the case of Indigo Prophecy, I believe this freedom to stay in tune with the project during its development played a fundamental role in determining the final result. It is also no doubt a luxury that not all productions can afford.

4: Vectors of Emotion

The cinematographic approach in Indigo Prophecy was an essential aspect of the game concept from the very beginning. The idea was to manage to recreate a richness and diversity of emotions comparable to film by using similar mechanisms (narration and characterization), but ones that are also peculiar to the medium (interactivity, immersion).

The goal was straight away to use all possible vectors of emotion. Beyond the story itself, the emotional vectors we identified were the virtual actors, the directing and the music.

Virtual Actors & Motion Capture

The work on Virtual Actors was absolutely fundamental to Indigo Prophecy. From a technical point of view, the creation of virtual actors capable of communicating emotion was a veritable challenge. Although the writing would facilitate the task, the characters still had to be technically capable of expressing these emotions.

Motion Capture was an immense aid in this respect. Quantic Dream has its own in-house MoCap studio, without which Indigo Prophecy would probably not have been possible. In addition to the usual technical difficulties linked to MoCap, the main problem I found myself confronted with was how to maintain coherent characterization for each character. For Lucas Kane, for example, several actors were required for the body animation (adventure, body dialogs, stunts), another actor lent his voice and the facial animation was then recorded by a puppeteer. It therefore took eight actors to give life to Lucas. And as their performances were staggered over more than 18 months, my work as a director was essential in order to preserve the coherence of the character throughout the game.

Facial Animation

Work on the face was also extremely complex. I had experimented with different techniques in my previous game OMIKRON-THE NOMAD SOUL, ranging from facial Motion Capture to triggering blendshapes with a midi piano. Given the quantity of dialogs and characters (more than 2h30 for more than 70 different characters) and the level of emotion we were aiming at (entirely mobile faces), we had no choice but to find an appropriate solution.

We finally opted for a system of "digital puppets". A glove is used to capture finger movements and each finger is assigned to a blendshape animation. With two gloves a professional puppeteer could thus dynamically control each blendshape dynamically and in real time, combining and blending them in a fluid and natural manner. He listened to each line twice, then recorded the animation while viewing the result in real time, lip synch and face simultaneously. The system also allows for retakes or to re-record only a part of the face.

Movie Maker Module

The quality of the directing was obviously a crucial aspect of the game. It was essential for us to provide quality comparable to that of a film. We studied different possibilities, cameras created in the modeling tool or by script, finally opting to develop an internal tool called “Movie Maker Module” or “M3”.

M3 is a real time workbench that is integrated into our scripting tool. It offers a system of tracks per type of data (cameras, animation, sound, post-render, FX) with a time line, just like an AVID or PREMIERE workbench. The result can be viewed instantly in the game engine.

The user can not only place cameras but he can also play with the animation or position sounds in order to have real control of the whole scene. The result is a binary file that can then be used by the script at any time.

The main goal was to create a WYSIWYG tool, the principal advantage being its extremely simple and intuitive interface and workflow. The idea was that it required no special technical training to use M3, so the tool was accessible for people having cinematographic training.

The Music

This subject has received ample attention in the past, but this post-mortem would not be complete without mentioning the music as a vector of emotion in Indigo Prophecy. I must admit that it took several unfortunate tries with talented musicians before I found what I was looking for. What I wanted was real film score, a combination of sensitivity and nuance, something that would lend an added dimension to my story.

The work of Angelo Badalamenti, David Lynch's composer since Blue Velvet (he also composed the theme music for Twin Peaks, amongst others), fulfilled my dreams. I asked him to work as if for a real movie, forgetting the fact that it was a video game. We gave him a script, visuals, a very detailed description of the scenario bible and the characters and I spent a lot of time with him communicating my vision of the story and the feelings I wanted to get across.

We worked by theme for each character, these being played out in accordance with the emotions of the different scenes.

The quality of the emotion Angelo brought to Indigo Prophecy through his music really gave the game an added dimension. Some composers of film scores have experience and talent that are still rare in video games.

Many games think that the music must be based on Carmina Burana or John Williams in order to have its place in a video game. Personally, I am convinced that it can lend a unique quality of sensitivity and emotion that we are still struggling to express graphically.

5: Good Management of the Usually Underestimated Tasks

There is a large quantity of hidden tasks in all development. They seem negligible at the start but often prove to be very considerable at the end of production because they were badly anticipated.

These are few examples of minor tasks that we anticipated correctly:

Localization: It would take a whole book to describe the quantity of various and diverse problems that can arise in badly anticipated localization. After OMIKRON, which was a particularly heavy game in terms of localization, Indigo Prophecy set a new record with nearly three hours of audio dialogs and lip synch, in addition to a considerable quantity of written texts, all translated into six languages, including Japanese. The localization went smoothly, mainly thanks to a good anticipation of the tools (Excel import/export of texts from the dialog and text scripting tool).

Auto-Builders:On a cross-platform containing a considerable quantity of data and six languages, it rapidly became a priority to automatize the builds. All the game data was stored on a central server along with the history and versions for each platform and language. Before leaving at night, a tool was launched to automatically reconstruct the specified version by recuperating the latest validated version of all the game data from the server. In the morning the QA team had a new version of the game for testing.

Intranet: We made a significant investment in our Intranet server in order to be able to deal with a certain number of classic development problems. We specifically integrated the following sections directly accessible from an Internet navigator:
Library: all documents shared by team members, with management of user rights
Shared Scheduling and follow-up of task lists for the whole team
Declaration and follow-up of requested vacations
Bug Report: simple and adapted to our needs, it was used both for the project and for debugging tools.

Synchronized Release of Tools and Technology: When we develop our own technology internally with a considerable R&D team, it is of primordial importance to synchronize the company's multiple tools. If the set exporter supports a new graphical feature but the scripting tool does not yet support this feature, there is a strong chance that it will crash. It is therefore essential to find an adequate solution so that the code is constantly synchronous.

We implemented a very strict discipline while developing Indigo Prophecy. A machine was dedicated to compiling release codes (it compiled automatically as soon as the code was modified and mailed the relevant leads when the code no longer compiled). All tools were released on the same day on the same machine from the same code of the same branch. When the code is effective, all the tools are tested. When they have been validated by QA, they are made accessible to the users who can then update their tools (direct update from the tool).

6: Changing Publishers Can Be Good

Changing publisher in the course of development is usually the worst nightmare imaginable. Indigo Prophecy is a sort of a special case because the developer went to see the publisher to ask to terminate their agreement.

The situation is a major classic for all developers: highly motivated people who really believe in the vision and the product sign a game. These people leave or are fired, but the game stays with the publisher. The fired people are replaced, but everything the previous people signed is necessarily of no interest. The developer can very quickly find himself in a ridiculous situation where he has signed for a game with a publisher who no longer wants it.

Indigo Prophecy had reached an advanced stage of development but no one at the publisher's seemed to understand exactly what we were doing. If I were more cynical I might have rejoiced in the situation, comforting myself that it was too late in the project to kill it, but I was really convinced of the quality of the game and I was scared the game would be released "quietly", with no marketing or promotion. Like any developer who sacrifices two years of his life for something he believes in, I couldn't resign myself to the idea that my game would be released without the necessary marketing backup.

So I went to see the publisher and, convinced of the quality and originality of Indigo Prophecy, I asked them to give me back my game. They were intelligent enough to accept this proposition, which thus enabled us to find a new publisher without any difficulty, one who was happy to acquire a cross-platform project at the Beta stage and just a few months away from the end of development.

Changing publisher was the most positive element in the development of Indigo Prophecy. We suddenly found people who were really enthusiastic about our game, convinced of its quality and who wanted to defend it and talk about it. We started a real collaboration in order to improve the game and streamline the game play. Indigo Prophecy improved considerably during this period, particularly thanks to the new view provided by the publisher, who was very useful in terms of regulating the pacing of the game.

The conclusion of this experience is that it is sometimes beneficial to change partners when you feel that things have ceased to progress. The "big leap" is never easy to make, but it can prove to be salutary for a project.

Next: What went wrong

Autor: David Cage
Source: Gamasutra

Labels: Fahrenheit Indigo Prophecy Developers Diaries

Tuesday, June 20, 2006
<< HOME

HOME : LINKS : ABOUT : RSS