Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Remote multiplayer for real-time games is an entire domain in itself and possibly the hardest part of game dev.

There’s a number of approaches. One approach is that you need to make your local simulation deterministic so that every client can do their own work and simply agree that they’re on the same page. You then send events, not state, in turns.

Saving state in a hashable structure can make it easy to check if all clients agree.

Decoupling the local sim from the multiplayer events can make the game feel smooth, even if at times there’s rubber banding.

This is such a good read: https://www.gamedeveloper.com/programming/1500-archers-on-a-...

View on HN

Nice, thanks for the link. I hadn't heard the term "rubber banding" before, but that exactly describes what I end up with.

I think my backend and overall strategy are good, sending events rather than state, deterministic simulation, event buffering, client prediction, etc, ultimately my issues arise on the client side when using these frameworks, I haven't found one that considers how a game server operates, so it ends up requiring a good deal of hacking to inject server messages into the game state at the right places, and ultimately the math is always a little bit off, rounding issues add up, rubber banding appears, etc. I guess I could write my own engine from the ground up with a backend in mind, but I don't have the free time to make the engine and the client and the server and the actual game, so I was hoping that maybe Melon2 would have considered my use case.

I am also working on JS client-server multiplayer implementations, and I've gone with WebRTC for the transport and a state-based communication (instead of events). The primary reason is to avoid desyncs, which is in my opinion impossible to avoid with JS because of the different JS engines and platforms that the game will run on. If you're expecting determinism when playing across mobile ARM, desktop x86, desktop ARM, and any combination of these, then the only way to achieve this is to use fixed point math and reimplement the behavior of JS primitives such as arrays and hash tables. It might be worth it for you and the game you're making, but for fast action games this is not needed, and just sending state to the players should work well.

I find that the bigger engines give you much better equipment to succeed with multiplayer. I think smaller engines avoid it as it’s easy to declare it out of scope and therefore avoid the pain.

Also, a piece of advice I once heard that resonated with me: you either make a game engine or a game. Never both.

Reply on news.ycombinator.com