Entity Component System, rollback netcode

This post highlight some of the code features behind-the-scenes of the development of this game.

The game is written from scratch in JavaScript, no engine was used, although several library helpers were chosen.

The engine uses an Entity Component System, which provides good performance behind the scenes. Each JavaScript object is referenced by an ID, which points to a spot in an array of strongly-typed data. This provides a good way of splitting game logic and data.

Most of the game logic is stateless aside from the ECS arrays, which provides a neat way of ensuring that the game is deterministic by default. Calling Update() multiple times will always have the same result, given the same input. And rendering can happen independently of game logic.

This greatly assists in the ability to have rollback netcode. 

Rollback is implemented where each player's inputs are synced across the network, each player predicts their inputs locally and a server (the host) reconciles any differences.

Since the game state is almost entirely based on the "Components" data structure, it can seamlessly load an old or new state by simply replacing that data structure, then rolling forward using either predicted or real inputs.

While hosting a game, the host essentially runs 2 copies of the game in real time, the server which is the authoritative version of the game, and the host, which is a client connected to the server.

While this was developed quickly for the game jam, this proves as a nice proof-of-concept. To iron out bugs, and to handle clients having mismatching frame rates, the server can sync client game state by simply serialising the ECS data it has, and hot swapping it on the client-side.