Some more notes from my experience:

If you're serious about large scale games, you should look into typescript. I'd start away from any other language, like coffee script, Ruby... See my next point.

Use node.js on the back end so you can do client side and server side validation with the same code. Another benefit is that you can also make your game single player much easier. I usually prefer to start the game multiplayer first and then do single player.

Another tool useful for game is pixi.js (or phaser if you need what they provide. Pixi just does the rendering part, phaser does a lot of game related things)

I'd use illustrator instead of Photoshop because you can scale your graphics without losing quality. Vectorial is better than bitmap.

For state management I use redux.

If you're interested here is my game https://bitplanets.com . It's a RTS game, where you need to conquer planets. You can play with your friends and people online. Of course no need to download or register and works on mobile. (60fps if on a decent phone)

It still confuses and unsettles me that Paint.net started as open source and then went closed source. I mean, people already had the source. All because someone tried to fork it? It just doesn't add up.

see

https://blog.getpaint.net/2007/12/04/freeware-authors-beware...

Someone tried to claim it as their own by repackaging it and packaging up some plugins... He obviously got annoyed and figured he doesn't want to make it so easy to make your own version.

It adds up for me, just kind of unfortunate, I'd like to think it still would've been better off open, but it's his creation and his time and effort so if that's what he wants to do, I'm ok with it.

I added some more mentions:

- Buzz! / FFmpeg - SugarJS - tween.js - hjson

It's not clear to me if they used Electron's Node backend for much more than it's File API. If that's the case, they might have been better off just using a QT webview (e.g. pywebview) for the sake of performance (which they cite as reason for moving from NW.js/Electron).

I'm not very familiar with Qt or Qt webview but from their documentation it states:

> This version of Qt WebEngine is based on Chromium version 73.0.3683, with additional security fixes from newer versions.

Assuming they both have a full Chromium embed, would there have been better performance? I assume the developers are mostly JavaScript devs so their choice to use Electron/Node makes sense.

Qr 5.13 is based on Chrome 76-77

Most folks complaint with Electron isn't that it isn't performative, but rather that it is bloated (you ship an entire browser when all you needed was eg the canvas and v8 engine).

In all fairness, are you aware of a tool for web developers that only ships the canvas and v8 engine? Legitimately curious, because I've tried looking in the past for similar reasons (game dev on an engine I already know) and came up empty-handed.

WebGL is planned for graffiti

It's not finished yet but you can get close to 20M mem usage + overhead of your libs & assets. Executable size is node.js + 2M (30M total IIRC and it compresses nicely to ~10M *.dmg because node contains a lot of strings)

Please file an issue if you want it to happen so that it can be tracked how many people want it too (I had no idea that this is a thing in gaming community). It's now at the bottom of my priorities (I'm working on raspi support so that it can run as smartmirror) but it's not that hard to add so it could actually happen.

https://github.com/cztomsik/graffiti

I added a watch to it and starred; I think it'd be a good idea to be more clear with what's being built in the README.md because I wouldn't have thought that this was a stripped-down browser based on the headline. As well, it's difficult to see exactly what you are getting from graffiti (is it just canvas, does it include DOM stuff) at a glance which may turn away those browsing repos.

Agreed that README is very unclear - it's not a browser at all, actually. It's just a GUI library for rust & node.js which happens to have little DOM-like layer.

This pseudo-DOM is really just enough to make web frameworks work. I want to do GUI apps with the same tools & libs which I use for web development but I don't want to include the whole browser and moreover I want it to be enough resource-savvy so that it can run on my raspi attached to the TV.

It's hard to describe what it is good for because there are many use-cases. It's really rather a platform just like Electron or Qt is, but of course it's very limited now. But really, if you or anybode else have better headline, I'd love to hear it.

And thanks for the interest :-)

Just setup a localhost server and open the default browser on it.

Or just have a website, if you don't need privileged access to the user's machine.

Just in case you are not being facetious: totally agreed; but in the case of delivering a game on platforms that include Steam, and also for perception reasons, not really an option.

I've always dreamed for an Ejecta[0] like solution for desktop systems.

[0] https://github.com/phoboslab/Ejecta

This would be great, if only... Realistically, I just want a canvas with some audio/input stuff in most cases (though being able to put some divs in places may be nice for rendering things like menus).

I second this. Ejecta is beautiful and I really hoped the concept would catch on.

I looked a bit a few months ago. There are some interesting things out there. But you will probably be a bit on your own (but not uncommon when it comes to game dev though!)

https://github.com/mrautio/duktape-webgl

https://medium.com/@bnolan/translating-sites-into-3d-with-du...

They tend to use ~10x the memory that seems reasonable—generous, even—for what they're doing, and periodically misbehave and decide to eat tons of cycles continuously for no obvious reason, in a way native apps don't, or at least not so frequently and nigh-universally.

Sure, partial counterexample in VSCode, but then there's all the others.

I agree with what you are saying with regards to the tendency of the platform. But, aside from the weight of unnecessary/unused browser features, I think that has more to do with the needs of the developers attracted to the platform more than the platform itself.

"The needs" being a requirement to ship a MVP ASAP using developers that can agree on a lowest common denominator language of js.

I wonder if the VsCode coders don't share their SOP somewhere for us mere mortals to learn some techniques they use to keep electron under control.

> pywebview

Uses Edge or IE on Windows by default. Nope nope nope. :D

you can set it to use CEF, however

What about https://www.chromestatus.com/feature/6284708426022912 ?

QT is expensive for the indie developers.

A better choice would have been to simply use WKWebView in macOS and the equivalent in .NET/UWP for Windows.

Except for then you have to deal with whatever version of embedded Internet Explorer .NET uses. Maybe the UWP solution uses Edge now, but that still isn’t wonderful compared with embedding Chromium.

Usually in .NET you typically get IE, not Edge. People have been using CefSharp as a replacement. A number of software I have contributed to have done this.

In contrast, UWP applications do use the Edge rendering engine, and while it may or may not be possible to use CEF in these applications, you won't be able to get it certified by Microsoft, therefore no one, at least to my research, has bothered doing so.

I wonder what the future brings with Edge now just being chromium based

Nitpick: QT isn’t expensive if you agree to the LGPL. If you want to do your own thing, you have to pay up.

It is an html game, runs basically on a potato with electrical wires plugged into.

Most websites don't run well on even high end hardware. There's most certainly a performance tradeoff using a browser, especially for something as performance sensitive as a game.

There's a performance trade off using the DOM. If you only draw to canvases and execute javascript, the browser becomes a very fast engine.

i can vouch for back4app, satisfied client.

Parse server OSS (and b4a service) does help us in our development.

They could have just used flash

Even better, Haxe.

The language is very familiar for AS3 devs and it transpiles to performant C++.

Many games such as Papers Please have been made with Haxe.

There are numerous engines/libs for game devs:

http://kha.tech/

https://www.openfl.org

https://github.com/haxenme/NME

Just to add a little more... Haxe not only transpiles to C++, but it also transpiles to JavaScript. With a Haxe codebase, can deploy a project as both a native app and on the web. Really nice for games especially.

Haxe is really amazing. Currently my favorite ones are Kha and Luxe, though the new version of Luxe has been on development for a long time;

Kha is really nice and I like using it. It's amazing that the author developed a specialised IDE (granted it's a modified version of vscode) for the framework.

The quality is so very high, much much higher than a typical open source project, because it's not just a bit of code, but an entire toolchain and workflow. So much so that an entire engine is built off this framework! https://armory3d.org/

I am currently using Haxeflixel game engine for a trivial project and I am enjoying the overall experience. Haxe is a great little language a8the engine is fully featured. The basics like scene management, gui, pathfinding etc are bundled in.

I also tried Heaps which on paper looks amazing but could not proceed due to lack of documentation.

Dead Cells is another recent high-profile Haxe success story.

Nooooo. Flash is dead, thank god.[1]

1. https://www.rystedtcreative.com/tech-talks/flash-dead/

I remember steam games were made in Flash a few years ago. Doesn’t it just export to HTML5 these days? Isn’t it used / couldn’t it be used to make a steam game?

Yes, it does. Adobe changed its name to "Animate" once they got the HTML5 export working. Dunno if it's in use for any games nowadays.

You can also AOT compile, so that would be another option.