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.
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.
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.
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.
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.
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?
Depends for which platforms you want to create game for. If it's for web games, you should stick to JS game engines, such as babylonjs
Engines like Unity produces binaries that are too big to be competitive for that market.
As a web dev I made two browser games with no framework (for one I used the Matter.js physics engine) and it was a good experience. The browser has great built in apis like the Canvas element so it isn't completely "from scratch", but you'll still get a great sense for the basics of making a game loop etc from the ground up and you can use your previous experience.
I've also played around with Unity a bit but haven't released anything or finished any project. If I wanted to transition to full time game dev I would probably start learning Unreal or Godot as an engine for major projects... or focus on making browser games, maybe with a JS game engine like Melon or Phaser, or continue to roll my own JS games. The big engines like Unity can compile to web but it's a subpar experience and I wouldn't use it if my main target was in browser.
Web devs like us will have some advantages in already being exposed to some of the networking and stuff related to multiplayer, auth, leaderboards, etc.
If you're seriously making that transition, then you should learn one of the two dominant general gaming engines - Unity or Unreal. Both of them have exceptional documentation and can be deployed in a wide variety of platforms.
If you're going from web dev to game devs as a hobby or just fun side thing, then a JS engine like Melon is a good way to dive in and start creating something people can enjoy without serious investment.
If you're just getting started, I'd recommend trying out a few engines to see what clicks (I find it usually takes at least an afternoon to get a feel for an engine). JS engines tend to be easier to get started with as a web developer, but you'll often run into limitations when you start building more complex games.
[+] [-] onion2k|3 years ago|reply
More here https://www.melongaming.com/en/Games
[+] [-] jlokier|3 years ago|reply
[+] [-] nassimsoftware|3 years ago|reply
I noticed this in the game you linked as well.
[+] [-] ermir|3 years ago|reply
Maybe you can also integrate the accelerometer on phones for a compact and more fun example?
[+] [-] pmontra|3 years ago|reply
[+] [-] jebarker|3 years ago|reply
[+] [-] PinkMilkshake|3 years ago|reply
[1] http://radmars.com/superkaijudunkcity/submission/
[+] [-] afavour|3 years ago|reply
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.
[+] [-] Mizza|3 years ago|reply
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?
[+] [-] Waterluvian|3 years ago|reply
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-...
[+] [-] somehnacct3757|3 years ago|reply
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.
[+] [-] warent|3 years ago|reply
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
[+] [-] meheleventyone|3 years ago|reply
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.
[+] [-] wesz|3 years ago|reply
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.
[+] [-] nullandvoid|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] green_man_lives|3 years ago|reply
https://www.amazon.com/Multiplayer-Game-Programming-Architec...
[+] [-] nkozyra|3 years ago|reply
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.
[+] [-] Throwaway234590|3 years ago|reply
[+] [-] alexandargyurov|3 years ago|reply
[+] [-] mlok|3 years ago|reply
[+] [-] duringwork12|3 years ago|reply
[+] [-] SquareWheel|3 years ago|reply
This is cool too, though.
[+] [-] sarchertech|3 years ago|reply
[+] [-] dyml|3 years ago|reply
To me, it has previously felt clunky to use older (and more mature, sure!) toolkits when building a one-day game just for fun.
[+] [-] acbart|3 years ago|reply
[+] [-] dmak|3 years ago|reply
[+] [-] Tepix|3 years ago|reply
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?
[+] [-] algo_trader|3 years ago|reply
What is the state of Cordova these days for a typical reactive webapp ?
[+] [-] dmak|3 years ago|reply
[+] [-] surmoi|3 years ago|reply
[+] [-] naet|3 years ago|reply
I've also played around with Unity a bit but haven't released anything or finished any project. If I wanted to transition to full time game dev I would probably start learning Unreal or Godot as an engine for major projects... or focus on making browser games, maybe with a JS game engine like Melon or Phaser, or continue to roll my own JS games. The big engines like Unity can compile to web but it's a subpar experience and I wouldn't use it if my main target was in browser.
Web devs like us will have some advantages in already being exposed to some of the networking and stuff related to multiplayer, auth, leaderboards, etc.
[+] [-] waboremo|3 years ago|reply
If you're going from web dev to game devs as a hobby or just fun side thing, then a JS engine like Melon is a good way to dive in and start creating something people can enjoy without serious investment.
[+] [-] amitmathew|3 years ago|reply
[+] [-] meheleventyone|3 years ago|reply