If I had a time traveling magic wand, the one Software Thing I would wish for would be that native, cross platform toolkits had won the war rather than the whole industry punting and declaring The Web Browser to be the target platform, or these super-high-level Game Engines. For decades, I always hopelessly thought the OS and hardware gaps would eventually be bridged by something like Qt or SDL or wxWidgets, and we'd all one day be happily programming cross platform apps using plain old native languages and SDKs instead of Electron or the HTML/CSS/JS triad of pain. As the years go on, and OS vendors move even more towards their own proprietary incompatible native APIs, this dream seems less and less likely.
Platform innovation requires control over your own API, because you want to expose the features and architectures that make your platform excel and that weren’t accounted for in abstracted tools. There will always be incompatible native API’s.
Meanwhile, a ton of apps and games are completely agnostic to those cutting edge platform differences and are going to thrive in least common denominator sandboxes. And making those sandboxes easy to use for some specific style/genre/skill-level is always going to be the competitive difference between them. So the big high-level things are always going to exist too.
But… so are the near-metal abstractions that let you cut through and interleave cross-platform and platform-specific code even in high-performance paths.
You wanted the last group to “win”, but the ecosystem inevitably involves all three. There will always be something like Metal, there will always be something like Unity, and there will always be something like SDL. Winning isn’t necessary.
What would make such a platform less of a compromise than a web browser?
How would programming in C++ be less pain than programming in JS / HTML / CSS? At the very least, JS code won't write past array bounds, or smash the stack.
From relevant olden times, Lisp and Smalltalk environments were closest to the ideal. They were expensive though, and nobody distributed them for free, as Netscape did with the browser. They also notably lacked any protections against untrusted code. But worst of all, they'd likely run even more poorly on consumer PCs circa 1995.
So, enjoy Typescript, V8, flexbox, canvas, web workers, etc. You could end up having a worse deal.
For that to happen, OS vendors would have actually had to care about sandboxing and security, to enable local execution of completely untrusted code without any gatekeeper. It's their complete security failure, still continuing today, that forces everyone to the web.
The other, slightly less important thing is petty rejection of cross-platform APIs (e.g. Apple's refusal to allow Vulkan support in macOS). It's fine to additionally have platform-specific APIs, but there should be a least common denominator cross-platform standard. But middleware can smooth over this problem, while the security problem is something only OS vendors could fix.
Unfortunately, the position of gatekeeper turned out to be so profitable that vendors don't actually want to improve their security to the point where it's unnecessary. And they're also incentivized to prevent the web from improving to the point where it would threaten their gatekeeper status.
Even without the time traveling, I would be happy if there was just a single stable, non-bloated, reliable, portable platform that could be used for when you just want to Write Once and then know that it will Run Everywhere _forever_ (* insert disclaimer about nothing literally lasting forever). Not something that rolls out breaking changes every six months. Or six years for that matter. Would not even have to be an entire API, just a clear declaration that a subset of some APIs will never change, and some tool to verify that my code did not accidentally use any of the other parts of the API.
Unfortunately running things in a browser is no guarantee, even for those that would otherwise consider that a good option.
Electron would be great if it weren't for the performance, security, configuration, and packaging issues. The latter two seem to be what OP suffered the most.
html/css/js (and the frameworks on top of it) seem like a pretty low bar to build games and business logic for a variety of apps which, despite huge efforts from OP, could run on pretty much any modern platform.
Flutter is actually pretty close to this right now. I'm building an app that targets Windows, Mac, iOS and Android and so far it's working really well on all of them with more than 90% code reuse.
If Google doesn't give up on it I think it's going to be a much better stack for cross platform applications than the browser is.
There's way more than enough room for both given how many million UIs get made. I think more time should be spent wondering why cross-platform toolkits aren't good enough. It's kind of lazy to point at the incumbent and say it's their fault for some reason.
Or framed this way: your dream exists and it's called Qt and can be used to make some absolutely fantastic applications[1]. What's deficient about it and why?
> Similar to developing for macOS, a Mac is pretty much required for developing for iOS and there’s the $100 per year developer membership fee. I think the combined income of both iOS and macOS (95% of which comes from iOS) barely covers the cost of the membership fee and the cheapest Mac Mini.
I think this contextualizes the post well, seems like overall revenues might be in the <$10k or even <$5k range. That's extremely hobby territory (/buying lottery ticket territory). Feels like at that scale a 'build whatever makes you happiest' heuristic is healthier for the individual and cross-platform support works against you.
Their MacOS revenues might have been <$10k, but given they have a 1000 reviews on Steam and their Android has 100K+ downloads I imagine the total revenue is more like >£80k
I suppose Steam handles Windows game installation, so you don't need Windows installer code signing. But it's worth pointing out that for non-Stream applications, compared to the cost of signing a Windows installer, the $99 yearly fee for Mac is an absolute steal. For windows, you need to get an EV code signing certificate and the cheapest option is $150 US per year, but you ALSO need a >$100 token device. Typical prices for a certificate are 300-500 USD per year.
Figuring out how to do production code signing on Windows, and where to go to get your app trusted after signing, is also way harder on Windows. In contrast, implementing Apple's code signing is both cheap and easy.
The token requirement is a pain. We settled on using Azure Key Vault and AzureSignTool [1]. It costs $5 a month for a HSM key and you can sign things from anywhere.
That's horrible and dastardly, but at least it's far easier for users to bypass SmartScreen on Windows than the block on Macs. I wonder how many Mac users actually know how to.
If you just get a regular (cheaper) code signing certificate I realise SmartScreen will still block you anyway until enough people have installed it, but how many is "enough"?
> Linux accounts for less than 1% of the total players
I think some types of games (think factory building, zachtronics style puzzle games, ...) might have a bigger percentage, though that's only a feeling I have, I don't have numbers myself, I just see such games more often have a Linux release on Steam that seems appreciated.
I published a not-super-popular (edit: but free) esoteric programming game on Steam and of the < 100 (Steam) hardware survey responses for people who have played my game, I'm seeing closer to 5% on Linux (edit to add: my game doesn't support Steam Deck).
I'm sure the hardware survey is biased towards Linux, but it's still a surprising result! Especially so, given that I originally only released the game on Windows (and later added Linux support after getting multiple requests to port the game).
That would make sense, the programmer crowd is more common on Linux and these are programming-like games. Looking at the authors games, they seem like the type of thing that would be more likely to do well on Linux (factory / automation). So the fact that he's still leaning towards it not being worth it financially seems notable.
Loved the article. My beef is debugging IOS Safari. It's so tragic that it's The Next IE™ but I can't debug it without a mac. There has always been ways to do it, but talk about jumping through hoops to see a debug window.
One issue with publishing a browser-based game that this article glosses over is: managing save data.
The browser provides Local Storage, but that isn't reliable as a "source of truth" since browsers (mostly on iOS, I think) may delete the data periodically (thanks, iOS, for deleting my Wordle history!) or when clearing browser history. Aside: the worst situation is when publishing on itch.io and playing on an iPad--your data appears to get saved to Local Storage but is actually wiped immediately to prevent cross-site tracking (itch.io hosts HTML5 games in a frame with a different domain).
Publishing on Steam, on the other hand, gives you durable file system storage and you can add cross-device syncing via Steam Cloud very easily. I'm holding out hope that something like remoteStorage will eventually catch on for browsers, but for now I don't really see a convenient solution.
If anyone has ideas for managing save data in a browser game that don't involve hosting user data myself (and dealing with account recovery, GDPR, etc.), let me know!
Web-first app, Electron for desktop, WebView for mobile.
I wonder how that compares to using an engine like Godot, Unity, or UE for cross-platform support? I love Electron and WebView is nice too, but neither would be my first choice for creating a video game. Personally, I'd prefer a native app that compiles to WASM for web support.
I noticed that too. Yes many games can be made this way but it's not what I think of when I think of making multi-platform games. At the same time if we could continue advancing web apps it would be more appealing, but does PWA even work everywhere?
"Saturated", as in the first usage under "Web", refers to market saturation. The word is questionably appropriate in the first case, and wrong in the second.
I suspect that what he means (in both cases), is that sales are low on both platforms, and they are not worth the effort to port to.
Does anyone know if, when you release a Windows game on Steam and it is played through Proton (eg the Deck or really anything, but the Deck is notable since it's a common platform), the dev would have any indication that the game is not in fact running on Windows? In a way, it doesn't matter, but I always wonder how these kinds of stats color how devs look at things.
But it seems like a lot of the other Mac issues are related to Steam.
A normal Mac app sold online or through the store wouldn’t need special entitlements for dylib loading, and Xcode could easily handle all the signing for you. Xcode cloud could help too with builds.
I don’t think the game being Electron would matter there.
> It turns out that unless the game is explicitly marked (by Valve reviewers), Steam Deck will use the Windows build + Proton even if a Linux version is available.
I found this which sounds like it's not the default, but is in fact a result of compatibility testing:
> If your game has gone through Steam Deck compatibility testing and the testers reported that the native Linux version didn't work (because of #579), then it might have been flagged to run the Windows binaries via Proton by default, instead of the native Linux version.
For those interested in cross platform game development, don't forget https://haxe.org/! The usefulness / popularity ratio is very high on this one :).
As the post mentions, the de-facto official way to distribute games on linux is as a windows binary run via wine/proton. AFAIK this mainly stems from issues in how linux deals with graphics drivers - you can static link everything _except_ opengl. This is similarly an issue with containerizing graphical apps: last I read you needed to have the same version graphics libraries both on the host system and _within_ the container due to the weird linking issues.
Does anyone know if there's any efforts to improve this situation? Is there some ideological issue in linux that prevents standardizing or presenting a generic interface?
(Or more background, my details are very vague here)
> As the post mentions, the de-facto official way to distribute games on linux is as a windows binary run via wine/proton.
It absolutely isn't unless you hate your users.
> you can static link everything _except_ opengl
You don't need to statically link OpenGL - it has a stable ABI and most functions need to be loaded at runtime anyway.
> This is similarly an issue with containerizing graphical apps: last I read you needed to have the same version graphics libraries both on the host system and _within_ the container due to the weird linking issues.
You don't need to worry about containers when distributing native Linux games.
> Does anyone know if there's any efforts to improve this situation? Is there some ideological issue in linux that prevents standardizing or presenting a generic interface?
Excellent post. This is why I’ve given up on trying to monetize my web game (https://www.farmhand.life/) and just give it away for free as OSS. The money I’d make would not justify the effort needed to actually capture it.
Surprised to see "Code signing with a hardened runtime is almost a must." under Steam (Mac OS). I released a game on steam and never had my distributables signed and never had a single complaint. Every player launches Steam games through Steam, and when that happens there's no need for signing.
> All the revenue from the platform does not even cover 10% of the cheapest Mac Mini. And then there’s the $100 per year developer membership fee for notarization
Same experience for my iOS games.
Apple should more friendly for sole indie developers. (But maybe they really don't need to care about this now?)
[+] [-] ryandrake|2 years ago|reply
[+] [-] swatcoder|2 years ago|reply
Meanwhile, a ton of apps and games are completely agnostic to those cutting edge platform differences and are going to thrive in least common denominator sandboxes. And making those sandboxes easy to use for some specific style/genre/skill-level is always going to be the competitive difference between them. So the big high-level things are always going to exist too.
But… so are the near-metal abstractions that let you cut through and interleave cross-platform and platform-specific code even in high-performance paths.
You wanted the last group to “win”, but the ecosystem inevitably involves all three. There will always be something like Metal, there will always be something like Unity, and there will always be something like SDL. Winning isn’t necessary.
[+] [-] nine_k|2 years ago|reply
How would programming in C++ be less pain than programming in JS / HTML / CSS? At the very least, JS code won't write past array bounds, or smash the stack.
From relevant olden times, Lisp and Smalltalk environments were closest to the ideal. They were expensive though, and nobody distributed them for free, as Netscape did with the browser. They also notably lacked any protections against untrusted code. But worst of all, they'd likely run even more poorly on consumer PCs circa 1995.
So, enjoy Typescript, V8, flexbox, canvas, web workers, etc. You could end up having a worse deal.
[+] [-] modeless|2 years ago|reply
The other, slightly less important thing is petty rejection of cross-platform APIs (e.g. Apple's refusal to allow Vulkan support in macOS). It's fine to additionally have platform-specific APIs, but there should be a least common denominator cross-platform standard. But middleware can smooth over this problem, while the security problem is something only OS vendors could fix.
Unfortunately, the position of gatekeeper turned out to be so profitable that vendors don't actually want to improve their security to the point where it's unnecessary. And they're also incentivized to prevent the web from improving to the point where it would threaten their gatekeeper status.
[+] [-] livrem|2 years ago|reply
Unfortunately running things in a browser is no guarantee, even for those that would otherwise consider that a good option.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element#ob...
[+] [-] ugh123|2 years ago|reply
html/css/js (and the frameworks on top of it) seem like a pretty low bar to build games and business logic for a variety of apps which, despite huge efforts from OP, could run on pretty much any modern platform.
[+] [-] cageface|2 years ago|reply
If Google doesn't give up on it I think it's going to be a much better stack for cross platform applications than the browser is.
[+] [-] ClimaxGravely|2 years ago|reply
Examples
- SDL
- GLFW
- Openframeworks
- Monogame/FNA/XNA/etc
- Haxe
[+] [-] Kiro|2 years ago|reply
[+] [-] reductum|2 years ago|reply
https://orca-app.dev/posts/230607/orca_announcement.html
[+] [-] zubairq|2 years ago|reply
[+] [-] bullen|2 years ago|reply
Flash also was this.
Now the browser is just a bloated pile of crap.
[+] [-] Waterluvian|2 years ago|reply
Or framed this way: your dream exists and it's called Qt and can be used to make some absolutely fantastic applications[1]. What's deficient about it and why?
[1] https://musescore.org/en
[+] [-] npunt|2 years ago|reply
> Similar to developing for macOS, a Mac is pretty much required for developing for iOS and there’s the $100 per year developer membership fee. I think the combined income of both iOS and macOS (95% of which comes from iOS) barely covers the cost of the membership fee and the cheapest Mac Mini.
I think this contextualizes the post well, seems like overall revenues might be in the <$10k or even <$5k range. That's extremely hobby territory (/buying lottery ticket territory). Feels like at that scale a 'build whatever makes you happiest' heuristic is healthier for the individual and cross-platform support works against you.
[+] [-] alberth|2 years ago|reply
Just say’n.
[+] [-] moritonal|2 years ago|reply
[+] [-] kevingadd|2 years ago|reply
https://howtomarketagame.com/2022/11/28/the-median-indie-gam...
[+] [-] Clamchop|2 years ago|reply
[+] [-] tensor|2 years ago|reply
Figuring out how to do production code signing on Windows, and where to go to get your app trusted after signing, is also way harder on Windows. In contrast, implementing Apple's code signing is both cheap and easy.
[+] [-] veeti|2 years ago|reply
It's not a protection racket...
[1] https://github.com/vcsjones/AzureSignTool
[+] [-] versteegen|2 years ago|reply
If you just get a regular (cheaper) code signing certificate I realise SmartScreen will still block you anyway until enough people have installed it, but how many is "enough"?
Also, previously: "Microsoft Defender SmartScreen is hurting independent developers" https://news.ycombinator.com/item?id=23392404
[+] [-] Aardwolf|2 years ago|reply
I think some types of games (think factory building, zachtronics style puzzle games, ...) might have a bigger percentage, though that's only a feeling I have, I don't have numbers myself, I just see such games more often have a Linux release on Steam that seems appreciated.
[+] [-] schemescape|2 years ago|reply
I'm sure the hardware survey is biased towards Linux, but it's still a surprising result! Especially so, given that I originally only released the game on Windows (and later added Linux support after getting multiple requests to port the game).
[+] [-] suby|2 years ago|reply
[+] [-] mvdtnz|2 years ago|reply
[+] [-] Iulioh|2 years ago|reply
1%->2%
[+] [-] Bellend|2 years ago|reply
[+] [-] schemescape|2 years ago|reply
The browser provides Local Storage, but that isn't reliable as a "source of truth" since browsers (mostly on iOS, I think) may delete the data periodically (thanks, iOS, for deleting my Wordle history!) or when clearing browser history. Aside: the worst situation is when publishing on itch.io and playing on an iPad--your data appears to get saved to Local Storage but is actually wiped immediately to prevent cross-site tracking (itch.io hosts HTML5 games in a frame with a different domain).
Publishing on Steam, on the other hand, gives you durable file system storage and you can add cross-device syncing via Steam Cloud very easily. I'm holding out hope that something like remoteStorage will eventually catch on for browsers, but for now I don't really see a convenient solution.
If anyone has ideas for managing save data in a browser game that don't involve hosting user data myself (and dealing with account recovery, GDPR, etc.), let me know!
[+] [-] hoten|2 years ago|reply
It's getting some improvements soon (at least from Chrome), currently requires renewing approval on every page load. https://bugs.chromium.org/p/chromium/issues/detail?id=101153...
It works well for my use case. If you want to see it in action: https://web.zquestclassic.com
The problem of course is not all browsers support. As a backup, I use either indexdb or local storage.
[+] [-] calibas|2 years ago|reply
I wonder how that compares to using an engine like Godot, Unity, or UE for cross-platform support? I love Electron and WebView is nice too, but neither would be my first choice for creating a video game. Personally, I'd prefer a native app that compiles to WASM for web support.
[+] [-] karmakaze|2 years ago|reply
[+] [-] kaz-inc|2 years ago|reply
I'd assume webview apps could be more accessible rather easily, and it would take care and attention to make a native wasm app accessible.
[+] [-] Narishma|2 years ago|reply
[+] [-] sdwr|2 years ago|reply
I suspect that what he means (in both cases), is that sales are low on both platforms, and they are not worth the effort to port to.
[+] [-] schemescape|2 years ago|reply
[+] [-] Tobu|2 years ago|reply
[+] [-] pjmlp|2 years ago|reply
If I want to play a WebGL game, I use the browser.
[+] [-] IggleSniggle|2 years ago|reply
[+] [-] reactordev|2 years ago|reply
[+] [-] MBCook|2 years ago|reply
But it seems like a lot of the other Mac issues are related to Steam.
A normal Mac app sold online or through the store wouldn’t need special entitlements for dylib loading, and Xcode could easily handle all the signing for you. Xcode cloud could help too with builds.
I don’t think the game being Electron would matter there.
[+] [-] rendaw|2 years ago|reply
I found this which sounds like it's not the default, but is in fact a result of compatibility testing:
> If your game has gone through Steam Deck compatibility testing and the testers reported that the native Linux version didn't work (because of #579), then it might have been flagged to run the Windows binaries via Proton by default, instead of the native Linux version.
per https://github.com/ValveSoftware/steam-runtime/issues/585
[+] [-] koonsolo|2 years ago|reply
[+] [-] rendaw|2 years ago|reply
Does anyone know if there's any efforts to improve this situation? Is there some ideological issue in linux that prevents standardizing or presenting a generic interface?
(Or more background, my details are very vague here)
[+] [-] account42|2 years ago|reply
It absolutely isn't unless you hate your users.
> you can static link everything _except_ opengl
You don't need to statically link OpenGL - it has a stable ABI and most functions need to be loaded at runtime anyway.
> This is similarly an issue with containerizing graphical apps: last I read you needed to have the same version graphics libraries both on the host system and _within_ the container due to the weird linking issues.
You don't need to worry about containers when distributing native Linux games.
> Does anyone know if there's any efforts to improve this situation? Is there some ideological issue in linux that prevents standardizing or presenting a generic interface?
Yes, for one you could stop spreading FUD.
[+] [-] itsmebucky|2 years ago|reply
[+] [-] jckahn|2 years ago|reply
[+] [-] samanbb|2 years ago|reply
[+] [-] tapirl|2 years ago|reply
Same experience for my iOS games.
Apple should more friendly for sole indie developers. (But maybe they really don't need to care about this now?)
[+] [-] cpill|2 years ago|reply
> Currently all HTML5 games on itch.io are set up to only take payments as donations
Seems like a big hole on the market? Anyone interested in setting up a online games payment gateway?
[+] [-] unknown|2 years ago|reply
[deleted]