Just a bit of friendly feedback. On my Android phone, the game didn't work in Firefox or Firefox Focus for me (the browsers I use normally). Music sounded good and initial screen looked good, but touching the screen had no effect. On Samsung Internet it worked fine. If MelonJS is handling the mouse/touch events, maybe all games are affected.
I think in the past I've fixed this by doubling the resolution. More precisely - detecting device pixel density and setting the canvas size based on that.
Are you playing on a phone or using a high DPI monitor? By default HTMLcanvas (which most game engines use to handle text) does not take into account high DPI scaling (I would guess due to performance).
This isn't inherit to JS game engines, but I will say text quality is not usually something that game devs focus on unless text is important to their particular game.
My guess is that this would be caused by rendering text into a canvas and then scaling the canvas to fit the window. That example is rendering at 640x960 regardless of the screen size.
This reminded me of my implementation for a university course where you played by tilting your head to the left and right with the help of an accelerometer embedded earbud. Everyone got nauseous after a couple runs but it was very fun indeed :)
These demos highlight the pro and cons of the various input devices. This melonjump game is much harder to play with a touchpad than with a mouse. The platformer demo isn't, but that's mostly a keyboard game. The whack-a-mole game is much much easier with a touchscreen than with a mouse or a touchpad.
Tree shaking, ES6 imports, yes to all of the above.
I tried a game engine some time ago (sadly I forget what it was called) but it bundled the entire library as soon as you tried to do the basic thing. If I recall it was over 1MB. These days JS transpires have incredible functionality for slimming down payload sizes and it's awesome to see more and more libraries making use of it.
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?
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.
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.
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.
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.
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.
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.
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.
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.
Thanks for sharing this. As a web dev, rather than game dev, I like that what I’ve used in web dev more and more is usable in web dev (es6, imports, rollups) etc.
To me, it has previously felt clunky to use older (and more mature, sure!) toolkits when building a one-day game just for fun.
Looks interesting, i also like the README and the provided demos. The development seems to have been done by a single dev for the last three years. Impressive!
The line-of-sight demo appears to be buggy on Firefox, however: A box behind a closer box that blocks the view is marked as red.
There's no mention of networking so i guess multiplayer is not inside its current scope?
Readit News
More here https://www.melongaming.com/en/Games
I noticed this in the game you linked as well.
This isn't inherit to JS game engines, but I will say text quality is not usually something that game devs focus on unless text is important to their particular game.
Here's an example of a workaround to render more crisp text https://github.com/danman113/gfx-utils/blob/main/src/canvas/...
Web libraries (react, etc) are very advanced and it'd be incredibly hard for a js game engine to match them for UI
Maybe you can also integrate the accelerometer on phones for a compact and more fun example?
[1] http://radmars.com/superkaijudunkcity/submission/
I tried a game engine some time ago (sadly I forget what it was called) but it bundled the entire library as soon as you tried to do the basic thing. If I recall it was over 1MB. These days JS transpires have incredible functionality for slimming down payload sizes and it's awesome to see more and more libraries making use of it.
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?
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-...
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.
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.
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
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.
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.
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.
Deleted Comment
Deleted Comment
https://www.amazon.com/Multiplayer-Game-Programming-Architec...
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.
This is cool too, though.
To me, it has previously felt clunky to use older (and more mature, sure!) toolkits when building a one-day game just for fun.
The line-of-sight demo appears to be buggy on Firefox, however: A box behind a closer box that blocks the view is marked as red.
There's no mention of networking so i guess multiplayer is not inside its current scope?
What is the state of Cordova these days for a typical reactive webapp ?