Gamasutra is part of the Informa Tech Division of Informa PLC

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.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Blue Tongue Software's Jurassic Park: Operation Genesis
View All     RSS
September 25, 2020
arrowPress Releases
September 25, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: Blue Tongue Software's Jurassic Park: Operation Genesis

March 17, 2003 Article Start Previous Page 3 of 3

What Went Wrong

1. Three Platforms at once. Operation Genesis was developed simultaneously for PS2, Xbox and PC. This was the first time we developed a game for multiple platforms simultaneously. While this presented a number of challenges, the approach we took enabled us to deliver all three versions successfully.

As mentioned earlier, Toshi was built from the ground up to support multiple platforms. The game code was largely platform independent, and the platform-dependent engine components were designed as plug-ins that could be refined during development. This enabled the development of the game code and the platform-specific engine code for each platform to proceed in parallel.

The build environment was set up so that team members could have all three versions compiled on their machines without one version clobbering another. Also, the development kits for PS2 and Xbox were connected to the LAN, enabling any team member to use them. It meant that team members could run the game on every platform even if they did not have the hardware for every platform at their desk. This enabled programmers and artists to develop and test on all three platforms regularly. While this set up enabled us to work on multiple platforms simultaneously, there were a few bumps along the way.

Sound designer and music composer Stephan Schütze using his sound equipment. He insists that he needs every one of those buttons.

Because the game code was mostly platform-independent, we had one copy of the game code in version control, and used it for all platforms. (#ifdef's were used in the places that had platform-dependent code.) We did not keep separate copies of the code for each platform. This was helpful as it meant that we did not need to duplicate changes across multiple copies of the code. However, it also meant that changes to the game code would immediately affect all platforms.

Because of this, there were some occasions early in development where code was tested on one platform, checked in, and broke the game on another platform. The types of problems that manifested ranged from graphical glitches to occasional crashes. (These were usually fairly easy to fix once the cause was found.) After being stung once or twice, we implemented a number of processes to avoid this problem.

Although this was the procedure from the start, we became stricter with insisting that code be tested across platforms before it was checked in. While the team followed this rule for the most part, there were some hurdles that made this difficult. First, compile times were long. Just linking the PS2 or PC build would take several minutes! Second, there was an initial lack of development kits for the consoles. This lead to some contention for resources, especially access to the PS2 development kits. As the project progressed, the number of kits increased, but there never seemed to be enough. So, while we asked everyone to test on all platforms before checking in, it was sometimes difficult, especially in cases where a number of team members were waiting for a small change to be checked in before they could proceed. (The time to compile and test on the various platforms often far exceeded the time to make the change.)

To supplement the rule of testing on all platforms, we also asked all team members (programmers and artists) to keep a log of changes they've made. The logs were written in a parse-friendly format, and checked into version control. A script was run daily to merge all the logs into a report. The report helped to keep the team informed of what other people were doing, and, in the late stages of development, it also helped in tracking the cause of new bugs. While these kinds of logs would be useful in any project, they were especially useful in finding bugs that were caused by not testing across all platforms. (For example, bug "fixes" that remove the bug on one platform, but introduce another on a different platform.)

Acrocanthosaurus catches a Dryosaurus for dinner.

Another challenge was dealing with the different capabilities and limitations of each platform. The differences that affected us the most were the different graphical capabilities and the different amounts of memory in each platform. While we wanted to keep the three versions as similar as possible, we also wanted to use each platform to its full potential. For example, the virtually limitless amounts of memory available to PCs enable them to support a highly detailed model set. This created some extra work as we needed to create and maintain multiple versions of the assets. However, we held off on multiple versions of assets for as long as we could to ensure that the assets created would be fairly final, avoiding the need to rework multiple versions of an asset.

Developing for multiple platforms simultaneously also made some milestone days a nightmare. There were occasions when we released seven different builds for a single milestone. There were versions for each platform and versions for different languages (US, Europe and Japan). As the project progressed, we organized staggered deliveries, delivering two or three builds on a milestone day. For example, we would deliver the US builds for all three platforms, or alternatively deliver the builds for a single platform in all languages. Staggering deliveries helped reduce the load on our internal QA.

Shane Stevens, the lead programmer, checks out some new artwork.

2. Is it compiled yet? The size of Operation Genesis and the compilers we used meant some long waits for compilation. For PC, on some of the development machines, just linking the project could take several minutes. This led to some long debug-compile-test cycles. This was especially problematic as we were developing on three platforms simultaneously, and we wanted the team to test on all platforms before checking in.

There were a few days where a large number of system changes were checked in. On these days, numerous full recompiles were required, and the team spent a lot of time waiting. Long compile times were also an issue in the days leading up to milestones as internal QA spent a lot of time waiting for new builds with the fixes needed.

Close to the end of the project, we found that it was possible to speed up compilations for the PC build significantly using Microsoft's new .NET compiler. However, we deemed the risk of switching tools at that late stage too high, and stayed with the tools we were using.

Derek Burnheim, our senior programmer, takes a break from coding to "test".

3. Over-generalization. From the beginning, the architecture and design of Toshi were kept very open. Some of the features were not ultimately used in Operation Genesis. And, in the later stages of the project, we re-engineered parts of the engine to increase its performance and improve memory usage.

For example, the animation system went through a number of iterations. With each iteration, we dropped some of the features that were not utilized and optimized the data structures further so that we could fit more animations for dinosaurs into the limited memory available on the consoles.

Another example is the AI system. The systems that were built were very powerful, but there simply wasn't time to take full advantage of their capabilities. For instance, the data-driven neural net system used for the dinosaurs' perception lends itself perfectly to in-game learning. However, in-game learning did not fully fit the game design, and the situations where it could be applied were very contrived. As a result, we did not use in-game learning even though it is supported.

There is a conflict between designing general, open-end technologies that can be reused in future projects, and building specialized technology for the current project. As Toshi was a new engine, there was always a tendency to give it more features, and make it the best. While this did not create any serious problems for Operation Genesis (apart from needing to re-work some parts), it may be a good idea to use prototyping even more in future projects, starting with simple versions, and adding more functionality as the requirements become finalized.

Pachycephalosaurus (concept art).

4. Prototyping and the Media. While it's a good engineering tool, prototyping isn't really compatible with the notion of press releases. As mentioned earlier, prototypes and placeholders were used extensively early in development.

As we were developing Toshi concurrently with Operation Genesis, we organized the schedule to minimize bottlenecks and to keep development in parallel. However, this plan meant that enhancements to rendering and other aesthetic boosts were often placed at a lower priority. (There were some bursts of aesthetic work for events such as the E3 Xbox demo.)

This meant that there were times when the game was not looking at good as it could, even though it may have only taken a day or two to make the aesthetic tweaks. As a result, we faced some criticism of rendering quality (and draw distance) based on some early incarnations of our rendering components.

The Blue Tongue team.

5. Features lost. As with all games, there are always features that were left out due to schedule or other reasons. With Operation Genesis, we probably had enough ideas to fill multiple games. I'd like to use this section to lament a few features that were lost.

Very early in the project, we dreamed of 40 dinosaur species. However, as development proceeded, the list was reduced to 25. The ones that we miss most are the sea-dwelling and flying dinosaurs. The main reason they were lost was schedule. In some sense, it was a choice between creating fewer, more interesting dinosaurs, or a larger number of less interesting dinosaurs. We decided to make the dinosaurs we had count, and focused on species that players would recognize from the films. However, models and art were created for some of the lost dinosaurs. We'll miss them.

We experimented with baby dinosaurs midway through the project. We tried schemes such as scaling the adult dinosaurs down to make them into babies. However, scaling adults down did not look right. Making baby dinosaurs that looked good required new baby dinosaur models and baby AI. This is similar to the work required for adding more dinosaur species. As a result, baby dinosaurs were dropped. Along with them, we also dropped any ideas for a "Dino Petting Zoo".

There were also some buildings that did not make it into the final game. These buildings include the hotel, hunting platform, and the dino-vet station. Some of these buildings existed in earlier builds of the game. Some were removed due to design decisions, and some were removed due to the memory constraints on the consoles. Having seen and played the game with some of these buildings, losing them was a difficult decision to make.

Operation Genesis evolved throughout the development period, and these features were cut for good reasons. However, if there's ever an expansion pack or sequel, I'm hoping that some of these features will make an appearance.


Operation Genesis was bigger than our previous projects, and was our first experience at developing for multiple platforms simultaneously. While there are still features that we would like to add and tweak, we finished with a product that we are happy with, and hope that players of all ages can enjoy.

Credit must go to the entire Operation Genesis team for all their talent, dedication, and hard work. Every team member made contributions to many and all areas of the game. I must also give credit to the many members of the team who contributed to the post-mortem. You input was invaluable, and gave me an opportunity to see the project from many points of view.


Jurassic Park: Operation Genesis

Developer: Blue Tongue Interactive
Publisher: Universal Interactive
Number of Full-time developers: Varied throughout project, but 26 at ship date.
Length of Development: 22 months
Platform: PS2, Xbox, PC
Release Date:
March 12, 2003 (PC), March 28, 2003 (PS2/Xbox)
Development Software: MS Visual Studio, 3DS Max, SN Systems
(PS2), Visual SourceSafe, Test Track Pro, Photoshop, Excel.
Development Hardware: Ranged over course of development from
800MHz-2.2GHz CPUs, with 256-1024MB RAM
Notable Technologies: fmod, Bink, CRI.




Article Start Previous Page 3 of 3

Related Jobs

Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Development Director
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Development Manager (Xdev Team)
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Cinematic Scripter
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Engine Programmer

Loading Comments

loader image