Lance Multiplayer Game Server

Extrapolation is a synchronization method where the client predicts the game's future progress in the absence of server data. The client renders steps ahead of the server (e.g., the server is at step 1026 while the client renders step 1030).

When sync data arrives from the server, the client must reconcile its predicted state with the actual server state using a process called reconciliation:

1. Roll back: The client reverts its state to the step described by the server (step M).
2. Re-enact: The client re-runs all steps from M up to the current client step (N) by calling the game engine's step() method. These are called re-enactment steps.
3. Bending: Because re-enactment results in different positions than the original prediction, the client applies a delta (the difference between predicted and actual positions). Instead of snapping to the correct position, the client uses a bending factor to gradually move objects toward the correct position over multiple steps to avoid visual jitter.

Key Implementation Concepts

• Re-enactment: The game engine's step() method must be able to handle being called multiple times for the same step. The step() method receives an argument indicating whether the current call is a re-enactment step.
• Bending: Bending applies to positions and velocities. Designers should avoid bending for objects that teleport or have sudden impulse-based velocity changes.
• Shadow Objects: When a client performs an action that creates an object (like firing a missile) before the server has acknowledged it, the client renders a shadow object to represent that entity until the official server object is created.

Interpolation is a synchronization method where clients render game steps that have already been processed by the server. Instead of trying to predict the future, the client renders a slightly delayed version of the past.

How it works

• The server advances through game steps (e.g., step 1026).
• The clients render older steps (e.g., step 1010).
• Because the client has access to both the current state and the state from a few steps ago, it can interpolate (smoothly transition) object positions between those two points, resulting in visually smooth motion.

Trade-offs

• Advantage: Provides very smooth visual motion because the client always has the 'future' data (relative to its current render step) to interpolate towards.
• Disadvantage: Introduces input lag. A player's input will not show a visual consequence until the client's render step catches up to the server step where that input was processed.

Implementation Considerations

• Tunable Delay: The time delay between the server and clients is a tunable parameter. You should choose the smallest delay possible that still allows for enough sync data to perform interpolation. If network spikes occur, the client may stop rendering while waiting for data; the client should be designed to reduce the delay gradually to recover from these spikes.
• Atomic Actions: Not all game logic can be interpolated. Actions like shooting or bouncing off walls are "atomic" and must be explicitly marked as such to prevent visual nonsense. Interpolation should only be used for continuous state like position or rotation.
• Client Requirements: The game engine does not necessarily need to run on the client if the server sync provides all the information required for rendering.

The GameEngine is the core of your game, running on both the server and the client. The server's execution is authoritative, while the client runs the engine to predict movement.

Registration

In your GameEngine sub-class, use registerClasses(serializer) to register all your DynamicObject types so the Lance serializer can handle them.

Event Handling

Use this.on(eventName, handler) in the constructor to respond to game lifecycle events. Common events include:

• postStep: Runs after every game step (ideal for game logic).
• server__init: Server-only initialization.
• server__playerJoined: Triggered when a new client connects.
• server__playerDisconnected: Triggered when a client leaves.
• client__rendererReady: Client-side initialization.
• client__draw: Client-side rendering loop.

class Game extends GameEngine {
    constructor(options) {
        super(options);
        this.physicsEngine = new SimplePhysicsEngine({ gameEngine: this });

        // common code
        this.on('postStep', this.gameLogic.bind(this));

        // server-only code
        this.on('server__init', this.serverSideInit.bind(this));
        this.on('server__playerJoined', this.serverSidePlayerJoined.bind(this));
        this.on('server__playerDisconnected', this.serverSidePlayerDisconnected.bind(this));

        // client-only code
        this.on('client__rendererReady', this.clientSideInit.bind(this));
        this.on('client__draw', this.clientSideDraw.bind(this));
    }

    registerClasses(serializer) {
        serializer.registerClass(Paddle);
        serializer.registerClass(Ball);
    }
}

The ClientEngine manages the local player experience and must reconcile its state with the server. It operates in two distinct loops:

Client Game Step

Occurs at a fixed interval to process local logic:

1. Check Syncs: Inspect inbound messages/syncs from the server to reconcile the local state.
2. Capture Inputs: Collect user inputs since the last step.
3. Send Inputs: Call ClientEngine::sendInput() to transmit captured inputs to the server.
4. Apply Inputs: Apply those inputs locally to the client's version of the game state.

Client Render Step

Occurs as frequently as the hardware allows to draw the game:

1. Renderer (Draw Event): Triggers the drawing process.
2. GameEngine (Game Step): The GameEngine may execute zero or more steps during a single render event to catch up to the current time (e.g., if multiple physics steps are required between frames). This includes running the PhysicsEngine step.