Banjo-Kazooie: Nuts & Bolts Developer Diaries

Greetings, Banjo fans.

In a change to our scheduled programming, discussion of Mumbo’s Garage has been cancelled due to poor organisational skills on my part. Instead, the Banjo Physics department (Paul Mountain, Scott Sims, and Robert Masella) have cobbled together a diary entry for your reading pleasure. Well, that’s enough from me, on with the show…

What it is, precisely, that constitutes “physics” in videogames probably means many different things to different people. For the purposes of this almost randomly-structured diary entry (that we’re trying to pass off as an informative article), it concerns the software that defines how inanimate objects interact with one another when left to their own devices, how the vehicles are simulated, and how they behave when the most important element in all games—the player—clasps the Xbox 360 controller in his or her sweaty palms and tries to do something fun and exciting.

Way back in the mists of Nuts & Bolts development history, the game’s designers set out the main vehicle components. To ensure that we’d have the maximum amount of time to assess and develop each of these, we got together as a software team and programmed the basic workings of many of them at an early stage.

Refinement—or iteration, if you want to be all mathematical about it—of the elements that make a game is an essential process in making it fun and rewarding to play. To fulfil these abstract requirements involves a cycle of having an idea, implementing it, testing it, evaluating the results, and then repeating the process. Getting the building blocks of the game in early was a crucial step to allow the whole team to work out how they would operate, look, sound, and interact with other areas of the game.

Before the full-scale work with the blocks got underway, we had begun working on the physics of how different types of vehicles would behave. This included work on vehicles with wheels and research into how things that fly and float in the real world could be simulated in Banjo’s cartoon world. At the start of the project, the decision was taken to use Havok as a basis for all of our game physics, and this proved to be a wise choice as it gave us a flexible and expandable base to work from, as well as some good support from the Havok guys during the project (who can address their envelope stuffed with “thank you for the positive mention” cash to The Banjo Team, Rare Limited, UK).

As soon as we had all of the key vehicle components in the game, it was the perfect time to lock down how we would make these into vehicles. Many hours were spent trying different ways of physically combining the components so they formed a solid shape, known as a rigid body, that could be thrown around the background (background is a term we use for the mostly-static models that form the landscape of the game world). We had to make sure it wouldn’t bring the game to a grinding halt or fall helplessly through the background hits (hits are the physical representation of the game world used to define solid surfaces that can’t be penetrated).

From an editing perspective, part of the solution involved storing information in the components to indicate how and where they could be connected to other components. From a physics perspective, we used this information to determine how vehicles could be broken apart when damaged. Once we had arrived at a solution that we were happy with, we were then able to concentrate on how the combined vehicle behaved. Hopefully, this is all making some kind of vague sense. Hey, you at the back, wake up!

Many of the individual vehicle components are recognisable as real-world parts, while others, such as the grenade turret, are less likely to be found on the average family car—at least in the UK. The instant recognisability of the components allowed us to incorporate some of the relevant characteristics of the vehicles into each of them. This made the game friendlier to play, instead of burdening the player with numerous graphs and charts. Examples of this range from something as simple as a light component weighing less than an equivalent heavy component, all the way up to something like the various powers of engine, each containing all of the information needed by the software simulation of the engine and the gearbox ratios, which remain hidden to the player.

As well as their own specific detailed characteristics, all of the components contain basic information that we could combine to determine how much the final vehicle would weigh and how this weight was distributed, how it would float, and how much drag it would develop while moving.

The combination of components that formed a vehicle now provided a reasonable approximation of what it should be. However, it required many months of further playing and tweaking, trying thousands of different vehicles to arrive at solutions that could successfully unite all of the parts into a fun and playable whole. This can be seen with the change of player controls and camera to match the type of vehicle the player has made or, less visibly, can be felt with the change in engine power when several engines are combined.

Part 2 will follow in a couple of weeks’ time. In the meantime, why not check the latest posts on the Banjo Blog or discuss everything Banjo-related on the new forums? Until next time, be excellent to each other!