I'm making a game engine that uses rollback netcode for its multiplayer architecture. As far as I can tell, no physics engine supports incremental rollback thus far. This means the entire physics engine state has to be snapshotted every frame, which basically means it's infeasible to have large worlds with rollback netcode. I've made a physics engine which only snapshots the changes, and so now I think you can have large worlds, as long as most of the world is static. I think that's true in most cases, like when you're walking around a big spaceship for example, all the walls, tables, control panels etc don't really move. I wrote up a bit of a post to describe some of the cool things I discovered while making my own physics engine.
Have you considered the opportunity of using delta compression on snapshots? Like the internal state of the physics simulation, most of the gamestate itself don't change between frames. Using delta compression on the whole structure is doable.
The export basically creates a page with an HTML IFRAME in it that embeds the hosted version of your game on easel.games so that all the multiplayer and leaderboards continue to work.
As a long-time web/app developer getting into game dev, it feels like I'm entering "the big leagues" of software engineering. Tougher problems, more problems, more _interesting_ problems, and problems without prebuilt solutions. Much more fun than making yet another dashboard.
Combining player control, multiplayer, non-player control, and physics is one of the tougher problems. I got it handled (enough) for my project, but I'd be very interested to read the source if Easel's physics engine gets open-sourced.
Fwiw, one case where I've wanted rollback has been input fusion over interface devices with diverse latencies. You might have 10 ms for a keypress, 100 ms for optical tracking, and 1000 ms for speech. So given click+"the red one"(spoken), you might start running click+"the one in front"(default), and almost a second later rollback and rerun with "the red one". Or for real example, keypress event handling might branch on optical "pressed where on the keycap" and "by which finger", which won't become available for several frames.
This looks great - how much of it is open source, could I host it all myself? wouldn't be interested in investing any time learning if I'm locked in to hosting on some else's hardware.
Very cool! Thanks for the detailed tech blog explainer.
Some, hopefully constructive, feedback:
- You mention "other games" several times. It would be so much more interesting to read, if you named them. Your readers may know that game but have no knowledge about those under the hood details. Like the user wordpad, I immediately thought about Planetary Annihilation when I saw rollback and multiplayer.
- Your landing page needs an easy to grasp "About" / "What is this" section. I'm more or less familiar with several popular game engines (Unity, HL, Source, Unreal, Godot, Spring etc) and never heard of yours before. Even after clicking around a bit on your website, I still had almost no idea what your engine (or is it a language?? [1]) can, and more importantly, can not do. I mostly went by the screenshots of the game examples shown and concluded that it is a 2D engine with simple graphics. Wikipedia [2] and web search were not that helpful either, so I had to resort to an LLM [3].
The comparison to Rapier and Box2D is interesting. Most physics engines assume you're simulating the whole world every frame. For rollback multiplayer, that's death. Snapshotting only what changes is obvious in hindsight but nobody did it. This feels like one of those ideas that will become standard in five years.
15 comments
[ 3.2 ms ] story [ 38.3 ms ] threadI'm making a game engine that uses rollback netcode for its multiplayer architecture. As far as I can tell, no physics engine supports incremental rollback thus far. This means the entire physics engine state has to be snapshotted every frame, which basically means it's infeasible to have large worlds with rollback netcode. I've made a physics engine which only snapshots the changes, and so now I think you can have large worlds, as long as most of the world is static. I think that's true in most cases, like when you're walking around a big spaceship for example, all the walls, tables, control panels etc don't really move. I wrote up a bit of a post to describe some of the cool things I discovered while making my own physics engine.
The export basically creates a page with an HTML IFRAME in it that embeds the hosted version of your game on easel.games so that all the multiplayer and leaderboards continue to work.
Thanks for your interest!
Combining player control, multiplayer, non-player control, and physics is one of the tougher problems. I got it handled (enough) for my project, but I'd be very interested to read the source if Easel's physics engine gets open-sourced.
Some, hopefully constructive, feedback:
- You mention "other games" several times. It would be so much more interesting to read, if you named them. Your readers may know that game but have no knowledge about those under the hood details. Like the user wordpad, I immediately thought about Planetary Annihilation when I saw rollback and multiplayer.
- Your landing page needs an easy to grasp "About" / "What is this" section. I'm more or less familiar with several popular game engines (Unity, HL, Source, Unreal, Godot, Spring etc) and never heard of yours before. Even after clicking around a bit on your website, I still had almost no idea what your engine (or is it a language?? [1]) can, and more importantly, can not do. I mostly went by the screenshots of the game examples shown and concluded that it is a 2D engine with simple graphics. Wikipedia [2] and web search were not that helpful either, so I had to resort to an LLM [3].
[1] https://easel.games/docs/learn/key-concepts "Easel is a unique programming language with some unusual features." [2] https://en.wikipedia.org/wiki/Easel [3] https://search.brave.com/ask says "No, Easel is not a 3D game engine. It is a web-based game engine specifically designed for creating 2D multiplayer games without the developer needing to code the networking or server infrastructure"