[HN Gopher] MelonJS - a fresh and lightweight JavaScript game en...
___________________________________________________________________
MelonJS - a fresh and lightweight JavaScript game engine
Author : modinfo
Score : 194 points
Date : 2022-12-19 08:45 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| SquareWheel wrote:
| 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.
| sarchertech wrote:
| Looks like MelonJS is at least 5 years older. The GitHub repo
| history goes back to 2011.
| dyml wrote:
| 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.
| afavour wrote:
| 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.
| Tepix wrote:
| 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?
| onion2k wrote:
| An example of what can be done with it -
| https://melongaming.com/games/melonjump/ (hold the left mouse
| button down and move your mouse to play).
|
| More here https://www.melongaming.com/en/Games
| nassimsoftware wrote:
| The thing I noticed with most JS game libraries is their
| inability to display text without being slightly blurry. Is
| there a fix to the issue?
|
| I noticed this in the game you linked as well.
| ghusbands wrote:
| This engine at least says it has "High DPI resolution &
| Canvas advanced auto scaling", so it might not have that
| issue.
| koshergweilo wrote:
| 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.
|
| Here's an example of a workaround to render more crisp text
| https://github.com/danman113/gfx-
| utils/blob/main/src/canvas/...
| robust-cactus wrote:
| 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.
| MCArth wrote:
| Tbh when making a web game you'd be better served using
| standard web UI in tandem with your game even if canvas text
| wasn't blurry.
|
| Web libraries (react, etc) are very advanced and it'd be
| incredibly hard for a js game engine to match them for UI
| naet wrote:
| "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.
| aliswe wrote:
| I think you underestimate the performance difference of
| canvas! Also, WebGL
| dxhdr wrote:
| Disagree; updating the DOM is incredibly slow and will kill
| your games performance.
| MCArth wrote:
| 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
| robust-cactus wrote:
| Depends how often you're updating the DOM and how
| plopz wrote:
| 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.
| ramesh31 wrote:
| Text rendering, manipulation, and searching, is one of the
| key issues holding back canvas adoption as a whole. The DOM
| is still king here.
| incrudible wrote:
| 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.
| pmontra wrote:
| 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.
| jebarker wrote:
| That's a really fun game!
| jlokier wrote:
| 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.
| ermir wrote:
| Reminds me of the classic Orsinial Winterbells:
| https://www.crazygames.com/game/winterbells
|
| Maybe you can also integrate the accelerometer on phones for a
| compact and more fun example?
| thifhi wrote:
| 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
| :)
| Mizza wrote:
| 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?
| alexandargyurov wrote:
| Check out https://heroiclabs.com/opensource/
| Waterluvian wrote:
| 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-...
| Mizza wrote:
| 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.
| ermir wrote:
| 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.
| Waterluvian wrote:
| 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.
| meheleventyone wrote:
| 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.
| somehnacct3757 wrote:
| 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.
| nullandvoid wrote:
| 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.
| leohart wrote:
| 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.
| nullandvoid wrote:
| 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!
| wesz wrote:
| 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.
| Mizza wrote:
| 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.
| wesz wrote:
| 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.
| nkozyra wrote:
| 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.
| warent wrote:
| 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
| philippz wrote:
| Can second Photon Engine. Great team with a lot of experience
| on this
| [deleted]
| Throwaway234590 wrote:
| 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.
| green_man_lives wrote:
| Sounds like your issues are non-determinism and client
| prediction. This book is a great resource.
|
| https://www.amazon.com/Multiplayer-Game-Programming-Architec...
| duringwork12 wrote:
| phaser and fluid js for microsoft have worked well for me for
| small multiplayers scenarios
| Mizza wrote:
| 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.
| algo_trader wrote:
| I see they "integrate with Apacha Cordova".
|
| What is the state of Cordova these days for a typical reactive
| webapp ?
| dmak wrote:
| For someone going from web dev to game dev, would it be better to
| learn MelonJS or another JS Engine or something like Unity?
| meheleventyone wrote:
| Depends on where you want to deploy ultimately.
| waboremo wrote:
| 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.
| surmoi wrote:
| 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.
| amitmathew wrote:
| 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.
| naet wrote:
| 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.
| acbart wrote:
| Can anyone speak to the difference between this and Phaser?
| dmak wrote:
| I would like to know as well
___________________________________________________________________
(page generated 2022-12-20 23:01 UTC)