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.
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.