Hacker News Reader

Comment by Mizza | Hacker News Reader

Nice! Is this yours?

I've tried building a few real-time games with different implementations of these HTML5/JS game engines, but I always hit a wall when trying to add multiplayer capabilities.

The main issues I've found is there's never a way to get a "universal" X/Y/Z position for an object that can be accurately stored in a server that syncs with the position for players. It always tends to be ever so slightly off in a way that desyncs over time, making a stutter when the server has to force a resync. This is then compounded with collision detection physics, which these engines never do in a "standard"/specified way, requiring me to reimplement their physics server side, which inevitably causes occasional game breaks from the inconsistencies - going through walls, or total desync.

Anybody have any suggestions/solutions/recommendations?

View on HN

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

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.

Don't make your goal to be accurate state across the internet. Game making is all about lies, cheats, steals, and fudge.

In this situation you can stream movement waypoints from remote clients and lerp between those waypoints locally to simulate movement. If latency is low enough you can make predictions about the next waypoint and it won't look bad when you're wrong.

If you're PvE, you're done. Nobody needs to know precisely where their teammate is as long as the game feels fair. (The AI players on the other side won't complain.)

In PvP the opponent will complain, and they're also a customer, so you have to do something about it. This is an entire technical discipline within gamedev if you want both accuracy and player freedom.

Don't be afraid to let technical constraints guide your design. If you don't want to spend your life building remote physics validation or latency-aware consensus algorithms, make your players interact with the world via clicking so you always know exactly where they wanna go next. One of the super powers of being a programmer + designer combo is making trades across disciplines to maximize your output.

TL;DR unless you're super passionate about networking, don't waste time reinventing the wheel. These problems have all been solved already.

I've been building a MOBA, using Photon Engine for the networking. It's a framework that handles everything you just described, using different paradigms depending on your preference.

The one I'm using, called "Photon Fusion", runs the entire game on the server to replicate all the game logic and physics that the client side has, as you described. However, it takes care of desync issues by using some clever interpolation and client side prediction with tick-based simulation, while keeping the server as the state authority with extremely optimized compression of communication to support lower bandwidth.

https://www.photonengine.com/en-US/Fusion

Can second Photon Engine. Great team with a lot of experience on this

All approaches need to deal with desync and do it in different ways. Lockstep waits causing a hitch for everyone. Rollback resimulates and will pop. Interpolating positions will mean you occasionally need to catch up. It’s just the nature of latency and unreliable network conditions. The trick is how to deal with this without it interrupting gameplay significantly. For example in rollback you need to keep clients reasonably in sync with the progression of time so a lot of the time different clients are either running slightly slowly or slightly fast to catch up to the baseline. You’re dealing with a situation where everyone is in their own universe and trying to make sure they eventually end up in sync. In the interpolated example that might mean giving coordinates relative to a particular entity. For example in an interpolated setup an explosion happening on the server against a fast moving vehicle probably needs to be relative to the vehicle for it to make sense when it reaches a client where the vehicle will naturally be in a somewhat different location.

By the sounds of things you’re sending positions updates and broadcasting them from the server. If that’s the case some bog standard interpolation should just work. If you’re seeing divergence then you’re probably running code with a non-deterministic result on the different machines. Typically speaking you want to work out who ‘owns’ each part of the simulation and make sure anything you do elsewhere converges back to that.

I'm assuming you're talking about lockstep/rollback network model, since it should not be an issue for client-server with proper client prediction/interpolation.

The biggest source of these inconsistencies is Math.sqrt(). You need to implement deterministic version of sqrt() and that should fix 99% of your issues. Hit me up if you need some additional pointers.

This sounds extremely relevant to my issues, as floating point issues between different clients and the server was something I noticed. I would really appreciate any links you might have to share.

https://mariani.life/flash-notes.html

I'm using this sqrt implementation (found it long time ago on some old action script blog, this link is not the original source). It's plenty fast, accurate and fully deterministic. I successfully implemented it in my multiplayer gta2 clone in javascript.

I use phaser on client side, then matter.js for physics + nengi.js for networking (https://github.com/timetocode/nengi).

I only have experience with 2d (so it might not be useful to you, but perhaps will others), where typically it's a worse experience for the player to have CSP (client side prediction) at-least in a fast paced game, as for example a player behind a wall can more clearly see something missed them, yet they still got hit.

The way I do things (and I've seen is common across other "io" games), is "CSP" only for particular actions (such as your own rotation, or swinging your own weapon), but otherwise just let the client move in step with the server in terms of any physics entities etc.

Do you have a demo/link to one of your games? I am interested in learning more about multiplayer experience for web games and would love to see an example with these tools mentioned.

I only have this old demo I open sourced - https://github.com/TomYeoman/2d-zombie-survival-io-demo right now (trying to crunch to finish full version)

It's using phaser on the server in this instance (which I recently ripped out, and moved to just using matter)

It's pretty ugly code, but the foundations are there, maybe it's a starting point or of some use!

Sounds like your issues are non-determinism and client prediction. This book is a great resource.

https://www.amazon.com/Multiplayer-Game-Programming-Architec...

I don't know the specifics of your problem but a broadcast of position through websocket to that only succeeds if each client accepts it first?

There are race conditions all over and I'd imagine you'd need to have a hash of current and next positions to prevent conflicts.

Is the problem you mentioned not fixed by collision prediction? Check out ourcade on youtube, if you don't already know what this is, he has a video on it.

Check out https://heroiclabs.com/opensource/

I am not an expert but GunJS may be of interest for fast p2p sync.

phaser and fluid js for microsoft have worked well for me for small multiplayers scenarios

Phaser is the one I liked the most and I got it _nearly_ close enough to being acceptable, but the rubber banding was enough to make it Not Fun^tm. I think the issues could have arisen from using Elixir as a backend rather than JS, leading to some of the math/floating point errors (particularly around sqrt) that others have mentioned here.

Reply on news.ycombinator.com