As 2014 is coming to a close, and it’s a week since the release of “Radial-G : Racing Revolved” on Steam Early Access, it’s time to look back at the rollercoaster ride we’ve had getting to this stage, and specifically, how we have utilised the Unity3D engine from Unity Technologies to get here.
The Beginning

When we received our Oculus Rift DK1 headsets from backing the hugely successful Kickstarter, we knew immediately that we could make something amazing with this new technology. We have been working with Unity for years already and had created a number of serious, non-game-related applications and experiences for clients and customers worldwide. Since Oculus Rift development supported Unity3D from the outset, it was an easy choice to carry on building upon our previous Unity3D experience and make a series of virtual reality (VR) experiences.

We started off by finding our feet with the early beta SDKs from Oculus VR by converting some of our existing content made in Unity3D to work with the Oculus Rift, something which is simple, easy and quick to do. However we quickly learned, and were aware of already from designing 3D and VR simulations for other hardware devices, that you couldn’t just drop in the plugin and expect a silky smooth, non-simulator sickness inducing experience, you had to carefully design from the ground up for VR.

So after a couple of wobbles and queasy stomachs, and remembering to sit down when using the Oculus Rift, we set about designing a game for Oculus Rift from the ground up, bringing together our previous experience of AAA game development and rock-solid 3D simulators. We wanted to create something as exciting and exhilarating as the Oculus Rift itself, and based on the team’s love for and past history pedigree with racing games, we knew an arcade racing game was the direction to go in. (Side note: members of the team previously worked on Moto GP, Pure and Split/Second at Black Rock Studios.)

When one thinks of an arcade racing game, you think of speed and thrills over authenticity and the ability to use artistic license with reality, so we looked at classic sci-fi racers from the past as our starting point for inspiration. The obvious titles that spring to mind are F-Zero, WipEout and Extreme G to name but a few. We wanted to recreate the essence of these classic titles, especially since they haven’t been updated for many years and in some cases, the studios responsible for them no longer exist 🙁

We set about examining what made each of these games great in their own right and took the elements that we thought would work in VR, and lo, the early concept for Radial-G : Racing Revolved was born.

Design & Development With Unity3D for VR

Prototyping and developing a game, or application, with Unity3D is quick and painless thanks to being able to play the scene within the editor without need to compile a build each time to deploy. Thankfully the engine also supports Oculus Rift headsets so we can test VR within the editor too seamlessly. This saves us a lot of time as we designed Radial-G to work with and without an Oculus Rift, since we wanted to capture as large a potential user base of gamers as possible. Being a development kit only at this stage, we knew that there weren’t that many Oculus Rift headsets out there in the wild and so, in order to be successful, we had to design the game with VR in mind but also ensure the normal, non-VR experience was still as much fun and attractive to gamers.

Since we were designing a racing game based on a tubular track (hence the name), there were a number of design considerations we had to take into consideration in order to ensure that the gameplay didn’t make players instantly sick from motion sickness, and make sure that the engine and performance didn’t jitter or stutter, dropping below the prescribed frame rates so as not to induce simulator sickness.

Some of the design decisions and factors we could actively control and make are detailed below:

• Place the player in a sitting position so they are stable and steady as possible to begin with – this is the best way to use the Oculus Rift, since without real world visual feedback, balance is quickly lost.
• Place the player in a cockpit to position them in a situation they would expect to be in – this in conjunction with the above, provides a natural connection between brain and senses.
• Use futuristic, non-real-world environment to help the brain determine the difference between the game and real world – allows the brain to switch-off and have fun.
• The pipe track asset provided a natural, stable element within the game world players could focus on.
• Limited rapid changes in acceleration; despite the inclusion of speed boosts and slow-down gates, the overall difference in the sensation of speed experienced by the player wasn’t huge.
• Being in a ship attached to a pipe meant there was a natural limit to player [camera] movement within the game world – but they can still naturally look around the world and cockpit with smooth judder-free performance.
• Carry out extensive playtest sessions with as many different types of user as possible to measure responses, ability, ease-of-use and any sensations of sickness brought on through play – to date we’ve seen over 2,000 players, only 30 or so have had to stop within the first 20-seconds “hump”, after which the body accepts VR.

There were a number of factors that, as developers and users, were beyond our control since the game would be played by gamers all over the world:

• Allow configuration for each individual user – although since then the Oculus Runtime tools have improved to make individual profiles and Interpupillary Distance (IPD – the distance between eyeballs) measurements easily.
• Ambient temperature of the play space – it could be a basement, bedroom, lounge, located anywhere!
• Varying ages of gamers playing the game – age affects responses and reactions to VR (although we’ve seen 88-yr old grandmas playing for over 30 minutes without discomfort).
• Varying health status of players – stereotypes of gamers aside, health conditions affect responses and reactions to VR and suitability of use.

Thanks to the rapid pipeline of development, we were quickly able to implement new ideas, test them out and then cement their inclusion and move on.

The other benefit of using Unity3D is the wide range of additional assets and plugins available to further expand the toolset and options open to us as developers. We took a simple plugin called Curvy and vastly expanded upon the capabilities for our needs and purposes. Now we can add additional track features, as seen in the Steam Early Access version, such as jumps, tunnels and splits to the tube, a far cry from the simpler version of tracks we included in the initial single player demo (available from our website to download for free) and we’re not done yet!

Another great piece of middleware we utilised is the Photon Unity Networking plugin, which gives us online multi-player servers and allows to continue working towards our end goal of supporting up to 32 players. Currently we are able to support up to 16 players online for the Steam Early Access version working within the PUN limitations. Based upon our pedigree and in-house love of the genre, a racing game was destined to be the focus of our first title. When we started out designing and deciding what we wanted from our 1st arcade racing game title, Radial-G : Racing Revolved, we knew that online multi-player was always going to be a key factor in the game features list. Considering the game is influenced by past greats such as F-Zero and WipEout®, we wanted to replicate that feeling of a busy track with a large pack of racers battling it out against each other. Therefore from Day One, we aimed for and stuck our necks out stating that we would support up to 32 players. This raised a few eyebrows amongst our fellow Unity developer fraternity, since many of them didn’t believe that it could be done.
The Multi-player Challenge

Based on the challenge set and accepted by some of our peers, we were keen to work with suitable middleware to remove a lot of the grunt work required for multi-player code and stable, smooth gameplay for all players. Therefore the PUN service from Photon seemed a perfect fit for our needs. We were looking for a scalable solution to meet the demands of our players, as our user base increased in size accordingly.

Being a new, unknown indie developer, we can only project our CCU and take up rate amongst gamers and so have started out conservative, with hopes of great success in our minds for the future.

Although we initially stated we would support 32 players online, we are focussing on 16 for our Steam Early Access release; still not a number to be sniffed at. A number of AAA console racing games still only support up to 8 players online, or 12 with only recent new-gen games supporting 16.

Looking at the typical traffic for a multi-player racing game, and the natural emphasis on the start being crucial for a race, we have to carefully balance out the allocation of messages per second accordingly to ensure that each player has an even, equal experience without any lag or latency to ensure smooth gameplay and a feeling of fairness across the grid.

The busiest time for a race is the start, when all players are located close together, fingers itching on the trigger to accelerate off the grid as soon as the light goes green. Furthermore, because we have tested and confirmed that we can include collisions in virtual reality without causing motion sickness from unexpected impacts, it is even more important that all players are able to get away from their starting positions without stutter, causing unnecessary, unfair impacts to other racers. We all want a clean race after all (at least until we add weapons). To simplify issues however, we decided to go with “bubble shields” so there’s less geometry and less collision calculation data to pass around in order to smooth the experience out for all players. Being sci-fi based, we can get away with that.

Sending everything to everyone in a 16 player game would lead to an overload of data and would potentially overload the clients. With 10Hz it would be 10 * 16 * 16 = 2560 messages per second per room. For this reason we decided to incorporate region-based interest management to group data and messages depending upon the player location on the track compared to others.

At the start of the race, we have 3-5 seconds of this super high data rate but gameplay tests and evaluations have shown that players soon spread out. Also with the tubular track, we are able to switch quickly to the medium group when an opposition player is on the other side of the track from the player. Over the course of a race, over a number of laps with the field spreading out, we remain within the average 500 messages p/second requirement as a result. We achieve this average through only switching to high data at the start when the last light has gone green and as soon as a player crosses the line and finishes, we stop sending any data to remove as much redundant data as possible.

Whereas a 2D game will use a grid system for this, as we are dealing with a tubular track, we work with a long line of boxes with high / medium / low-data-rate groups in order to best represent each player to one another accordingly. This means that players closer to each other will fall in the high data rate group, since you want to be able to see players ahead of you without any jitter or bouncing around the track, making the gameplay experience poor, since it makes it hard to time overtakes when you can’t accurately determine where that opponent is at any given time.

Opponents that are further up the track, just within sight but not within overtaking distance, will fall into the medium data rate group since they can be represented on track off in the distance accurately but without the need for complete precision.

Finally, opponents who are out of sight fall into the low data rate group since it is not important to the player where they are and how they are represented, but of course the game and server needs to know their current position on track to determine player order and timing.

We achieve all this with the limit on messages per second through clever management of the groups and spatialising the track into segments, based upon the percentage of completion of the track, from 0% (the start line) to 100% (the finish line).

So far we have been able to test our 16-player online support and have seen that the game operates smoothly when players connect to a region server most suited to them specifically. We’ve tested with “foreign” connections, i.e. players in Australia connecting to EU servers, and whilst the player ping rates have increased, we haven’t seen a hugely detrimental, negative effect on the overall race experience. Certainly nothing worse than your average online race experience with some of the greatest AAA console racing games, with cars popping in and out all over the track causing havoc for other racers.

We are now focussing on our Steam Early Access release and the ability to monitor a wider-scale test with greater numbers of players.

Additionally we envision multi-player gameplay with 32-players and achieve the same level of gameplay smoothness we have achieved for 16. Interest Management will not work then any more (the high data region with 32 players) and we plan to implement message aggregation: Combine each player messages into one super message and pass these between all players simultaneously. Operating at our standard 10 Hz, this would give us the same result with 16-players but for 32.

However, this feature is not implemented in the Photon Cloud turnkey APIs and we would need to convince the Exit Games crew to implement this or host our own Photon Servers. This is something we plan to evaluate once we have been able to determine our success levels in Steam Early Access as we move towards full, public release early next year.

Since launch we have also implemented a version that operates over a LAN, utilising a localised installation of the PUN Server so we can continue to demonstrate the game at events with multi-player without the need for Steam servers or internet access, which is nice.

Events and Appearances

Not directly related to game development or using Unity3D but showcasing the game during development and after release is an important part of the PR, marketing and raising awareness of your title to the gaming public. Unity3D allowed us to tweak and customise builds for specific events quickly and easily so we could showcase specific new features or elements at each event.

Over the course of 2014, Radial-G has appeared at the following events:

VR Brighton Meetup – numerous times, a great local testbed for us with VR enthusiasts
South West VR Meetup – as above, good to spread the VR love and word
VR in a Bar – Loading Bar in Dalston, London, was kind enough to invite us along to their first VR event where we got filmed by S4C!
Develop Conference Expo – a great opportunity to get the game in front of peers and players, and we met Shuhei Yoshida, President of Sony PlayStation Worldwide Studios, who is now assisting us with bringing the title to Morpheus / PS4
Kotaku-UK / I. Am. Arcade / Fight Club – a local bar in Brighton, Sticky Mike’s Frog bar, holds monthly gaming meetups and there’s nothing we love more than the competitive nature of gaming, and beer
Paris Games Week – thanks to Microsoft, Asus and CDiscount, we were able to appear at one of the largest gaming events in mainland Europe
PAX Aus – thanks to Evocca College, we were able to appear at the largest Australasian gaming event

The Future

Thanks to Unity3D, we are in a position where we can optimise and target all the major platforms for release from one main branch of development. Looking ahead to 2015, we’ll continue our discussions with Sony PlayStation to bring the title to Morpheus and PS4. The IDXbox programme is an attractive with free dev kits available to small studios and assistance with licensing for publishing. Samsung Gear VR will be out in the UK and we can look at a lite / heavily optimised version of the game for mobile VR, which could then lead onto a non-VR version for Apple and Android tablet devices as well. Who knows, watch this space.