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

MelonJS – a fresh and lightweight JavaScript game engine

github.com

Post reply on HN
Print view View original

11–20 of 70 posts

Re: MelonJS – a fresh and lightweight JavaScript game engine

#11

Post by nkozyra »

Mizza wrote: post #7

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

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#13

Post by Mizza »

Waterluvian wrote: post #9
Mizza wrote: post #7

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

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

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#14

Post by ermir »

Mizza wrote: post #13
Waterluvian wrote: post #9

Earlier quoted context omitted.

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

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

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#15

Post by somehnacct3757 »

Mizza wrote: post #7

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

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#16

Post by Waterluvian »

Mizza wrote: post #13
Waterluvian wrote: post #9

Earlier quoted context omitted.

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

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

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#17

Post by wesz »

Mizza wrote: post #7

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

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#18

Post by warent »

Mizza wrote: post #7

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

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

Re: MelonJS – a fresh and lightweight JavaScript game engine

#19

Post by duringwork12 »

Mizza wrote: post #7

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

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

Re: MelonJS – a fresh and lightweight JavaScript game engine

#20

Post by sarchertech »

SquareWheel wrote: post #4

There's a Nintendo DS emulator named melonDS. If the title didn't have a description, I would have assumed it were a JavaScript port of the emulator. That would have been cool. This is cool too, though.

Looks like MelonJS is at least 5 years older. The GitHub repo history goes back to 2011.
Post reply on HN