This is the first part in a series of posts about the networking architecture for Dragon Saddle Melee.

Background

Dragon Saddle Melee is a solo-dev PC game inspired by the classic game, Joust. DSM was designed from the beginning to be multiplayer -- even when played in solo mode, the client is running the server code locally and connecting to it. I figured that since online multiplayer was so important to the project, it would be best to tackle those technical challenges first instead of trying to retro-fit the game for multiplayer later on. This led me to learn about networking techniques. In these blog posts, I’ll attempt to walk through some of the challenges and design decisions encountered in making DSM. Hopefully it will be helpful to some other fellow netcode newbs out there.

Resources

DSM’s networking implementation was influenced by three great sources:

• The 2018 GDC talk “It IS Rocket Science!” by Jared Cone. This talk is excellent and Rocket League shares the same fundamental problem with DSM of synchronizing multiple physics simulations across the internet.

• The 2017 GDC talk “Overwatch Gameplay Architecture and Netcode” by Timothy Ford. Again, another excellent talk with great animations showing how player inputs move across the internet and how problems like packet-loss and mis-predictions manifest to the player and are minimized.

• Glenn Fielder’s series of blog posts “Networked Physics”. These posts are incredible, especially how he walks through a series of solutions to the fundamental problem of networked physics to arrive at better and better results.

The Fundamental Problem

The core technical problem DSM needed to tackle was how to sync the states of multiple physics simulations that all have slightly wrong views of the simulated world; except for the server -- it has a perfect view of the world because DSM is a server authoritative game.

Breaking down this problem further, each client is pushing buttons on their controller that fly their little dragon around. These inputs result in forces being applied to the physics object that represents their dragon. Each client also receives from the server the inputs the other players and AI dragons are creating. That’s when the problems start because of latency. A client’s commands take time to get to the server and even more time to be relayed by the server to the other clients in the game. Also, packet-loss could cause some inputs to get lost. They could also arrive in a different order than they were sent.

Priorities

Unfortunately, there is no perfect solution to this problem -- latency and packet-loss will negatively impact the game. However, we can prioritize the ways in which they impact the game. Players can perceive some imperfections in the simulation much more than others.

Priority #1 -- The locally controlled object

The highest priority is to minimize disruptions to the locally controlled physics object on any given client. If I’m sitting at my computer and push the flap button on the controller to propel my dragon upwards, the networking system should prioritize making that look as flawless as possible. Nothing will be more noticeable to a player than seeing his own dragon’s movement stutter and hiccup.

Priority #2 -- Everything else

The next highest priority is updating every other object as soon as we get updated information from the server. There’s no way to avoid the delay from the server to us containing new information. So, the only option is to re-update our simulation as soon as possible with the new information.

Next Up

That wraps up the first post in this series. In the next post I’ll talk about the specifics of the networking architecture implemented in Dragon Saddle Melee.

Chris

Developer of Dragon Saddle Melee

Co-Founder of Main Tank Software

February 22nd, 2022