Omikron Game: INDIGO PROPHECY: Developer's Diary

INDIGO PROPHECY: Developer's Diary

Fahrengeiht Art

THE GAMEPLAY

Game Design
Writing the full game design document took me about a year to complete. The final script is about 2000 pages and integrates absolutely everything; story, characters, gameplay, structure, branching dialogs, horrible sketches, maps and storyboards (I am terrible at drawing), instructions to remember for acting and directing, indications about music and sounds and much more. With the experience of another very complex game (Omikron), I have established some rules for my game designs in order to put all the possible information in there while keeping them clear (I hope). This document was the master document for the whole production. It was truly our "bible", the absolute reference for everything.

Very few changes happened during the development. The number of people involved and the mass of data produced would have made any change extremely time and resource consuming. This is why I usually pay a lot of attention to the game design document to avoid having to make changes on the fly. Trying to set the game design in stone at the beginning of development is generally a noble wish, but it is also important to leave some space for what is discovered during the process. Whatever efforts you make to try to plan the game on paper, you always have some surprises when it comes to the screen; some good, some bad.

Fahrengeiht Art

Our first tests on the game brought both good and bad news. The good news was that the storytelling seemed to work well. After a couple of hours of play, a pleasant feeling of attachment to the characters appeared. They were real characters, consistent and with a personality. The player felt like he knew them, knew their tastes, how they would react, where they came from, a little bit like in a TV series. The pacing of the narrative was also working well, because as the player moved between the different playable characters, the different sets and situations, the story was always moving along. Unfortunately the pacing of the game itself appeared to be way too slow on all levels though. Moving across a room was really painfully slow, there were cut scenes every two steps, dialogs lasted hours, etc. In our anticipation of the balance between narrative and interactivity, we obviously gave too much importance to the narrative, which killed the fluidity of the experience. We made massive adjustments to the pacing of the game, speeding the navigation animations by 30 per cent, cutting all unnecessary cut scenes and speeding up the remaining ones. The game was suddenly totally transformed. We came from something that was slow and boring to a fast moving experience. The story finally found its own pacing.

Time pressure also became a major element of the game play. I absolutely wanted the story to move along all the time, trigger events on its own and push the player forward. I did not want to let the player to slow the pacing of the narrative except in specific situation. In the diner at the beginning of the game, Lucas is under pressure because the cop may stand up at any time. In his apartment, he has the premonition of the cop arriving and has a limited time to decide what to do. I tried to take every single opportunity to make the world accelerate the story.

As I said, very few changes to the design happened during the development of Indigo Prophecy. The most significant one was probably the idea of the actions and choices modifying their mental health, making them feel good or bad about themselves and affecting their psychological state. To do this, we take physical actions into account, and also all the moral choices the player has to make in the story and the relationships he has with other characters. In the original script, everything was in place to make the player feel good or bad about his actions. In my mind, if the player decided to save a child by risking his own life, he would feel good about it. On the flipside, deciding to play it safe and let the kid die would make him feel bad. I thought that these feelings would happen in the player's mind and that they would be obvious. When I could play the entire game for the first time, I felt that this idea was a little too abstract for the player. He would clearly need a visual representation of his mental health to make it more tangible for him. This is how we decided to add the little mental gauge in the lower right corner of the screen. We also decided that the character's animations would depend on his level of mental health, making it even more obvious for the player. Then we realized that many other actions implemented in the game should affect this gauge and that we needed to add a consequence if the characters get totally depressed. We developed the full system in a couple of weeks, including the game over sequences. The tools were robust enough to allow such a significant change so late in the development.

The Pen to Tell the Story: The Interface
I felt comfortable with the solutions I had found so far for the storytelling part, but another important element was still missing to be able to tell a decent interactive story: the interface. Most video games use a list of actions limited to about 15 to 20 maximum. The reason for that is easy to understand: there are about 10 buttons on a game controller. It is difficult to have more actions than buttons. I really see the interface as the pen we give the player to write the story. The issue is that telling a good story with a hero only able to do 20 different actions is very difficult.

The idea of having contextual actions quickly appeared to me as being the right solution. I would have an infinite number of possible actions that I could use depending on the situation. The final missing piece in this puzzle was to make the player forget the interface. Often, the controller is just a remote control to move a bunch of pixels on screen. For Indigo Prophecy, it had to be a part of the experience, an extension of the player's physical body in the world of the game. I wanted him to touch objects, make the moves with his character, to feel how his character feels.

Inverse kinetics would have been an interesting solution to actually move the arm of the character in the world while doing the same move with the analog stick, but the results were too unpredictable. Also, I did not want to distract the player with the interface from his main focus; the story. The solution had to be simple and fluid, context sensitive and supporting immersion without distracting the player. It sounded to me like a very ambitious challenge.

Fahrengeiht Art

Then I started working around the idea of momentum; the simple feeling of initiating the motion with the stick, making the move, and at the same time working within the boundary of the movement itself. I called this system MPAR for Motion Physical Action/Reaction (I love meaningless acronyms!)

Simple symbols at the top of the screen describe the movement the player has to perform in order to unfold the animation. He can really "play" it, decide to do it faster or slower with the analog stick, or even play it back and forth. No need to have more menus or icons, no need of "Examine/Combine/Take" anymore, the player just decides what he wants to interact with and makes the appropriate move.

With the Bending Stories writing technique and this new approach to interface with my contextual MPAR, I had the basic words of the narrative language of Indigo Prophecy.

I just still had a thousand major issues to solve before having the final script of the game.

Game Mechanics
Another interesting challenge was to solve the equation of game mechanics. Most games taken at their core are based simply on pressing the right buttons at the right time. The player progressively acquires the necessary skills to understand the best timing and order depending on the information given by the program. As the game progresses, timing becomes more and more tight. These games are based on repetitive patterns of actions triggered by patterns of controls.

If games are based on short and repetitive patterns, stories totally hate them. A story has an arc, and the range and diversity of the hero's actions to solve his issues are a significant part of storytelling. If videogames usually give the priority to physical actions, a major part of the story usually takes place in the mind of the character, where he has to face moral choices and dilemmas. Difficult to play that by just pressing buttons...

In short, my objective was to provide an experience that didn't rely on short control patterns, didn't need repetitive mechanics, and I wanted to provide the possibility for the player to make "non-physical" choices. Having no real mechanics in a game is a very interesting exercise. To me, there is no other way of creating a storytelling experience than to let the story generate its own mechanics. The story becomes a "puzzle maker" in 3D. It creates the context for choices and manages the consequences. There are of course some mechanics, but I tried to make them as invisible to the player as possible by integrating them directly into the context. For example, I often used time pressure in the scenes. In the opening scene, the player must hide a dead body in the restroom of a diner before someone comes in. This timer will be perceived by the player as a logical event in the context of the story, but at the same time it puts pressure on him by forcing him to think fast. It adds stress and tension to the scene while making the player "feel" like he really committed a murder.

Multiview
Multiview is another example of this blend of mechanics and storytelling. When I saw the TV series 24 for the first time, I was amazed by the potential of this feature. Not only did it have a wonderful visual appeal, but it was also a great gameplay feature. Instead of having a cut scene to show what was happening in another place at the same time and lose interactivity, Multiview would allow me to open another window in real time 3D and let the player continue to play while watching what's happening. For example, when Lucas leaves the diner in the first scene of the game, I can show the cop discovering the dead body in the restroom while still allowing the player to control the hero's actions.

Implementing Multiview has been an interesting technical challenge, to say the least. First of all, we had to make the decision of implementing this feature based on the idea of displaying up to four real-time 3D scenes in four different windows, at a time where the engine was not optimized at all. In fact, at this point it was only running at about eight frames per second with one window. It showed considerable faith in our technology to believe that we would be able to display those four views at 30 frames per second, which is what we eventually were able to do.

The other important consequence of Multiview was the necessity to have a multi-threaded script and the possibility of the need to synchronize threads. We needed to execute the main script in the player's window, but also to have other threads with up to four complex scripts running independently. We also needed to accommodate the possibility of hooking two threads together when they needed to be synchronized. Last but not least, memory constraints were massive. Four times the data from the same scene means four times the memory requirement. On PS2 especially, managing loading times and memory constraints has been really challenging.

For example, there is a complicated scene in the game where Lucas is hidden in a hotel; Carla and Tyler are in the corridor looking for the right room so they can arrest him, and Lucas' brother Markus is in his church with the villain trying to kill him. These three scenes are loaded and displayed in three windows at the same time, and the player can freely switch between these three characters. The entire scene takes place in real time and each character can influence other windows: Lucas can call his brother to warn him, Carla and Tyler can enter in Lucas' room, Markus can decide to answer the phone or be killed by the villain. Most people won't even realize the technical difficulty of these scenes, and this is why I think it works so well. Technology should be invisible and always allow the experience to be at the forefront.

Action Sequences
When I made the decision of going for this new action interface, I knew some people would love it, while others would hate it. My thinking was simple; I was looking for an interface that would allow me to have very spectacular action sequences, where each scene was different and each was presented with a strong sense of pacing and direction. I had to find a generic interface that would allow me to do car chases, ice-skating, basketball, dancing, fighting and anything else I could think of. I knew the result would be amazing-instead of always having the same repetitive shooting scene with the same 20 animations, I could have any type of action with spectacular animations and direction.

At the same time, I was thinking about what was really important in any action scene, namely timing and precision. I suspect that Yu Suzuki was thinking along similar lines when he was designing the Quick Time Events in Shenmue. This approach has become more and more popular in recent years, and it's been used very effectively recently in games like Resident Evil 4 and God of War. In Indigo Prophecy, I tried something slightly different based on the same concept. I wanted to keep the idea of physical immersion, a direct link between what the player is doing on his controller and the motion on screen, but I found that Shenmue's QTE were quite disconnected from the action. The decision to use the two analog sticks rather than the buttons seemed to be the right approach.

I also wanted to increase the amount of user input. I didn't want a Dragon's Lair style experience, but rather a kind of Dance Dance Revolution kind of feel. Making the character move should be a sort of dance. He has two arms and two legs, there are two analog sticks. It sounded like a good fit. The decision to put the two rings in the middle of the screen was an audacious one I think. It takes some time to get used to it, but it really works, and I think it increases the feeling of immersion. We did tons of tests with positioning, sizes, colors, but none of them worked as well as the one we implemented. We discovered that while the center of the eye was focused on the 2D symbols in the middle of the screen, the periphery of the eye tries to have a sense of what's going on in the background. In my mind, this is exactly what would happen if the player were in the situation for real; the center of his eyes would be focused on his next move while also trying to see what's going on around him. It requires some time for the eye to get used to the system, but when it works, it creates a kind of third dimension that significantly increases immersion.

NEXT >>

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

Thursday, September 22, 2005
<< HOME

HOME : LINKS : ABOUT : RSS

INDIGO PROPHECY: Developer's Diary

THE GAMEPLAY

Previous News