Banjo-Kazooie: Nuts & Bolts Developer Diaries

Banjo Dev Diary 1: Cold Pizza in Barn D | Banjo Dev Diary 2: Banjo and the Giant Robot | Dev Diary 3: Putting Words in Banjo’s Mouth | Dev Diary 4: Building the Hub, Pt. 1 | Dev Diary 5: Building the Hub, Pt. 2
| Dev Diary 6: Physics Lessons, Pt. 1 | Dev Diary 7: Physics Lessons, Pt. 2 | Dev Diary 8: Closing Comments

Welcome back, Banjo fans, to our second developer diary instalment with Paul Mountain, Scott Sims, and Robert Masella from the Banjo physics department, which is fast becoming known as the most successful part-serialised written-word cure for insomnia on the Internet. In the first instalment we spoke about how the vehicle components were implemented and how we then solved the problems faced when turning a collection of components into a cohesive vehicle. Get comfortable, grab yourself a pillow, and dare to read on… please!

Once we had the vehicles working effectively and reliably, we began to make a series of changes to shift the physics and control away from their initial simulation-like feel towards a more cartoon-physics approach befitting the Banjo world. Before these changes, we found that vehicles built with, for example, uneven weight or power distribution would tend to topple or spin far too easily. This level of realism was often more frustrating than fun, so a good deal of testing and adjusting took place before we were finally satisfied with the way that vehicles played.

Another important part of Banjo’s design was that the backgrounds shouldn’t simply be full of immovable objects. The designers wanted plenty of things to be breakable, and sometimes usable, to alter the way the game plays. To get this working, a system had to be developed so that our artists could build backgrounds containing these breakable elements, some of which had to be linked to other breakable elements—such as the tree tops in Nutty Acres being connected to their trunks.

Once this was working, it was back to the familiar process of testing and tweaking to determine how long objects should be left in the environment when they were broken off, if or when they should reset back to their original positions, and what physical attributes each object should possess (weight, height of bounce, how easily it would slide or roll, and so on).

The flexibility of the physics system and vehicle construction necessitated advancements in our sound effects software. We soon realised it was no longer enough to use the traditional approach of playing a specific sound for a specific object when it collided with something. We had a situation where the player could create a massive amount of different objects that varied in size, shape, weight and even the materials they were made from.

This led to a long-term collaboration between the physics and sound departments to develop a physics-based sound effects system. The two teams worked tirelessly to produce a system allowing sounds to be grouped by physical attributes and triggered by physical events. This meant that, for example, a heavy metal object falling onto mud would generate its own unique sound. The system also looked at the motion of objects and could detect situations such as dragging, rolling, or toppling.

When approaching Xbox LIVE network games, there were different challenges to the vehicle physics than those for a game being played on a single Xbox 360. Information can be moved at great speeds and with tremendous reliability inside the Xbox 360. When information is sent along a network, the amount of information that can be passed between consoles is affected by lots of different network factors, but is much, much less than what can be moved internally. To ensure that vehicles would still move realistically in a LIVE game, several systems were developed to estimate where other players’ vehicles should be, and to convincingly manipulate them into these positions. A great deal of work was done to ensure vehicles moved effectively in a wide range of networking situations. This included the development of a system that could “push” vehicles into the appropriate position.

To summarise everything in a school essay-like manner, there are many ways to approach developing a game, and there are many different definitions of what makes a game exciting and fun to play. In physics and control, there are always areas that we can look to improve on in the future. But as autumn draws in and the fast food-fuelled late nights fade, we rub our blurry eyes and walk out into the daylight (we haven’t been working late, we just have a really bad diet and rubbish summer weather over here in the UK), and we feel proud of what we have achieved with Banjo-Kazooie: Nuts & Bolts.

We hope that when you’re playing it, the feeling comes across that it was made by people who love playing games for people who love playing games. Thank you for taking the time to read our physics developer diary, and we hope you enjoy the game.

Thanks guys for an excellent diary entry! The game is fast approaching, so you can expect the next instalment in the near future. Feel free to discuss this entry and all things Banjo-related on our forums, and check out the Banjo Blog for all the latest news.

Guh-huh!