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.
The text is blurry for me even on a standard DPI monitor that just happens to be large. For some reason the canvas resolution is still significantly lower than the display resolution and then being stretched.
I think canvas kept the "1 px is 1/96th an inch as reported by the browser not a display pixel" convention primarily for consistency as that's how the px unit worked on everything else in the browser.
"Web libraries (react, etc)" are just using HTML and CSS / the standard DOM for rendering instead of Canvas. You don't need to use any "library" to render in that way, it's built into the browser.
My most recent web game uses both standard DOM and Canvas for rendering different parts of the UI and text, and both look equally good to me. You do have to have set up the Canvas rendering correctly, especially for sharper displays like Apple Retina displays with higher pixel densities, but when done properly it looks very sharp and has no issue IMO.
As long as you don't read your writes and use transform for animations it won't cost you more than 0.5ms to 1ms per frame (could it be better? Sure. But developer productivity is important.)
I use react in my game platform bloxd.io - which I work full time on - and I couldn't be happier
Just took at look a bloxd. Pretty cool! I want to make my own io game. I think the browser game market is under served as far as quality games are concerned, and doesn’t seem saturated compared to all the other platforms.
Would you be able to give any advice on netcode/multiplayer solutions? I like working with low level rendering libraries (canvas, Kha/Haxe) but I am wondering if it is better to use an engine versus libraries, or even just rolling my own solution with web sockets?
no need to roll your own solution. If you want to ship a game, go high level :D
For web native rendering pixijs is good for 2d (and phaser is good also a good entry level). For 3d theres threejs/babylonjs.
There's also unity, which some browser games use but it has downsides on web (large build sizes for one)
None of the networking solutions will give you unreal engine netcode developer productivity (and that includes ones for unity). I use colyseus, it doesnt solve everything but will save you some work
Re saturation, it definitely depends on the genre, web is its own market. What type of game are you thinking of making?
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.
Text rendering quality is not as bad as it used to be, pretty much on par with DOM. In any event, if you do not scale canvas resolution by devicePixelRatio, the result will be blurry on most devices these days.
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.
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.
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'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 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?
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.
I'm a web dev that tried to find a job in browser game dev. Until I realised that there aren't many positions to go around. Only making slot games for online gambling companies really. The rest of the opportunities were not in browser land, but Unity or Unreal Engine. And good luck getting past the millions of techbros who want these positions.
Yes, the browser game market is dead except for gambling and education - that’s because browser games run instantly with 0 installation.
Almost no jobs. However, if you can find them they pay much better than Unity/Unreal jobs because html game dev is such a rare skill. The decision tree you need to follow to end up as a html game specialist is so fraught with distractions almost no one ends up there.
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.
More here https://www.melongaming.com/en/Games