Upgrading to Unity 5: Freejam's story

Upgrading to Unity 5: Freejam's story

By Brian O'Connor, Freejam Games

January 26th 2016 at 12:05PM

The Robocraft studio's co-founder and senior coder discusses the biggest hurdles devs may need to overcome when switching engines

When the Freejam team made the decision to upgrade from Unity 4 to 5, I took the lead on this with more than a little trepidation but with genuine enthusiasm for the new features on offer. I managed to keep this enthusiasm alive for the next three months it took me to actually make this happen. While the rest of the team were turning out new features Unity 5 was my pet project.

I wanted to release the port to Unity 5 in one of our regular updates and my goal was to disturb the player base as little as possible. Since moving to Unity 5 meant moving from PhysX 2 to PhysX 3, and Robocraft is such a physics-heavy game this was not going to be a simple task.

In Robocraft, we let players build any robot they like: their choice of movement type, shape and size all play a big role in how their robot handles and players have a huge amount of freedom in how they construct their machine. As soon as I’d installed the new version, I found that most robots I built worked just fine. However, not all of them did. The problem was that Unity 5 had reinvented the wheel.

The Wheel Collider in Unity 4 were a steadfast fellow that you’d depend upon, but perhaps was a little dim. They weren’t perfect - the friction doesn’t like to play ball, the suspension never really worked and the amount of torque you applied didn’t always give the results you were hoping for. But they worked. Whatever you threw at them, they worked. When we decided it would be fun to add tank tracks in the game we simply strung several of them together in a line, no problem. When we had to implement sleds then we turned to the Wheel Colliders again.

Moving to Unity 5 meant moving from PhysX 2 to PhysX 3, and Robocraft is such a physics-heavy game this was not going to be a simple task.

However, the Wheel Collider in Unity 5 is a different animal. Wonderful but delicate. All of a sudden my tank tracks only want to go forwards or backwards and my dancing sleds have turned into bricks. What followed was a long process of rebalancing, far longer than when I initially developed these types of movement.

Don't get me wrong, there are some excellent tutorials on how to setup the new Wheel Colliders and if you follow these closely you’ll have a great car at the end of it. The problem for me came when I couldn't follow these steps exactly. When you get into the weird and wonderful like in our game, that’s where you’ll get problems.

Our players can make feather light drag racers with over twenty wheels or huge tanks that trundle along with only three. They have agile sleds powered by rockets or racer-flyer hybrids. The new wheels are certainly no worse than the old, just Robocraft is putting some very heavy demands on them.

With QA’s patient feedback, some liberal hair pulling and no small amount of resilience I did arrive at a place where I am happier than ever. The types of movement work wonderfully, I’ve got better control than ever on how the wheels act and feel and that temperamental suspension is (finally) behaving itself.

Another big feature we took advantage of was UNET, Unity’s new networking framework. We already used Unity’s low level networking API so we were quick to adopt the new framework.

Initially UNET was quite simple to implement. Having switched out the API calls and removed the obsolete networking code everything was working just fine – until mass testing started, that is.

Since porting to Unity 5, there’s been a noticeable improvement in frame rate, with the profiler showing a 20 per cent reduction to CPU time spent on rendering and physics.

After getting upwards of fifteen players into a game, things started to fall apart. Admittedly, as it was now getting close to launch time this was an unwelcome surprise. However, you're provided with a good selection of network parameters to tweak in UNET so the launch was soon back on schedule.

Now admittedly, my goal of making the game feel exactly the same as in Unity 4 wasn’t completely realised, but where I couldn’t keep a robot’s handling feel exactly the same the changes were an improvement. I’d like to say the forums were alive with praise and positivity after the update, but players were pretty quiet on the gameplay changes. Let’s call that a success.

In fact, we gained a lot of successes from porting to Unity 5. There’s been a noticeable improvement in frame rate, with the profiler showing, in some cases, a 20 per cent reduction to CPU time spent on rendering and physics. We also now have a better collection of standard assets and shaders and a host of new animation features.

I also found that in coding terms there were a number of places where Unity 5 forces good practices. Which is important when you have a big team working on shared code.

So, while it was a lot of work, I found the port to Unity 5 was well worth my effort. I can see the new, softer bloom making my world a little rosier and watch my robot’s suspension finally oscillating beautifully.

Brian O'Connor is co-founder and code jammer at Freejam Games. He works on popular robot fighting and crafting game Robocraft. Before coming to sunny Portsmouth and Freejam, he worked for multiple developers including Climax Studios and Stainless Games.