Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A physics engine with incremental rollback for multiplayer games

easel.games

Post reply on HN
Print view View original

21–30 of 46 posts

Re: A physics engine with incremental rollback for multiplayer games

#21

Post by manuisin »

maxbendick wrote: post #8

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 projec…

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.

Re: A physics engine with incremental rollback for multiplayer games

#22

Post by mellinoe »

BSTRhino wrote: post #16
stephc_int13 wrote: post #14

Earlier quoted context omitted.

No, in this context I meant delta-compression in the case of local roll-back. The entire gamestate has to be rolled back when using this style of netcode, regardless of bandwidth, reducing the size of snapshots in memory can also reduce make it faster to rebuild.

Actually, it doesn’t roll back the entire game state. Everything is stored in slot maps, and if there are 1000 slots and only 10 changed, it really does only rollback those 10 only and it does not touch anything else. Slot maps are great!

How do you accurately resimulate if you don't rollback everything to the previous state? E.g. a giant wall moved from point A to B but it was accurately predicted (no rollback). Don't you need to roll the wall back to accurately simulate everything around it?

EDIT: I misunderstood the previous comment, I think you are rolling back everything that changed, and not rolling back objects which were "static" in that timeframe.

Re: A physics engine with incremental rollback for multiplayer games

#23

Post by BSTRhino »

mellinoe wrote: post #22
BSTRhino wrote: post #16

Earlier quoted context omitted.

Actually, it doesn’t roll back the entire game state. Everything is stored in slot maps, and if there are 1000 slots and only 10 changed, it really does only rollback those 10 only and it does not touch anything else. Slot maps are great!

How do you accurately resimulate if you don't rollback everything to the previous state? E.g. a giant wall moved from point A to B but it was accurately predicted (no rollback). Don't you need to roll the wall back to accurately simulate everything around it? EDIT: I misunderstood the previous comment, I think you are rolling back everything that changed, and not rolling back objects which were "static" in that timef…

Yes, sounds like you get it, Giant Wall changed so it gets rolled back to point A, then it resimulates, which might mean Giant Wall might push some other things this time around that it didn't before during the predicted simulation. It kind of uses a transaction log copy-on-write kind of mechanism, so there will be a log entry for previous value of the Giant Wall slot and it will restore that into its old slot. It's a bit more advanced than that but that's the gist.

Re: A physics engine with incremental rollback for multiplayer games

#24

Post by dasyatidprime »

BSTRhino wrote: post #4
riidom wrote: post #3

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?)

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!

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?

Re: A physics engine with incremental rollback for multiplayer games

#25

Post by ggambetta »

gafferongames wrote: post #12
BSTRhino wrote: post #9

Earlier quoted context omitted.

Yes thank you, you understand perfectly and thank you for explaining. Also, I LOVE your series of blog posts, thank you for making them! Just to add to the general discussion for everyone following along - rollback netcode only sends inputs around, not state, so it doesn't really have much to send. I think I'm doing about 1.5 KB per second. When you point your mouse it sends that data in 10 bytes. There's not a lot t…

One cool trick you could try (although you are probably doing it already) is to include all inputs for some long period (like 1-2 seconds!) in every input packet the client sends to the server. This way if one input packet gets lost, the very next one getting through will have all the inputs for the last 1-2 seconds, and this greatly improves how well your game will play under packet loss. When you do this, you can e…

No need to resend inputs with seq IDs <= the last one acknowledged by the server, right? 1-2 seconds sounds like overkill. Unless the server updates themselves are lower than 0.5-1 Hz, but what kind of game is that? A very sparse world where chances of misprediction are very low?

Re: A physics engine with incremental rollback for multiplayer games

#28

Post by BSTRhino »

dasyatidprime wrote: post #24
BSTRhino wrote: post #4

Earlier quoted context omitted.

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!

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?

Okay, in that case you can upload a stub with a transclusion of the game. If there is enough demand I would definitely work on a standalone export system!

Re: A physics engine with incremental rollback for multiplayer games

#29

Post by quikoa »

dasyatidprime wrote: post #24
BSTRhino wrote: post #4

Earlier quoted context omitted.

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!

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?

Vendor lock-in with a monthly subscription where the price can change at any moment or the company may disappear along with your product. I wouldn't build my business on that.

Re: A physics engine with incremental rollback for multiplayer games

#30

Post by tikotus »

stephc_int13 wrote: post #5
BSTRhino wrote: post #2

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 y…

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.

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.

Post reply on HN