7 ms·

MelonJS – a fresh and lightweight JavaScript game engine

216 points by modinfo 4y ago

SquareWheel 4y ago
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 4y ago
  Looks like MelonJS is at least 5 years older. The GitHub repo history goes back to 2011.
  - SquareWheel 4y ago
    Cool callout. Frankly I'm impressed that a JS game engine is still relevant after more than a decade.
dyml 4y ago
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.
Tepix 4y ago
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?
algo_trader 4y ago
I see they "integrate with Apacha Cordova". What is the state of Cordova these days for a typical reactive webapp ?
onion2k 4y ago
An example of what can be done with it - https://melongaming.com/games/melonjump/ 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 https://www.melongaming.com/en/Games
- pmontra 4y ago
  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 4y ago
  That's a really fun game!
- ermir 4y ago
  Reminds me of the classic Orsinial Winterbells: https://www.crazygames.com/game/winterbells https://www.crazygames.com/game/winterbells Maybe you can also integrate the accelerometer on phones for a compact and more fun example?
  - thifhi 4y ago
    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 :)
- nassimsoftware 4y ago
  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.
  - plopz 4y ago
Mizza 4y ago
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?
- Throwaway234590 4y ago
  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.
- Waterluvian 4y ago
  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-28-8-network-programming-in-age-of-empires-and-beyond https://www.gamedeveloper.com/programming/1500-archers-on-a-...
  - Mizza 4y ago
    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.
afavour 4y ago
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.
acbart 4y ago
Can anyone speak to the difference between this and Phaser?
- dmak 4y ago
  I would like to know as well
dmak 4y ago
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 4y ago
  Depends on where you want to deploy ultimately.
- surmoi 4y ago
  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.
  - dmak 4y ago
    What did you mean by the binaries part?
- waboremo 4y ago
  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.
- amitmathew 4y ago
  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 4y ago
  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.

216 points by modinfo 4y ago

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 4y ago
Looks like MelonJS is at least 5 years older. The GitHub repo history goes back to 2011.
- SquareWheel 4y ago
  Cool callout. Frankly I'm impressed that a JS game engine is still relevant after more than a decade.

dyml 4y ago

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.

Tepix 4y ago

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?

algo_trader 4y ago

I see they "integrate with Apacha Cordova". What is the state of Cordova these days for a typical reactive webapp ?

onion2k 4y ago

An example of what can be done with it - https://melongaming.com/games/melonjump/ 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 https://www.melongaming.com/en/Games

pmontra 4y ago
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 4y ago
That's a really fun game!
ermir 4y ago
Reminds me of the classic Orsinial Winterbells: https://www.crazygames.com/game/winterbells https://www.crazygames.com/game/winterbells Maybe you can also integrate the accelerometer on phones for a compact and more fun example?
- thifhi 4y ago
  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 :)
nassimsoftware 4y ago
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.
- plopz 4y ago

Mizza 4y ago

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?

Throwaway234590 4y ago
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.
Waterluvian 4y ago
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-28-8-network-programming-in-age-of-empires-and-beyond https://www.gamedeveloper.com/programming/1500-archers-on-a-...
- Mizza 4y ago
  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.

afavour 4y ago

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.

acbart 4y ago

Can anyone speak to the difference between this and Phaser?

dmak 4y ago
I would like to know as well

dmak 4y ago

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 4y ago
Depends on where you want to deploy ultimately.
surmoi 4y ago
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.
- dmak 4y ago
  What did you mean by the binaries part?
waboremo 4y ago
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.
amitmathew 4y ago
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 4y ago
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.