Dev Story: ‘Radial-G : Racing Revolved’ – 32-players in One Race
This guest post was written by Sam Watts, Game Producer at Tammeka Games.
Tammeka is a new indie start-up, focussing on VR games first and foremost. Formed in early 2014 by ex-developers from Black Rock and NCsoft, having previously worked on AAA games titles such as Pure, Split/Second, Moto GP, Guild Wars, Aion and City of Heroes. Other members of the team come from a serious 3D & VR simulation background, bringing years of experience developing high-fidelity, rock solid immersive environments for the pickiest of clients.
‘Radial-G : Racing Revolved’ is a high-octane futuristic arcade racer that pits upto 32 players against each other in sci-fi races online. Supporting normal monitors and Oculus Rift headsets, Radial-G sets out to bring the spiritual successor to games like F-Zero and WipEout bang up to date for the current generation.
Don’t miss to grab your seat in Radial-G Steam Early Access.
A 32 player Racing Game
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 multiplayer 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 Multiplayer 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 multiplayer 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 multiplayer 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.
Using Photon PUN Service
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).
Testing
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.
Future & 32-Player
We are now focussing on our Steam Early Access release and the ability to monitor a wider-scale test with greater numbers of players. You can get involved here: http://store.steampowered.com/app/330770/
Additionally we envision multiplayer gameplay with 32-players and achieve the same level of gameplay smoothness we have achieved for 16. Interest Management will not work then anymore (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.
Feel free to get in touch with any questions: sam
