PacketZoom Blog Providing Your Players with a Balanced Real-time Experience in Multiplayer Mobile Games

Insights and Best Practices from an Independent DeveloperFrom trying different products and working through the kinks of implementing online functionality in my games, I found insight to the haunting effects of an unsatisfactory networking structure.How I Jumped Into Online Game DevelopmentOn a Thursday afternoon back in April 2018, I was exploring the booths at the Game Developers Conference in San Francisco. I came across a booth with a small, yet very energetic team. The company behind the booth was PacketZoom - where, little did I know, I would be working at the following month. The services provided were promising - as a college student, independent game developer, and complete novice in the world of online game development, the idea of a strong custom protocol to include in my games intrigued me.Fast forward a few months and I found myself developing a mobile real-time multiplayer game called PacketBall from scratch - using PacketZoom's new mobile networking product Mobile Connect. From this firsthand experience, I witnessed what really goes on behind the scenes when making a networking protocol. In my situation particularly, development cost and time to market would possibly be extended by years if I chose to try and build a similar networking protocol myself.Why Good Online Multiplayer MattersYou've been there. You boot up a multiplayer game on your mobile device, ready to jump into the fun, and just when you're about to make a critical move... you face game-breaking lag and the experience is ruined for some or all players involved.A ball misses a goal. A bullet misses its target. A countdown skips a number. In many cases you as a player know that this hiccup is not your fault, but a result of a game sync issue, which makes it even more infuriating.Perhaps in an intense session-defining moment, the ball teleports just outside the goal posts, the bullet doesn't fire when the button is pressed, or the countdown to the race shows the wrong number. This is not a fun experience for anyone. If you as a player feel such frustration, why would you as a developer make a game that results in players feeling a similar way?These errors can be the result of incorrect or less-than-stable protocol implementation. Even if an error lasts for only a fraction of a second, it doesn't matter. The entire enjoyment of this experience can be crushed in this short moment.As an active player and a game developer myself, I have experienced these frustrations firsthand from both sides and am more than happy to share my personal insights.There are two major networking-related factors to keep in mind when developing a mobile multiplayer game. Of course, the first factor is the actual code-related infrastructure. However, we should also pay attention to the design aspect. The often overlooked component of making a balanced online experience is deciding when and where networking actually matters.An ExampleLet's look at an example. First of all, we must know our two big terms. We have a client - a device/player running the game - and the server - common to all clients, syncing the game's objects on what can be referred to as your game's "cloud". The scene above is taken from a popular military shooter. In some levels there are sandstorms that sweep through the battlefield, which challenges the players to battle it out with one another, all the while handling an obstructed view from the storm.However, this sandstorm would need to obstruct everyone's view in the area, as a real sandstorm would. Not synchronizing this sandstorm on the server-side leads to massive imbalance issues. As seen in the images above, Player B (right side) has an unfair advantage against Player A (left side), while Player A struggles to fight Player B with virtual sand in their eyes.Even More ExamplesIn the diagram above, client 1's arrow hits its target on their device; however, client 2 dodges the arrow on theirs. Network failures caused client 1 to see the arrow in the wrong place. To keep things balanced, the arrow and the players' characters are objects that should have been prioritized with the server.Here are some other examples of various items in a game that developers should include on the server's side:Vehicles that players can drive around with or in the view of other players.Breakable environments, such as falling buildings - if the player can interact with them (i.e. climb them, can't get around them, etc).Positions of players and enemies (very important in particular to be reliably translated across clients).The sun and moon in games where day turns to night and night turns to day. Players need to be able to see each other and objects with the same clarity during each level of brightness.Effects, such as explosions or fireworks.Many more items, much of which is up to the developer's discretion.Here are some game elements that developers may want to keep out of the server code, keeping them on the client's side. These don't need to be communicated to other players, as they don't affect the balance of the game:Static environment that is never moving, and the same among all clients, such as rocks and buildings that never move."Non-player characters"; These static characters, such as a shop-owners or "quest-givers" have positions that do not need to be synced if they are in the same location for every player.The sun and moon objects only if they are "static" and either never move, or move the same way for both players.Visual effects that are in large quantities and would bog down the servers if tracked, while they could just be random. Examples; rain, waterfalls, sparks.Now that we know where we should have our network code in place, making these implementations strong is where the real difficulty comes in.Mobile Connect helps provide a way to deal with the technical aspects of networking in your game. This results in players being less frustrated in their time with your game and you having the time to spend on game optimization to build a spectacular online experience.Mobile Connect is currently in closed beta - click here to learn more.