Backdash Rollback Netcode

Backdash is a multiplayer network SDK designed to implement Rollback Netcode in games using C#, F#, or any .NET dialect (such as Godot, MonoGame, or Stride3D).

Core Concept: Rollback Netcode

Unlike traditional delay-based networking that waits for all player inputs to arrive before advancing a frame, rollback networking allows the local game to proceed immediately using local inputs. If remote inputs are missing, the SDK predicts them based on previous behavior. When the actual remote inputs arrive, if they differ from the prediction, Backdash triggers a re-simulation from the point of divergence to the current frame to ensure all players remain synchronized.

Integration Requirements

To use Backdash, your game engine must be fully deterministic. You are responsible for implementing three core functionalities that Backdash will orchestrate:

1. Save State: The ability to capture and store the current game state.
2. Load State: The ability to restore the game to a previously saved state.
3. Execute Frame: The ability to run a single frame of game logic without rendering the output (used during re-simulations).

Backdash uses a combination of frame delay and speculative execution to manage network latency.

• Frame Delay: The number of frames you choose to delay input. Increasing this can reduce the frequency and visual impact of rollbacks (glitching), but adds perceived input lag.
• Speculative Execution: If the network latency exceeds your specified frame delay, Backdash uses speculative execution to predict and hide the remaining latency.

Tuning Recommendations

• Fighting Games: Require high precision. Keep frame delay low (e.g., 1 frame) to avoid affecting timing-sensitive mechanics.
• Board/Puzzle Games: Can tolerate higher frame delay (e.g., 4-5 frames) to provide a smoother experience with fewer rollbacks.
• Visual Glitches: If short-duration visual effects (e.g., a 2-frame screen flash) are being 'consumed' or hidden by rollbacks, increase the frame delay or redesign the renderer to delay the effect until after the potential rollback window.

The SpaceWar sample demonstrates P2P connectivity over the internet using UDP hole punching.

Core Workflow

1. Middle Server: A central server (LobbyServer) acts as a signaling mechanism. All clients connect to this server, which is known to all participants.
2. Signaling: The server captures the IP address and port of each client and shares this information with other peers in the lobby.
3. Authentication: When a client joins the lobby, the server issues a Guid/UUID token used for basic authentication.
4. UDP Hole Punching: Once logged in, clients send a UDP packet containing their token to the server. The server uses the packet header metadata to track the client's public IP and Port.
5. Local Network Mitigation: Since UDP hole punching often fails for clients behind the same NAT, the server also tracks local IP and port information to detect if peers are on the same local network.

Communication Protocols

• HTTP: Used for lobby management and retrieving peer information via HTTP pooling.
• UDP: Used for the actual hole punching and peer-to-peer signaling.

For rollback to work, the next game state must be computed solely from the current state and inputs. Avoid these common pitfalls:

• Random Number Generators: Use a deterministic RNG. The seed must be identical for all players at frame 0, and the RNG's internal state must be part of your saved game state. Backdash provides a deterministic RNG via session.Random.
• External Time Sources: Avoid using system clock or real-world time in state calculations, as clocks are never perfectly in sync across machines. If time is needed, include the time as part of the frame input.
• Dangling References: When implementing save and load, ensure you are copying values rather than object references. Rebase pointers correctly during the load process.
• Static/Hidden State: Avoid static variables in C# or C. All state must be part of the serializable game state. If you must use a global static, you must manually sync it during the LoadState callback.

Backdash requires you to implement SaveState and LoadState in your INetcodeSessionHandler to manage rollbacks.

Using BinaryBufferWriter/Reader (Default): Use the provided BinaryBufferWriter in SaveState to write state members, and BinaryBufferReader in LoadState to read them. ⚠️ IMPORTANT: You must read and write members in the EXACT SAME ORDER and ensure the same data sizes (e.g., for arrays/lists).

Using Custom Serializers (e.g., MemoryPack): You can bypass manual member writing by accessing the underlying buffer. Use writer.Buffer in SaveState and reader.Buffer in LoadState to integrate with third-party serialization libraries.

// Example using manual binary writing
public void SaveState(in Frame frame, ref readonly BinaryBufferWriter writer)
{
    writer.Write(in currentGameState.Value1);
    writer.Write(in currentGameState.Value2);
}

public void LoadState(in Frame frame, ref readonly BinaryBufferReader reader)
{
    reader.Read(ref currentGameState.Value1);
    reader.Read(ref currentGameState.Value2);
}

// Example using MemoryPack
public void SaveState(in Frame frame, ref readonly BinaryBufferWriter writer)
{
    MemoryPackSerializer.Serialize(writer.Buffer, currentGameState);
}

public void LoadState(in Frame frame, ref readonly BinaryBufferReader reader)
{
    MemoryPackSerializer.Deserialize(reader.Buffer, ref currentGameState!);
}

While Backdash automatically serializes primitives and enums, you must implement IBinarySerializer<TInput> for complex input types that require Endianess conversion support. The most efficient way to do this is by deriving from BinarySerializer<T>.

When implementing, you must override Serialize using a BinaryRawBufferWriter and Deserialize using a BinaryBufferReader to manually handle each field of your input structure.

// 1. Define your complex input structure
[StructLayout(LayoutKind.Sequential, Pack = 1)]
public record struct MyPadInputs
{
    public PadButtons Buttons;
    public byte LeftTrigger;
    public byte RightTrigger;
    public Axis LeftAxis;
    public Axis RightAxis;
}

// 2. Implement the serializer
public class MyPadInputsBinarySerializer : BinarySerializer<MyPadInputs>
{
    protected override void Serialize(in BinaryRawBufferWriter binaryWriter, in MyPadInputs data)
    {
        binaryWriter.Write((short)data.Buttons);
        binaryWriter.Write(data.LeftTrigger);
        binaryWriter.Write(data.RightTrigger);
        binaryWriter.Write(data.LeftAxis.X);
        binaryWriter.Write(data.LeftAxis.Y);
        binaryWriter.Write(data.RightAxis.X);
        binaryWriter.Write(data.RightAxis.Y);
    }

    protected override void Deserialize(in BinaryBufferReader binaryReader, ref MyPadInputs result)
    {
        result.Buttons = (PadButtons)binaryReader.ReadShort();
        result.LeftTrigger = binaryReader.ReadByte();
        result.RightTrigger = binaryReader.ReadByte();
        result.LeftAxis.X = binaryReader.ReadSByte();
        result.LeftAxis.Y = binaryReader.ReadSByte();
        result.RightAxis.X = binaryReader.ReadSByte();
        result.RightAxis.Y = binaryReader.ReadSByte();
    }
}

// 3. Register the serializer with RollbackNetcode
MyPadInputsBinarySerializer mySerializer = new();
var session = RollbackNetcode.WithInputType(t => t.Custom(mySerializer));