PaoloMan sent me a link to 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 – Rogue Spear and write, test and debug the whole game in three-four months.
With 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 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 on 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 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 Rogue Spear, I wasn’t willing to think what could happen with tens of levels.
Puzzles were 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 changing and modifying code for this purpose.
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 the 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, and 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 at understanding 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 did we make it?
Regarding 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 define whether the place is dangerous to the main character or a solid wall or a plain, walkable terrain.
In 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 accomplished 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. In 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. In 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’s actions posed another problem. The design document asked for some 40 basic actions to be performed in all 4 available facings (left, right, up, down). Moreover, some of these actions could be performed both with guns drawn or not. Moreover, guns automatically aim at the nearest target in discrete steps of 8 directions. The resulting number was huge, even relying on the hardware support for the horizontal flip in some animations. 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 scores it at 10/10).