Live data from Hacker News

MelonJS – a fresh and lightweight JavaScript game engine

github.com

51–60 of 70 posts

Re: MelonJS – a fresh and lightweight JavaScript game engine

#51
post #37
post #31

Earlier quoted context omitted.

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

Disagree; updating the DOM is incredibly slow and will kill your games performance.

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

Re: MelonJS – a fresh and lightweight JavaScript game engine

#52
post #29

Earlier quoted context omitted.

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, manipulation, and searching, is one of the key issues holding back canvas adoption as a whole. The DOM is still king here.

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#53
post #6

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

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.

This engine at least says it has "High DPI resolution & Canvas advanced auto scaling", so it might not have that issue.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#54
post #6

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

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#55
post #33

For someone going from web dev to game dev, would it be better to learn MelonJS or another JS Engine or something like Unity?

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#56
post #31

Earlier quoted context omitted.

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.

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

"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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#57
post #36
post #33

For someone going from web dev to game dev, would it be better to learn MelonJS or another JS Engine or something like Unity?

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.

What did you mean by the binaries part?

Re: MelonJS – a fresh and lightweight JavaScript game engine

#58
post #51
post #37

Earlier quoted context omitted.

Disagree; updating the DOM is incredibly slow and will kill your games performance.

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?

Re: MelonJS – a fresh and lightweight JavaScript game engine

#59
post #55
post #33

For someone going from web dev to game dev, would it be better to learn MelonJS or another JS Engine or something like Unity?

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…

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.

Re: MelonJS – a fresh and lightweight JavaScript game engine

#60

Earlier quoted context omitted.

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.

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 c…

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.

Post reply on HN