Tomb Raider – the prophecy

PaoloMan sent me a link of a video review of Tomb Raider – the prophecy the game we developed some years ago when I worked at UbiStudios. The development was quite a challenge – we have to reuse as much as possible from the previous game – [CV-projectDesc-RS.html|Rogue Spear] and write, test and debug the whole game in three-four months.
With [CV-projectDesc-RS.html|Rogue Spear] we had developed a pretty robust engine for isometric view able to handle a couple of terrain levels – the CEngine. On the constrained hardware of the GameBoy Advance, the CEngine happily performed line of sight and line of fire tests, room occlusion, automatic generation of level maps, pathfinding, managed an impressive number of enemies on the whole level and provided reliable support for multiplayer game.
When I was informed that the studio was going to develop this game and that I would have been the lead programmer most of the decisions about the kind of game we were going to make were already taken, but, they assured me, it is as close as possible to the previous [CV-projectDesc-RS.html|Rogue Spear] game.
Good I thought. Unfortunately the old saying about a non-programmer pretending that two systems are the same meaning that they do not differ more than 50% held in that occasion too.
In fact the game had to preserve the Tomb Raider key game plays: jumps, vertical vertigo effects, puzzles and extinction of animals. Jumps was something unheard in a military simulation game such as [CV-projectDesc-RS.html|Rogue Spear] and the vertigo effect was hard if not plainly impossible to achieve with just two levels of terrain. Editors and tools were the same of the GameBoy Color games we did, i.e. 2D platformers without any notion of elevation. They already posed a number of headaches with the quite-flat world of [CV-projectDesc-RS.html|Rogue Spear], I wasn’t willing to think what could happen with tens of levels.
Puzzles was another head-scraping aspect of the game. I knew that every factor of the gameplay was going to be refined, modified and touched an uncountable number of times before the Gold Master, and I didn’t want a programmer to be dedicated to change and modify code to this purpouse.
Cut scenes were also required and the camera needed to move around, far from the main character, to show the effect of various switches and devices or the goal of the level.
Another problem was posed by the animation system. The CEngine animation system suffered from the [|Rayman] modular animation. In Rayman many animations were performed just by moving fixed shapes around. This approach was intended to save space and Rayman character itself was designed around this idea, but it is ineffective at most when you have to animate life-like characters. Lara had an impressive number of actions that really stretched the limits of the poor handheld system.
How we made it was a successful combination of hammering, ingenuity, compromise.
The CEngine proved to be well designed and well coded with good insulation between layers of game related abstraction levels. My fellow programmers were top notch and brightly solved a number of problems. Artists and Game Designers were great to understand technical problems and helped us in finding suitable compromises. And we managed to get the game throughout the whole process in three months and half.
How we did it?
About the number of levels we changed the physical property encoding of the terrain. CEngine provides a single byte to encode the physical property of each 8×8 pixels square. Such properties defines whether the place is dangerous to the main character or a solid wall or a plain, walkable terrain.
In [CV-projectDesc-RS.html|Rogue Spear] three bits were allocated to sound properties leaving just 5 bits for the rest. 8 elevation levels allowed to define two floors and the connecting stairs/slopes. Also the slopes needed to be both vertical and horizontal to accommodate for climbing and descending both ways. This allocation leaves pretty no space for more levels.
Well but if Lara Croft can jump why do we need slopes? So here we get back our slopes code allowing for 10 different heights, enough for the vertigo effect.
Nonetheless it was impossible to design such maps with the old 2D editors. Luckily [|another GBA game we were working on] at the same time needed a better editor so the management decided we had enough “needs” for a new editor. Alberto worked on the editor for about one month and something accomplishing a remarkable result before game designers actually started designing maps and levels.
Another bright programmer, Valentino, worked on the puzzle system. Rather than hand coding each puzzle as a specific C code, he defined a set of devices that could be connected in many different ways to provide enough flexibility to implement any kind of puzzle. At the end the mechanism proved to be still too complex for non-programmers, but he managed to implement and maintain the whole system alone with minimum effort.
Cut scenes were a major problem – we didn’t have the resources for developing a cut scene authoring editor, nor we could afford movies in the game for cartridge space constraints. We came out with a simple idea that turned out to be a nightmare to use. The simple idea was to have a dummy character able to play any animation, then for each character in the cut scene a path had to be drawn where each node contained both timing and animation code.
Although the idea was simple, creating cut scenes this way was a burden. Synchronization among characters was impossible, modifying an existing sequence was a painful operation. At the end the producer Nicola went through all the cut scenes fixing and sometimes recreating from scratch all these meaningless number tables.
The number of Lara action posed another problem. Design document asked for some 40 basic actions to be performed in all the 4 available facings (left, right, up, down). Moreover some of these actions could be performed both with guns drawn or not. Moreover guns automatically aims to the nearest target in discrete steps of 8 directions. Even relying on the hardware horizontal flip for some animations, the resulting number was huge. We managed to handle them all by splitting the character in half: legs and arm with chest plus head. Thanks to this trick and some twiddling in the actor code we avoided the need of writing compression/decompression code for animations.
Given all that, the fact that the lead game designer resigned in the middle of the project, the fact that a change in the Eidos management near the Gold Master forced us to rework a number of license issues and the other GBA game developed at the same time by the same people, I don’t hesitate to call Tomb Raider – the Prophecy a great success. Back then it won’t earn much credits to the studio since it sold much below the expectations and got several mild reviews that’s why I am happy to hear that people love it (the video reviewer score it at 10/10).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: