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.
Great read, very eye opening.<p>> 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.<p>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.
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. <i>Typical</i> prices for a certificate are 300-500 USD per year.<p>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.
> Linux accounts for less than 1% of the total players<p>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.
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.<p>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).<p>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.<p>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.<p>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.
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.
I won’t dispute the cost issues with the Mac.<p>But it seems like a lot of the other Mac issues are related to Steam.<p>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.<p>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.<p>I found this which sounds like it's not the default, but is in fact a result of compatibility testing:<p>> 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.<p>per <a href="https://github.com/ValveSoftware/steam-runtime/issues/585">https://github.com/ValveSoftware/steam-runtime/issues/585</a>
For those interested in cross platform game development, don't forget <a href="https://haxe.org/" rel="nofollow noreferrer">https://haxe.org/</a>! 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.<p>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?<p>(Or more background, my details are very vague here)
Excellent post. This is why I’ve given up on trying to monetize my web game (<a href="https://www.farmhand.life/" rel="nofollow noreferrer">https://www.farmhand.life/</a>) 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<p>Same experience for my iOS games.<p>Apple should more friendly for sole indie developers. (But maybe they really don't need to care about this now?)
Its weird that there is no online portal for selling access to HTML5 games. Itch doesn't really do it<p>> Currently all HTML5 games on itch.io are set up to only take payments as donations<p>Seems like a big hole on the market? Anyone interested in setting up a online games payment gateway?
I'm going for the productive compromise:<p>Windows on X86 and Linux on ARM<p>Everything else is a waste of time.<p>For revenue I'm going with <a href="http://itch.io" rel="nofollow noreferrer">http://itch.io</a>
Really nice article, i was waiting for a conjecture of the dropped support of CS2 on IOS but it was still a good read :)<p>Brb going to download idle industry