Address
Utrecht, Veenendaal

Work Hours
Monday to Friday: 9am to 5pm
Weekend: 10am to 5pm

Networking Game Engine

A personal project: a reusable networking engine for browser multiplayer games. Photon Realtime for transport, a Node.js server holding the authoritative state, and a client framework a game is written against.

  • TypePersonal project
  • Period2020
  • RoleSolo design and build
  • DeliveredOne engine, two playable games
  • An engine, not a one off game. The client framework and the server were built to be dropped into the next game as they were.
  • Realtime state over sockets, with a Node.js service deciding what is true when two players disagree.
  • Two complete online games shipped on it, and the second needed no change to the engine to exist.

Context

I wanted to build browser multiplayer games, and every one of them starts by solving the same problem: getting two browsers to agree on what is happening right now. So I solved it once, as an engine, and then built games against it.

The challenge

Realtime multiplayer is unforgiving. Messages arrive late, arrive twice or do not arrive, and every one of those has to leave the game in a state both players accept. A browser also gives you no second process to hide the work in, so the client had to stay light while the server carried the truth.

What I did

  • An object oriented engine in JavaScript, built on Photon Realtime for transport, with rooms, players, lobbies and match lifecycle modelled once instead of per game.
  • A client framework for browser integration, so a game only has to describe its own state and rules, and the engine handles joining, syncing and leaving.
  • A Node.js backend over sockets, holding the authoritative state, resolving conflicting input and pushing the result back out to every connected client.
  • MySQL behind it, for the things that have to survive a session: accounts, match history and scores.
  • Two games built on the engine, which is how I know the abstraction holds. The second one needed no changes to the engine to exist.

The outcome

  • A networking layer that is reusable rather than a copy paste of the last game.
  • Two online multiplayer browser games, playable end to end.
  • A working answer to the hard part of realtime: one authority, many clients, and a defined outcome when they disagree.

Technologies used

  • JavaScript: The engine itself, written object oriented so a game extends it rather than forks it.
  • Node.js: The server holding authoritative game state and the socket connections into it.
  • Photon: The Realtime networking service the engine is built on.
  • MySQL: Accounts, match history and scores.

If realtime state between many clients is the problem in front of you, put it to me and I will tell you how I would approach it.