Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Indigo Prophecy
View All     RSS
September 22, 2019
arrowPress Releases
September 22, 2019
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Indigo Prophecy


June 20, 2006 Article Start Previous Page 2 of 4 Next
 

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.

 


Article Start Previous Page 2 of 4 Next

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States
[09.20.19]

Sr. Project Manager
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[09.19.19]

Producer
Sony Pictures Entertainment
Sony Pictures Entertainment — Culver City, California, United States
[09.19.19]

Sr. Product Manager, Mobile Games
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[09.17.19]

Experienced Game Developer





Loading Comments

loader image