Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Blue Tongue Software's Jurassic Park: Operation Genesis
arrowPress Releases
December 13, 2018
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 2 of 3 Next
 

What Went Right

1. Jurassic Park as a simulation game. The Jurassic Park books and movies have always contained action. However, a core idea in Jurassic Park is the creation of a dinosaur theme park. It is surprising that only one other game has explored Jurassic Park as a park building simulation -- Konami's Jurassic Park III: Park Builder, which was released after Operation Genesis was already in development. We wanted Operation Genesis to be a cinematic simulation that would capture the feeling of the movies. Also, while simulation games are more common on PC, we wanted Operation Genesis to be as fun on a console as it was on a PC. We feel that Operation Genesis succeeded in achieving these goals.

The process of conceiving Jurassic Park as a simulation game was fun, and generated an endless source of ideas. It was a vision that inspired the team, and every member of the team contributed to the design. Operation Genesis is not tied to any particular Jurassic Park movie or book. As a result, we were able to draw from everything in its universe. The game features dinosaurs from the first, second and third movies. To recreate the feel of the movies, characters such as Dr. John Hammond also make appearances in the game.

As Operation Genesis is a Jurassic Park game, we follow the facts set by the movie. For example, the Velociraptors in the game are human-sized, and the Dilophosauruses can spit venom at their prey. (Note that we later discovered that there is no evidence to suggest that real Dilophosaurus could really spit venom.) However, not everything in Jurassic Park fitted into the game. For example, the tiny Compsognathus ("Compys") are familiar to Jurassic Park fans, but were left out of the game due to their size. These small dinosaurs would have been very difficult to see, making game play difficult.

In the cases where the movie did not specify the dinosaurs' behavior, we drew information from the real world. Sources used include The Dinosauria by Weishampel, Dodson and Osmolska, and Terrestrial Ecosystems Through Time: Evolutionary Paleocology of Terrestrial Plants and Animals by Behrensmeyer and Sues. While we were not striving to be educational, the Dinopedia in the game provides some real dinosaur facts to the player. We wanted to give a rewarding experience to both fans of the movies, and fans of dinosaurs.

We looked at many issues when designing Operation Genesis. One issue was finding that balance between order and chaos. Jurassic Park as depicted in the film and books is about the loss of control and the chaos that ensues. However, players must be able to create order if their park is to be a success. Will the player enjoy Jurassic Park if everything is running well? This part of the design was one of the more difficult issues. If dinosaurs break out constantly, the player may feel that they have no control over their park, and feel frustrated. However, if the dinosaurs break out too rarely, the park will feel too safe and will not feel like the Jurassic Park people read about and saw in the films.

To address the issue of breakouts, we created various security measures that the player can use. The player can research and upgrade to stronger fences. This enables the player to increase their security as the game proceeds. However, to prevent the park from becoming too safe in the later stages, weather effects such as tornados and thunder storms can destroy sections of fence and stress the dinosaurs, causing them to rampage.


A T-Rex doesn't like tour groups going through its territory.

In Operation Genesis, there is a direct mapping between the simulation and the game aesthetics. For example, seeing one dinosaur in your park means there is one dinosaur in the simulation. When you see the dinosaurs fighting in the park, they will get hurt or injured in the simulation. This extends to all parts of the simulation. Being able to see all that happens in the park adds to the cinematic feel of the simulation, and also helps to create a sense of immediacy. Players can see and get a feel for how their actions affect the park.

Also, wherever possible, the game lets the players jump in and manipulate the park directly. For example, when a dinosaur breaks out, players can fly the helicopter out to sedate it. Or, if the dinosaurs are playing too far away from the viewing tower, players can use the helicopter to herd the dinosaurs closer to the viewing tower so that the visitors can see them. This level of direct manipulation caters to console players. However, for players who just want to manage the park, these kinds of operations can also be done automatically. For example, you can issue a sedate order, and an AI Ranger will fly out and sedate the dinosaur for you. This style of play is often found in PC simulation games. By supporting both styles, players can choose the level of interaction they want.

2. Toshi, the engine that could.
Toshi is the new engine that we developed for Operation Genesis. It was designed from the ground up to be multi-platform, expandable, and customizable. We wanted the engine to be as reusable as possible.

Consequently, Toshi's design uses a component architecture. Components such as shaders (used for rendering), game creatures, and GUI objects are all just plug-ins to Toshi, making the entire system very modular and extendible. As it was built in parallel to Operation Genesis, the initial component "toolkit" was geared towards photo realistic outdoor environments, dense foliage and skinned creatures.

Toshi was also designed to work on multiple platforms from the beginning. This is a key feature that made it possible for us to develop for three platforms at the same time. Given the independent nature of components, the platform-dependent (primarily rendering) components could be implemented in parallel. This design also enabled new, enhanced versions of these components to be plugged in as they became ready. Like other cross-platform engines, Toshi enables the same application code to work across all platforms.

One of the most successful parts of Toshi is the animation system. The dinosaurs in Operation Genesis can blend ten or more animation sequences at a time. Often, these sequences also have sub-component animations driven by the AI system. This enables the dinosaurs to walk, look around, and blink all at the same time. This flexibility creates natural looking movements, and means that a dinosaur might do the same behavior slightly differently each time. The system went through a number of iterations during the course of the project. The final version was very fast, required a tiny memory footprint, and ran equally well on all three platforms.

As we were developing our engine at the same time as the game, we faced the risk of having major production bottlenecks. Our solution was to use prototyping and placeholders to keep the game development going. This was used in a number of situations and was perhaps the main reason we were able to develop the engine in parallel to the game without serious scheduling problems.

For example, before Toshi was rendering the structures, visitors and dinosaurs, a placeholder renderer was made to allow the development of AI systems to proceed in parallel. This renderer used text and icons to display the current state of each unit, enabling the game and AI architecture to be tested and tweaked. So a large part of the game architecture was fully functional before Toshi was rendering the objects on screen.

Another instance where we used prototyping and placeholders revolved around the path-finding system for dinosaurs. Early in development, we used a system we developed for Starship Troopers as a placeholder to allow the AI development to continue. But this solution was not adequate; it didn't cope with terrain modifications made by terraforming operations, and it made some assumptions about bipedal objects (which does not apply to the quadrupeds in Operation Genesis). However, using this old system as a place holder was enough to keep AI development going while a more fitting solution was prototyped. Since the prototype was developed using the same interfaces as the placeholder, it was a simple task to drop the final path-finding system into Operation Genesis.

Toshi supports powerful terrain rendering features. In the early stages of the project, procedural terrain texturing was prototyped using a software-rendering scheme. This allowed us to rapidly try out a number of different ideas. Care had to be taken as we needed to ensure that the design selected was achievable on the hardware of all three platforms. Having a prototype also allowed us to streamline asset creation, since artists could visualize their work months before the final system was implemented.

Prototyping was used extensively during the development of Operation Genesis; all high-risk components were prototyped. This was a valuable tool, enabling us to mitigate many risks very early in development.


T-Rex having a morning drink.

3. The Art of Jurassic Park. It was important that Operation Genesis capture the aesthetics created by the Jurassic Park films. Almost all of our players are familiar with the movies and we need to give them the Jurassic Park that they know. The artists on Operation Genesis did an outstanding job in accomplishing this goal. I believe the dinosaurs in Operation Genesis are some of the best dinosaurs seen in any game.

When people think of dinosaurs, they usually think of the colorful and lively dinosaur from the Jurassic Park movies and books. Jurassic Park did a lot to update the public's perception of dinosaurs; before Jurassic Park, most of the public saw dinosaurs as slow, gray creatures. Although we were creating Jurassic Park dinosaurs, the way each dinosaur should look was still not clearly defined. The appearance of the dinosaurs changed between the three different films -- the dinosaurs became more colorful in the later films. Because of this, the dinosaurs in Operation Genesis went through a number of iterations as we settled on a style. We initially used designs from each of the three films, but settled primarily on designs seen in Jurassic Park 3.

Our artists gave each dinosaur a number of special animations, imbuing each species with its own individual character. For example, the Triceratops will locks horns with each other in a playful show of strength, and the Velociraptors will climb the fences to escape. These kinds of animations breathed life into the dinosaurs of Operation Genesis, making them interesting to watch. This was important, as we decided early in development that the visitors in the simulation should only be entertained by things that will also entertain the player. I think these interactions worked well in the game. Quite a few members of the team were seen locking the camera onto their favorite dinosaur, and leaving the game running like a fish-tank. (This is the reason we created the "Site B" mode of the game. In this mode, the player does not need to worry about managing a park; the player can create herds of dinosaurs and just watch them.)


Spinosaurus (concept art).

Getting the sound and music right are also crucial for bringing the player to Jurassic Park. With the dinosaur sounds, we used the sounds from the movie when possible. For example, when the Velociraptors call to each other, they use those evil sounding barks from Jurassic Park 3. And, the T-Rex has the familiar T-Rex roar from the film. For dinosaurs that did not appear in the movie (or did not get enough screen time to show us their calls), we constructed the calls by blending together real animal sounds. In some cases, unusual bird sounds worked well without too much manipulation or alteration. The sounds we created were then tailored and reworked to fit the character of each dinosaur. We used the sounds to highlight the character of each dinosaur, while keeping them consistent with the world of Jurassic Park.

Another aspect of art that worked well is the tools. The export process enabled the art team to drop new assets into the game without needing to create new builds. This enabled assets to be polished quickly, and also enabled the artists to work independently of the programmers. We also created tools for tweaking special effects such as particles and weather. Because these effects were data driven, it enabled the art team to fine tune them without needing to wait for new builds.

4. Data-Driven Game Play. Almost every aspect of the game could be tweaked via spreadsheets, from weather settings to the AI for all the different units. This enabled a fast turn around in tweaking the game balance as we did not need to wait for new builds to test the changes. It also enabled balancing responsibility to be delegated to the team members who are most qualified to do it. For example, tweaking the walking and turning speeds of the dinosaurs was best done by the animators who created those motions.

The data-driven aspects of the design also extend to unit definitions as well. All the units in the game (dinosaurs, visitors, buildings) are bound to the game in a dynamic way. They are like self-contained plug-ins to the game, and interact with the game world and other game objects via well-defined protocols. This allowed us to develop all of the game units concurrently. Also, as the game evolved, this system enabled new units to be created and plugged-in easily. In a way, all units in Operation Genesis are "add-ons" to our initially empty environment.

The data-driven approach required some initial investment. However, the time spent creating these systems was saved many times over, and allowed us to focus on game balancing and tailoring individuality into creatures. Having data-driven unit definitions also opens up the possibility of creating expansion packs with more dinosaurs, objects and buildings.

5. Artificial Intelligence. As mentioned earlier, Operation Genesis is a game where the simulation is tied to the aesthetics. The game is not purely driven by stats. We do not use rules such as, "One carnivore feeder will support two T-Rexes," implying a model where as long as there's one feeder within the enclosure the two T-Rexes will not get hungry. Instead, when a T-Rex gets hungry, it will search for suitable prey, chase it down, and eat it. Enabling the dinosaurs to do this makes the game play much more immediate, and also makes the AI system critical. As a result, we began work on AI very early in development. The systems worked out well.


Jurassic Park from a visitor's point of view.

The dinosaurs in Operation Genesis have drives and needs like real animals. When their needs are not being fulfilled, the dinosaurs will take action to satisfy their needs. They can perceive their environment, and know how to interact with other objects/creatures. Like many other aspects of the game, the dinosaur AI is data driven, enabling the dinosaur behavior to be tweaked rapidly.

The dinosaur AI is separated into three distinct systems: the neural net perception system, the behavioral drive system, and the behavioral execution system.

Each object in the game has a clearly defined set of traits. When a dinosaur perceives an object, it uses these traits as inputs into its neural net. The neural net will then classify the object into a category that is relevant to the dinosaur. For example, it may classify the object as a "threat", "friend", "food", and so on. The most exciting feature of this system is that it enables dinosaurs to respond appropriately to new objects/creatures that they have never encountered before. However, these neural net computations can be expensive. As a result, a caching system is used on the neural net results to reduce the computational load.

While the traits can be tweaked to create the behavior we desire, the neural net outputs are not 100% predictable. This means that the dinosaurs do not always behave as we predict. However, this works in the game because there is no right or wrong responses. Hypothetically, even if a small dinosaur decides to attack a larger one, it may be seen as brave or foolish, but not necessarily incorrect.

Once the dinosaur has classified the object it has perceived, the classification is sent to the behavioral drive system. The drive system will then determine which drive is the most dominant at this point in time. While only a subset of the dinosaur's drives is visible to the player, the set includes all the possible behavioral motivations that the dinosaur may have. These include hunger, thirst, the desire to hunt, the desire for territory, the desire to socialize, and the desire to flee from predators. These drives are grouped and prioritized. Important drives such as self-preservation are always given the highest priority.

Finally, each drive has a hierarchical finite state machine associated with it. These specify and carry out the actions needed to fulfill that drive. (For example, the actions that the dinosaur should take to find suitable food.) Different dinosaur species fulfill these drives in their own unique way, giving each of them their own personality.

The AI system also enables some interesting, emergent, group behaviors. For example, when a T-Rex approaches a flock of Dryosaurus, the flock will scatter and flee in all directions, as the Dryosaurus drive for self-preservation overrides the drive to flock and socialize. These emergent interactions add life and complexity to the dinosaurs.

Besides the dinosaurs, visitor AI is also an important part of the game. The visitor systems also have some interesting features. The visitors determine how well your park is doing. If a large number of visitors see attractions that they like, the park's star rating will go up. If a large number of visitors complain, the star rating will go down. For efficiency, each attraction (for example, a viewing tower) has a "performance analyzer" attached to it. The analyzer will look at the scene visible to the attraction and rate it. The analyzer scores are updated regularly as the dinosaurs move around and change their behaviors. Visitors can check the analyzer score and decide how much they enjoyed the attraction. This avoids the inefficiencies of having every visitor analyze the scene before them.

Although the performance analyzers started as a way to improve efficiency, they eventually turned into a part of the game play. The player is able to select an attraction and see its performance. The analyzer score depends on what thrilling, fun or historically accurate entertainment is visible to the analyzer. This gives direct feedback to the player on how they can improve each attraction.

Visitors generally stay on the road network. (The exception is when dinosaurs are loose. Sometimes, panicked visitors ignore the rules and run off roads to try to escape being eaten. In this case, the visitors use the dinosaur steering system.) Because of this, we store proximity information about buildings on the road network. This makes the visitor pathfinding extremely efficient. The roads themselves can trickle information across the network, keeping the CPU load down. When visitors come to intersections they can use this information to determine what attractions are close by without requiring each visitor to search the road network again.

There is also an interior steering system that visitors can latch onto for entering buildings. Some buildings have interior paths that were specified by the artists. This system allows the visitors to navigate perfectly around the complex building geometry. The paths also hook up to the logic of the building, making it trivial for buildings to have doors that open when visitors come up to them. In addition, the paths can specify turning direction and animations (such as sitting down at benches in the picnic areas), as well as calling routines that affect the visitor's state (such as buying food from a kiosk when the visitor gets to the front of the line).


Hervibores like to socialize with each other.


Article Start Previous Page 2 of 3 Next

Related Jobs

WWE
WWE — Stamford, Connecticut, United States
[12.13.18]

Manager, Interactive Games
Crystal Dynamics
Crystal Dynamics — Redwood City, California, United States
[12.13.18]

Senior Data Scientist
Nerve Software
Nerve Software — Dallas, Texas, United States
[12.13.18]

Senior Software Engineer
Disruptor Beam, Inc.
Disruptor Beam, Inc. — Framingham, Massachusetts, United States
[12.13.18]

Game Director, Star Trek Timelines





Loading Comments

loader image