At Gamious, we like our games pure, simple and original. So when we started thinking about a cute, top-down, single screen race game, we weren't aware that simplicity was one of the least applicable terms. After two years of developing Team Racing League, we are quite aware (this sentence was written with old Private Ryan's stare on my face).
Team-based games are the cats' pyjamas nowadays. The idea for a team-based racing game was however derived from a frustration we had with existing multiplayer racers. They tend to be less about racing skill and rely heavily on pickups, items and other artificial mechanics to keep everyone (including lesser skilled players) committed. We try to solve this by focusing on the team-based aspect. Lesser skilled racers can still play a huge role in the outcome of the game by supporting their team. Players can connect their vehicle with a teammate to enable boosts or roadblocks (where two teammates connect their vehicles together to form a blockade). They can also choose to troll, block or obstruct opponents with various abilities. This is not to say that a non-racing role is easy. It might in fact be more challenging.
Development of Team Racing League went quite smoothly, and playtesting gave us great confidence that we were onto something here. Teams that work closely together almost always win. Even when they're up against a couple of solid racers. Racing individually doesn't pay off when your adversaries are working together. In Team Racing League, only one racer is needed to secure a first place for the entire team. And winning a few tenths of a second making nicely rounded corner is worth little when you lose five seconds because of a well placed roadblock.
When we were happy with the racing and drifting physics, we wanted to bring the prototype online. Because it's essential to know where all the players are, the whole track is always visible through a fixed camera perspective. This is where we walked into a minefield (or a beach with mines, under constant artillery and machine gun fire).
In an online game you are always confronted with latency, broadband limitations, jitter, etc. Even in the most ideal situation, a package or message still has to be sent from one player's PC to another. (We use Unity 5 + UNET and its relay servers.) We designed the game to be as simple and pure as possible, but some of these design choices turned out to be killing for a smooth online experience.
Where lots of multiplayer games - like most shooters - avoid player collision, colliding into other players is a major part of Team Racing League's gameplay. Not everyone needs to race to win; trolling plays a big part of the fun too. In order to create a playable environment for supporting roles, collisions and timing needed to be very accurate. The game we initially created had very accurate responses to collisions, almost Formula 1-like. A slight bump into the back of an opponent could change its racing line. When trying to sync this behaviour in online multiplayer, it proved too accurate for proper results. Even the smallest delay would give a totally different result on each of the player's screens.
All players always visible
In Team Racing League, you see the complete race track from a fixed camera perspective. All players are visible all the time. This limits the way we can divide bandwidth. In a lot of online multiplayer games like first person shooters, it makes no sense to send player data of players who aren't visible on your screen at that moment. This saves a lot of bandwidth and lets the game focus all of the GPU, CPU and network capacity on the stuff that is relevant for the player. Since we don't have situations where some players aren't visible, we can't use tricks like these. Also, due to the static camera, visual masking is also very hard pull off, compared to fast moving images from a 1st or 3rd person view.
Finding ourselves in this predicament, we decided to look around for help. Luckily, we have a very active and open developer community in the Netherlands. We are based in Haarlem in a gaming hub called Lvlfour, sharing the floor with several other game companies. Together with Joost van Dongen (lead developer at Ronimo Games) we hosted a coders meetup at our hub. Over thirty devs from all over our little country attended, amongst others the networking specialists of Curve Fever, Besiege, Speedrunners, Tricky Towers, Volo Airsport and Awesomenauts. We shared our Team Racing League experiences and issues, talked intensively about possible solutions, and discussed general multiplayer issues. Besides the big meetup, we also visited some of these studios for more in-depth one on one sessions.
These meetups were extremely helpful. In general, it is nice to know you're not alone in this and that others have travelled the same bumpy road. While every game comes with their own specific obstacles and needs, the limitations are the same for all of us. The one thing that stood out from the meetup and the individual talks we had with other devs, is this: don't try to create a perfect smooth online experience; create an online experience that seems smooth for the players. It's all about masking.
In order to deal with the collision issue, we decided to make adjustments to the gameplay. We threw away our original theme - racing in regular cars - and went for a more futuristic theme with hovercrafts instead (a setting that suits the mechanics better anyways). We rewrote the physics and made the collisions less subtle. By increasing the impact of collisions, the gameplay got a bit more chaotic, but we were able to make impacts consistent to manage player expectations. It's a good fit with the party nature of the game, and due to the introduction of hovercrafts, the chaotic collisions and physics are way more believable now. We also implemented various visual masking effects, like chromatic aberration, light flares and sparking particles, so that there is a lot going on when colliding.
Keeping the whole track and all players visible at all times is something we wanted to keep intact. We believe that players need an overview of the entire race to anticipate on changing situations. We did make some adjustments to the player's abilities to mask potential lag. For example, when activating anchor mode (the ability to lock your hovercraft into the ground to become an obstacle), we check the player's ping and process this into the default start-up delay for activating the ability. When a player presses a button, we immediately play a sound and visual effect. After the delay is over, we activate it. This delay gives the server some time to process the player input and push the results to all other players. During the delay, a start-up animation and sound effect provides the player with a feeling of instant responsiveness.
Adding online multiplayer to your game will make everything much and much more complex. Without online multiplayer, the game could have been finished over a year ago. When you do want online multiplayer in your game, start thinking about the possibilities and limitations from the creation of your first prototype. Designing, playtesting and balancing a game before you work on getting this experience online will force you to make a lot of difficult choices and compromises to the original design. Besides losing precious time, you might also have to say goodbye to some really cool gameplay ideas. In the end it was a long but rewarding road for us. And hopefully Team Racing League's road to success is far from over.