Refract Studios

Nitronic Rush devs on racing game controls, and building an engine from scratch

Nitronic Rush devs on racing game controls, and building an engine from scratch

Hey guys, Ben here! The team behind Nitronic Rush contacted me about their upcoming racing game, and I thought it looked great. I was a big fan of Nitronic Rush, which is still free if you want to give a try, and the team designed their own engine from scratch and made a pretty remarkable game for students. I invited Jordan to share some thoughts on how they did it, and of course to talk about their upcoming game. Take it away! I recently shared my team’s newest game, Distance, with Ben as we were preparing to announce it publicly. Distance is a spiritual successor to an experimental arcade racing game we released last Fall (for free) called Nitronic Rush. He kindly asked if I’d be willing to reveal some behind the scenes info on what it was like to create Nitronic Rush, as well as things we’ve learned looking back. It was a wild and crazy development over the past couple years, so I’m more than happy to share some interesting things that we found along the way.

Back in the Day

If you haven’t heard of Nitronic Rush, it’s essentially our take on arcade racing games from the 1990s, but with fresh graphics, sound design, and gameplay. Using the car’s many abilities (including boost, wings, and jump), you must avoid obstacles that the city throws at you. It was created as a student game for DigiPen Institute of Technology, where every year programming students are required to build a game from the ground up using no middleware or pre-made engines (aside from a couple small exceptions. The teams can range from 2 person duos to large teams with upwards of 15 people, including full art teams and level designers. Traditionally, your Junior year game ends up being your magnum opus due to the combination of skills you’ve learned so far and the lack of senioritis that hits later on. Nitronic Rush was our Junior year game starting in summer 2010.The team started with only 5 developers, but quickly grew to 11 team members by the time it was released 17 months later on 11/11/11. It’s pretty rare for a DigiPen game to continue development longer than 9-12 months, but our teachers highly encouraged us to continue until submitting to the Indie Game Challenge and Independent Games Festival competitions halfway through Senior year. While it was very time consuming, creating our own engine from scratch allowed us full manipulation and control over the low-level hooks into RAM, graphics memory, and any interfaces we needed between the game and Windows. We had to establish what a “game object” meant to us, such as whether or not it had transformation data by default, as well as how memory was managed in general. If we wanted to load a level in the game, we had to define what a “level” means, how it’s stored (binary, XML, etc.), how it’s loaded (i.e. streaming via threads or via a blocking call), and what interfaces you have to work with in code and in the actual game. Kyle (Holdwick) and I were actually a part of two teams during Nitronic Rush’s development, one of which created Nitronic Rush, and other created a much more poetic experience called Solstice . The Summer before Junior year, we actually took the technical directors from both teams and created a shared architecture called Superdyne that would handle generic game object data, messaging, and eventually larger systems like the audio engine. It was great because the code was tested by both games pretty heavily, and a lot of bugs were eliminated pretty early on in development. Separate graphics and physics engines were written on top of the Superdyne architecture, since each game had very different requirements and there was only enough time to write the features you needed (i.e. bloom, depth of field, and HDR in graphics, or dynamic AABB vs. sweep and prune support in the physics engine). The downsides to creating this low-level engine were mostly in that we were still learning proper code practices, and we rarely nailed a systems design on the first shot. Eventually both games games got to a place where the code felt solid, however in some areas it could act like quicksand for Nitronic Rush while working beautifully for Solstice. In an engine like Unity, all of the low-level functionality is obscured by high-level interfaces, whether through a scripting language like C# or through an menu in the Unity editor. Unfortunately you don’t usually get access to direct memory that Unity encapsulates, so if you need a reference to any data Unity controls you have to hope that an interface is available. On the flip side, Unity has the ability to build a PC, Mac, or Xbox 360 version of the game with a click of a button, which could take us months to implement that kind of flexibility. Both Solstice and Nitronic Rush were bound to the Windows operating system, entirely because we decided to use DirectX for our graphics API and it’s only supported on Windows. Mac support would have required the OpenGL API, which would have required a complete rewrite of the graphics engine and shaders in both games.

Reinventing the Wheel

The most interesting part of Nitronic Rush’s development to me was simply the fact that it was an arcade-style racing game. Actual car racing was something never successfully done at DigiPen before, and when we looked for other small indie teams working on racing games we could only find a handful. We quickly realized that there are only a few companies releasing racing games every year, and many times it boils down to one or two individuals on those teams who really know how what it takes to make driving a vehicle fun. Luckily we had Jason Nollan on the team, who had the persistence to spend nearly three quarters of the game’s development (out of 17 months) iterating on the controls to make them fun while also intuitive and responsive. I honestly can’t comprehend handling the weekly playtesting feedback where no one has a technical solution to their problems, but vehicles are so innate to many that almost everyone can point it out when something feels wrong. Getting the correct feel for car controls generally comes down to implementing a “correct” physical car simulation, and then breaking the physics to the point where it’s predictable but engaging and exciting. For us this meant that Jason not only had to implement a suspension system for the car, thruster simulations for the rotating and flying, and traction simulations for the road grip, but he had to also develop the entire physics engine from scratch. He had to calculate triangle to triangle collision for every mesh in the game every frame, often times using a separate physics mesh from the graphics one so that bumping into objects behaves as expected. Adding new features to the physics engine was tricky because it could require re-tweaking of the controls whenever the car’s physics behaved differently. With the complexity of the controls in Nitronic Rush, he had to also insure that players could react as efficiently as possible since at any moment they could be spinning out, flying, or barely missing an obstacle. You can also easily run into problems with sense of speed and scale when you're trying to build a non-traditional world that can be raced through. In the end it just takes a lot of tweaking and testing to establish a solid relation between objects in the world, especially when moving at high speed. A good example of this is why there isn’t a 3rd person replay system in Nitronic Rush. If you were to pull back the camera enough to see the car in relation to the track, you would instantly realize that the car is essentially a tiny microcar in this world. To put it into perspective, the roads in the game are many times larger than any road in the real world. It ends up being nearly impossible to see the car when it’s moving at full speed.

The Power of Assumption

Experimenting within an established genre like racing was also a surprising challenge. The challenge though wasn’t that racing innovation itself was difficult, it was the combating of player expectations that really made things interesting. We ended up describing the game as an “experimental survival driving game” so that players would (theoretically) be well prepared for that fact that this isn’t your normal racing game. It seemed to work well in our favor since most people in reviews or playthrough videos make a point of bringing it up to emphasize the uniqueness of the game. Alongside the assumption that the game would take place on a looped track, many players would also expect a monumental amount of content to be included. Ironically, Nitronic Rush could quite possibly be the biggest DigiPen game ever made in terms of content (50+ levels with around 3-5 hours of gameplay for many). In comparison to almost any AAA racing game released in the past 10 years it’s a small amount. Most of our players, however, seemed to praise the replay value of the content, especially with the ghost replays. One fascinating thing we discovered was how the concept of racing and driving vehicles is an incredibly universal idea, and it seems to easily translate around the world. People all over seem to love cars and enjoy racing one way or another. Only about one third of the Nitronic Rush player base is actually in the U.S., as the game has been now played in over 150 different countries largely due to word of mouth. It’s been interesting responding to questions and comments when we continued to receive them in so many different languages.

Going Forward

We learned a great deal from every aspect of developing and releasing Nitronic Rush, so we’re excited to use that knowledge to start fresh with a spiritual successor. We're putting more of an emphasis on mystery and a deep atmosphere within the game, encouraging players to explore and discover the backstory of the world. One of the most requested features from our community was multiplayer support, so we’re developing technology to support that right from the beginning.One of our focuses is having a bunch of different and unique modes, such as the Classic Race mode, Stunt mode, Tag, Capture the Flag, as well as a few experimental cooperative modes. We’re also building powerful tools so that we’ll be able to release them with the game. The level editor will be released officially this time around, so anyone can easily create levels and share them with other players from inside the game. With the limited tools provided for Nitronic Rush we saw some incredible levels created, so we’re excited to see what players can do with a much more polished toolset. If you’re interested in learning more about Distance, you can check it out on our recently launched Kickstarter. It’s an exciting time to be developing racing games, and with our community’s involvement we’re beyond excited to see how far we and other developers can take this genre.