Omikron Game: Postmortem: Indigo Prophecy What Went Wrong

Postmortem: Indigo Prophecy What Went Wrong

1: The Story - The Bad

Generally speaking, the scenario and characterization worked particularly well but a few glitches in the writing prevented the scenario from reaching the level of quality I was aiming for.

Here are some of them in no particular order:

- one bad guy per story is enough: the Oracle was the real enemy in Indigo Prophecy and I think his characterization was quite good. The AI that comes into play at the end of the game only adds confusion to the plot.

- you can make people believe anything in a scenario, but only once per story. In the case of Indigo Prophecy, the story of Lucas, guilty of a murder he never really committed because controlled by the Oracle, was THE unreasonable proposition in my scenario, which the players accepted without difficulty. The series of new developments at the end, although built into the first scene (the crow representing the AI is a leitmotif throughout the game) constituted a series of added propositions that went beyond what the players/spectators could reasonably accept.

- I made the mistake of not devoting enough time to the last hour of the game. I was convinced (and rightly so) that the first hour of the game would be decisive for hooking the player, but I naively thought that one hour from the end the player's opinion would be made. I therefore devoted most of my time to the rest of the game in order to make it as perfect as possible.

This was obviously a mistake. I was forgetting that what leaves a lasting impression on the player is often the end, and that a bad ending can change his perception of the whole game.

It won't happen again…

2: Graphics: "Atmospheric but not Stellar" (as they said…)

The graphical quality of Indigo Prophecy was given an uneven reception by the critics. I think there are three reasons for this:

- Indigo Prophecy was developed simultaneously on three platforms, PS2, Xbox and PC. PS2 had been defined as the lead version and no efforts were spared for this console. The last months of development were devoted to graphically improving the PC and Xbox versions, but too few specific features were developed for these platforms to make these versions competitive with the best games on the market.

- the second reason was a deliberate choice to work on the graphics in terms of atmosphere rather than in terms of a technical demo. In order to create a grim atmosphere by working on the colorimetry and the grain of the image we deliberately avoided easy lens flare and other such env map effects that invade most games. The result probably lacked eye candy.

- the last reason relates to a misevaluation of needs in terms of tools. The graphics team did top quality work but the tools that would have facilitated the graphical production appeared much too late in the production or were not suited to the job. The heaviness of the technology always has direct repercussions for the graphical quality of the game: when a graphic artist spends more time trying to view his work than improving it, the result is a loss of quality.
The burden of having to develop an internal technology on three platforms proved to be too much to afford the artists the comfort they needed.

On our upcoming productions we have devoted a significant effort to developing the graphics and animation tools entirely in pre-production. More specifically, we have greatly extended our WYSIWYG philosophy enabling direct visualization on console in all tools.

3: Action Sequences - Almost A Good Idea...

The action sequences are a good example of a good idea that never came to maturity during the development of the game unlike, say, MPAR and MultiView. Reviews were globally good for this part of the game, which was designed from the very beginning more as a spectacular breath of fresh air in the narration than as a veritable game play challenge. I am personally dissatisfied with the result.

The initial concept was to avoid having repetitive action sequences like most games, where the player accomplishes the same actions (shooting, fighting, driving).
The narrative structure imposed a great variety of actions, animation and situations in order to preserve the cinematographic side of the experience and there was no question of imposing shoot sequences every ten minutes at the risk of totally destroying the narration.

The other important point in the project specifications was that the camera should be free to provide top quality directing (so no views from behind). Finally, there was no question of providing specific interfaces for each new action scene. We therefore had to imagine a generic interface that was equally suited to a chase scene, a game of basketball or ice-skating.

The result was the PAR system (japanese designer experimented something similar with his Quick Time Events in SHENMUE).

The final idea of assigning controls to the analog sticks and bonding them to the movements of the character on the screen came quite late in the development, too late for the appropriate tools to be developed. The implementation was thus very largely blind, and the tuning particularly long and delicate.

In addition, we failed to find an ideal visual representation for the symbols on the screen. We tested a large quantity of positions, sizes, shapes and colors and finally opted for peripheral player vision. It was an interesting option but not entirely convincing, the interface being graphically too invasive. If the player does not use peripheral vision, the eye moves from the symbols to the scene and the interface masks the scene.

A better implementation would have been possible if we had had complete WYSIWYG tools earlier in development.

4: Insufficient Overall Vision for the Technology

The Indigo Prophecy technology is not really spectacular. It was primarily intended to serve the experience of the game and fluidity. Most of its features were designed to improve the game experience.

For example, the game is not burdened by any loading in the course of scenes thanks to an "intelligent" streaming system that enabled the game to offer a particularly large quantity of action per square meter.

The scripting tool we used to assemble the game enabled us to construct extremely complex scenes with a great number of possible variations and a great variety of mechanisms. The MultiView and Multi-Character scenes were veritable technical challenges.

In spite of many positive points, the game suffered globally from an insufficient overall vision for the technology. This placed a considerable burden on the development and demanded not inconsiderable extra efforts that the team could otherwise have avoided.

The first mistake occurred when changing platforms. Developing a PC game is very different from a console game, particularly in terms of memory management, loads and saves. We considerably underestimated the switch from PC to console and failed to identify the difficulties correctly (we quickly focus on the frame rate, whereas the memory and loading issues are considerably more problematic).

The second mistake was an insufficient analysis of the game design. It seemed to be very simple (playing animation in scripts with conditions) whereas it finally proved to require great underlying complexity. Synchronously managing several scripts playing simultaneously in several windows but capable of interacting with each other, as in the Hotel scene, is just one example of the type of cases that had to be managed.
We also underestimated the needs of a game that uses few recurrent mechanics.

The other classic error we committed was trying to develop generic tools with a view to possible future productions rather than tools dedicated to the experience of the game we wanted to create. The initial scripting tool was supposed to enable us to script both an FPS and a tennis game. The reality quickly proved to be different from the theory.

A generic tool enables management of a great variety of cases… but none of them very effectively. The prospect of reusing a tool as is for future productions is usually a pipe dream that costs time and money in the short term with no guarantee of profitability in the long term.

In Indigo Prophecy we realized this early enough to be able to correct the error. We adapted the tool, making it less generic but more effective for the type of game we were developing. With a scripting tool that was better suited to the game, we considerably simplified the scripting and accelerated the development.

The reality of development in the years ahead is that engines will no longer constitute a veritable barrier, and there is a strong chance that all teams will very quickly have access to the same features.

The real technological stakes of Next Gen development are in the tools.

5: Difficulties of Developing an Original Concept

The major difficulty in Indigo Prophecy was being able convince before, during and after the development, publishers, the team, the marketing, the journalists and finally the gamers.

Convincing a Publisher

The difficulties inherent in an original project begin even before it goes into development with the incredibly difficult task of convincing a publisher.
Indigo Prophecy was no exception to this rule.

I often say that a truly original project cannot be signed by a publisher except if based on a misunderstanding, because if the publisher really understood what he was signing, he would never sign it.

The initial presentation of Indigo Prophecy was capable of terrifying even the most foolhardy of publishers (and these are few on the ground…). The challenge of the project was to create an experience in which the player would control the main protagonists of a story in which his choices would modify the course of events. No gun, no car, no action, no puzzle…

The first publishers I spoke with took me at best for a harmless dreamer, at worst for a madman. The publisher's first reaction when evaluating a new project is to look at the sales figures for games in the same category. In my case, he either considered that the game was a new genre, therefore having no comparable reference, or else that it belonged in the category of adventure games, an economically minor genre. Clearly not a good omen for Indigo Prophecy…

The other difficulty I ran up against was trying to explain the experience that Indigo Prophecy was going to be. Even today I still find it difficult if not impossible to explain what the game is like to someone who hasn't played it. The dialog inevitably ends with the person looking at me with a puzzled expression accompanied by a polite smile.
Because it really is impossible to explain Indigo Prophecy (you can make the test yourself…).

In an action game you can explain how to shoot, what weapons are used, who the enemies are, and everyone immediately understands the type of experience it is going to be.

With Indigo Prophecy, no one can see right away how the player can enjoy playing with only a story and choices.

Explaining the concept of an original game with no real prior references is a major difficulty that must not be underestimated. I had to deploy considerable efforts before I finally managed to generate enough excitement to sign for the project, after spending more than a year discussing it with the publisher.

Convincing During Production

Developing an original project also constitutes a mass of difficulties at all levels of production. Apart from the initial difficulty of convincing the publisher to take the risk of trying something new, you then have to convince them that the project is making progress.

Lots of publishers need to be reassured by the game play early on in the development and demand vertical slices (a full playable game level complete with all the features). This method is perfectly suited to shooters or car games where we can in fact produce a complete level and have a good idea of the final game play because all that remains is to duplicate the game play by changing sets.

The immense difficulty of the Indigo Prophecy concept was that a large part of the fun came from involvement in the story and emotion, which were both difficult to illustrate from a single isolated scene.

Because Indigo Prophecy didn't really use repetitive mechanics, playing an isolated scene demonstrated nothing except how that scene worked, without any indication of the context nor of the feeling the game would finally produce.

Moreover, it was difficult to perceive the typology of a game based on emotion as long as everything had not been set up, animation, dialogs, facial, lighting, rendering and most of all music. It was a bit like watching film rushes and trying to imagine the final result.

To optimize production, I had chosen to structure the development horizontally rather than vertically and produce all the animation, all the sets, all the characters, while simultaneously beginning to assemble. The result took time before it became visible but when it did, the whole game appeared "as if by magic" from one day to the next.

Production models should be adapted to the specific nature of the project, rather than just copying the established recipes. All games should not be produced like action games. Some creativity also has to be put in new methodologies to develop these games, more in line with their true nature and in respect with the publisher's constraints.

Convincing the Team

Managing the development team constitutes the other difficulty involved in producing an original project. When working on a FPS, the team has a very clear idea of what it is doing from the very first day of development. It has outside references that enable it to judge the quality of the game.
With an original project, this does not apply. The team had to have enormous faith in order to be able to produce Indigo Prophecy. Some of the team members even admitted to me that they had not really understood what Indigo Prophecy was all about until after the game was released and they heard their friends talking about it.

Anyone who has already directed a project knows how essential it is to have the complete confidence of the development team. If the team has reservations or no longer believes in the project, that project will fail.

For Indigo Prophecy, I made a point of never showing my doubts (which were nevertheless numerous and sometimes difficult to overcome all through the development) and made special efforts to share my vision of the project with the team.

Here again, the special nature of Indigo Prophecy and the fact that it was difficult to understand the experience of the game before everything was fitted together, did not make life any easier for me, but the team stuck with me all the way and I was genuinely touched by their confidence. I would like to take advantage of this occasion to express my gratitude to them.

Conclusion

Indigo Prophecy was really an extraordinary experience both professionally and in human terms. I learned an enormous amount from it and it profoundly changed my vision of interactivity. I won't make video games the same way before and after Indigo Prophecy, and I think it also deeply changed the vision of most of the people in the team.

And although the game may not be perfect, I hope that the passion and enthusiasm that the team and I invested in it will nonetheless make it a game that is both different and sincere.

In my personal development it constitutes an important stage toward making video games not just simple toys but a veritable form of expression. I hope it has given other more talented people the desire to explore interactive narration and the formidable capacity of this new medium to create emotion.

Publisher: Atari
Developer: Quantic Dream
Platforms: PlayStation 2, PC, Xbox
Number of full time developers: Around 80
Length of Development: Two Years
Release Date: September, 2005

Autor: David Cage
Source: Gamasutra

Labels: David Cage, Developers Diaries, English, Fahrenheit Indigo Prophecy

Tuesday, June 20, 2006
<< HOME

HOME : LINKS : ABOUT : RSS