A physics engine with incremental rollback for multiplayer games

https://easel.games/blog/2026-rollback-physics

by BSTRhino • 3 months ago

128 41 3 months ago

BSTRhino15• 3 months ago

Hi everyone,

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.

stephc_int132• 3 months ago

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.

gafferongames4• 3 months ago

The thing the author is trying to solve for here is reducing the amount of CPU used on the client when it rolls back the simulation and re-simulates to keep server authority.

He does this by only rolling back and re-simulating only a subset of the world, greatly reducing the amount of CPU required. It's cool that he's approaching this from the point of view of adding support for it in the physics engine itself, vs. making it something that the game has to do themselves.

Delta compression is an unrelated technique which reduce the amount of bandwidth sent from server to client, by sending only the differences between the snapshot at baseline frame n and the current snapshot frame m on the server.

Just want to clear this up for anybody trying to follow along. Bringing in delta compression is an unrelated thing (but somewhat similar conceptually). It might confuse people to talk about these things at the same time, if they're really just trying to understand what the author is doing in the article.

cheers

- Glenn

tikotus• 3 months ago

I was also curious about this, and I don't think the other replies understood what was being suggested.

If I understood correctly, the aim of the engine is to lower the in-memory size of the history of game states, by only snapshotting the delta. I'm also curious what would happen if, instead, you'd just run any deterministic snapshottable physics engine, and delta compressed the history on the fly. I think this is how, for example, Braid works.

Might be that it doesn't work, that running the delta check on two big enough snapshots would be too slow, and that's what this engine fixes. But would love to hear if it was considered.

gafferongames4• 3 months ago

I think this is a cool idea. Well done!

BSTRhino15• 3 months ago

Thank you so much!

ornitorrincos• 3 months ago

How does it compare with deterministic physics engines, given that their appeal for multiplayer is that they can perform rollback?

BSTRhino15• 3 months ago

This physics engine is a deterministic physics engine. It has to be to make sure that when it rolls back and resimulates forward, it gets the same answer on all machines.

The determinism is partly possible because WebAssembly is deterministic (except for a few known cases https://github.com/WebAssembly/design/blob/main/Nondetermini...), and partly because I’m making sure to use my own trigonometric functions, and the entire game simulation is executed single threaded with a known order of execution.

If you meant to ask how does it compare to non deterministic physics engines, I’m sure they might be faster on the physics but would be slower on the rollback, and I think on most reasonably-sized games the slow rollback would dominate and so they would be slower overall. But, you wouldn’t make a rollback netcode game with that size of world anyway, at least maybe not until now, so it’s a bit of a false comparison. They’re good at their different use cases.

Jyaif• 3 months ago

How big is the state that you want to rollback?

riidom• 3 months ago

Can the games only be played on the easel site, or can I upload to e.g. itch.io as well (probably with the limitation of only singleplayer?)

BSTRhino15• 3 months ago

You can upload to itch.io yes: https://easel.games/docs/learn/publishing/export

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!

dasyatidprime• 3 months ago

What you're describing isn't uploading the game, then, but uploading a stub with a transclusion of the game. I'm not the same commenter, but surely that doesn't answer (what I see as) most of the implications of the original question?

maxbendick• 3 months ago

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.

manuisin• 3 months ago

I’m in the same boat. Been learning 3d game dev past few years seriously after dabbling for half a decade. I even released my first few tiny 3d games in the last 6 months and they’ve made hundreds of dollars! That alone was a dream come true.

I picked game dev specifically because I wanted to build some things I had envisioned and found it challenging. And in the beginning each new concept within 3d modeling, optimisation, shaders, physics, lighting, shadows & rendering felt intractable and unmasterable.

Now, I have a basic working understanding of nearly everything that goes into traditional 3d game dev. Except the very cutting edge stuff. And have mastered things I was struggling with 2 years ago.

And recently I felt something that scared me. It was the feeling that within 2 years, I’ll have lost the excitement and challenges that learning game dev has brought me with these past few years. And I could see how to someone experienced this was as boring as full stack web dev was for me.

boredtofears• 3 months ago

I know there’s a ton of resources out there for this sort of thing but is there any particular sites/books that stood out to you while learning?

mncharity• 3 months ago

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.

BSTRhino15• 3 months ago

That is a cool idea! Could be a great application of rollback!

momojo• 3 months ago

Is this a demo? A hobby? How long have you been at this?

BSTRhino15• 3 months ago

I’ve been working on this for four years. I’m trying to make this my full time job!

jkhdigital• 3 months ago

Let me know when you have enough demand to make it multiple full-time jobs. I’ve been making notes for a few years now about all the best patterns and principles for designing complex systems and your language + engine more or less hits all the right notes.

Declarative state and reactivity, lexical lifetimes and ownership, etc. Really curious how you set it all up and what prior art was your primary inspiration.

metabrew• 3 months ago

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.

BSTRhino15• 3 months ago

I would LOVE to one day make a source-available standalone license for Easel that you can run on your own server! I just have a bunch of problems to solve to get there before it’s ready.

1. The people who really love Easel right now are teenagers who have mastered Scratch and are looking for more. Expert game devs who come from Unity or other programming languages find it’s missing some capability they really want and tend to get frustrated right now. I’ve been solving so many issues every month, like we got multiple cameras the other month for example, but there’s so much left. If I made a standalone version now, no one would buy it because it doesn’t yet do what they need, and if you did I would probably be refunding you quite soon. We might need another 6-12 months to be ready for experts. Sign up to the mailing list and we can keep you updated.

2. I would be willing to go as far as source available to licensees but there’s are some practical issues with fully open source. First, it makes it easier to cheat at all Easel games. Easel is client authoritative for certain things. Why? So I can keep the server costs within what I can actually afford because I am one person. Maybe once I can afford 30 servers we can make it all server authoritative and I won’t worry about this anymore. Second, I expect a net decrease in my productivity if I have to argue and defend my code, and become the BDFL to the open internet all the time in an open source environment. I’ve been really really productive just working by myself.

FrojoS• 3 months ago

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].

[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"

BSTRhino15• 3 months ago

That is helpful feedback, thank you, yes all things I can work on in the future! Thanks for taking the time to write this up.

AnnaKoro453• 2 months ago

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.

A physics engine with incremental rollback for multiplayer games

Related Stories