14 ms·
One game, by one man, on six platforms: The good, the bad and the ugly
- ryandrake 3y agoIf 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.
- swatcoder 3y agoPlatform 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.
- loup-vaillant 3y ago> 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. Yeah, I’m not buying that. It’s the story they tell you of course, but I think that’s a marketing lie. Let’s be clear first that hardware is the platform. Your comment seems to agree with that. Note that for quite a long time, the Windows and Mac world used the same hardware (same CPU, same GPU), and therefore the same platform. They could have went together and specified a common API to work on both MacOS and Windows, and they could both expose all the hardware has to offer. Heck, if they really wanted to expose all the goodness hardware has to offer, they would give us the actual data sheets. They don’t, for various reasons that are generally tied to "IP". They tell us sweet words about innovation, but let’s be honest they just want to lock us in.
- andybak 3y agoBoth things can be true.
- loup-vaillant 3y agoI was trying to respond to "Platform innovation requires control over your own API". The short answer "no it does not": look at CPUs, we just need their ISA to take advantage of any improvement. In fact, the best way to expose any hardware improvements is to give us the data sheet. Gate keeping direct access to the hardware with an API effectively reduces user access to innovation. One could criticise how I conflate hardware and platform. I’ll just note that all the goodness we’ve seen the past 40 years were made possible by hardware. Personally I saw precious little innovation coming from software specifically. So even if a platform is more than just hardware, actual innovation mostly comes from hardware anyway.
- pjmlp 3y agoEven UNIX isn't one platform, hence why POSIX is only good for CLI applications.
- nine_k 3y agoWhat 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.
- AgentME 3y agoI think people really underrate browsers. The browser standards are open and have multiple open source implementations. People associate browsers too much with annoying trashy ad-based and other questionable websites to see how good they are themselves. Electron has an annoyingly heavy download size but it's not the only option for native releases of web-based apps. Windows and some other OSes have built-in browser widgets that can be used with Tauri.
- nine_k 3y agoBrowsers are absurdly well-optimized for performance. If you know how to tap it, you can make screaming-fast apps of various kinds, with top-notch graphics, font rendering, accessibility support, audio, video, etc. They also have really solid networking capabilities, as long as you don't need raw TCP or UDP. In particular, HTTP/2, HTTP/3, WebSockets, and WebRTC allow for a lot of advanced things. By now, you also have WebGL and WASM, if JS's JIT is not fast enough for you.
- ClimaxGravely 3y agoI've definitely seen some really well optimized web targets. Unfortunately that is not the common case in my experience currently. That said the WebGL/WASM stuff is generally very nice in my experience and is very much changing my opinion. I'm interested to see what comes in the future!
- ClimaxGravely 3y agoFor games SDL still gets a good amount of usage. As do a few other frameworks that I think fit your criteria if I understand you correctly. Examples - SDL - GLFW - Openframeworks - Monogame/FNA/XNA/etc - Haxe
- a1o 3y agoIf you think any of these will save you from the issues of cross platform development and platform specifics, in a different way from what is described by the post, you are wrong. You will still suffer with notarization and appleness, Android stuff being pressured by Play Store policies changing constantly, and every platform/store specifics, adapting controls, form factors, gestures...
- ClimaxGravely 3y agoI have used these for published cross platform development. They don't solve everything but they certainly make things easier. Some of the issues you are describing would still exist even if I wasn't using a cross platform library.
- Waterluvian 3y agoThere'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? [1] https://musescore.org/en https://musescore.org/en
- Kiro 3y agoSounds like you're talking about software and apps in general, not games. 99% of game developers do not use web technologies.
- IggleSniggle 3y agocough Switch cough
- ClimaxGravely 3y agoDoes switch use web targets a lot? I haven't noticed that personally (I tend to mostly only play first part switch games though)
- Kiro 3y agoDo you mean games or their UI? Or do you mean that people are not using web due to Switch not being a valid target? No idea how the platform works.
- modeless 3y agoFor 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.
- ugh123 3y agoElectron 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.
- Andrex 3y agoIt's a shame opening local HTML pages is so heavily restricted in modern browsers. I mean, I get it, but we also might not need Electron if you could stuff everything into a single HTML file and let users download that as your "app."
- modeless 3y agoThat's what PWAs are supposed to be. Many if not most Electron apps could and should be PWAs.
- oldbbsnickname 3y agoNative is the only way to go. The problem of the mythology of cross-platform (pseudo-)development is having to know both the underlying platform AND the abstraction layer. This explains why RubyMotion, PhoneGap/Cordova, and Appcelerator/Titanium were flops, and so shall Microsoft's MAUI. There is nothing for free. Abstractions cost performance and confuse troubleshooting.
- zubairq 3y agoCould Flutter from Google be considered a good enough solution?
- halostatue 3y agoOnly if you don't value your battery life, usability, proper accessibility, or developer ergonomics with a language that has no raison d’être.
- Apocryphon 3y agoWhat's the evidence that battery life is substantially worse than native? Take this performance for example. https://www.orientsoftware.com/blog/flutter-vs-react-native-performance/ https://www.orientsoftware.com/blog/flutter-vs-react-native-... While the framework had issues with accessibility in the past, seems like they've been adding a lot to improve it. https://www.kodeco.com/35275067-flutter-accessibility-getting-started https://www.kodeco.com/35275067-flutter-accessibility-gettin... Dart is a simple, no-frills language. It's not used outside of Flutter but what is wrong with its semantics or anything inherent about it?
- cageface 3y agoFlutter 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.
- Capricorn2481 3y ago> 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. When I read this, I don't know if you're saying it's not ready yet or something. Is it close but not there yet? Do you experience bugs?
- cageface 3y agoNo so far I've had a great experience with it. But keeping up with new improvements and changes to the underlying platforms is going to require ongoing investment. Hopefully google continues to think it's worth it.
- halostatue 3y agoFlutter has a multitude of problems, at Google's inability to support anything long-term is probably the smallest. Flutter apps don't look or work like native apps, and the only people who will put up with that are people who have to do so because their enterprise mandates it. Flutter apps have horrible battery performance. Flutter apps are always at least six months behind what is possible with native toolkits and SDKs. Flutter apps use a language that literally no one other than Sass or Flutter developers actually want to use and that offers exactly no benefit over the dozens of other possible languages out there. Flutter is Java Swing, but worse in pretty much every way.
- cageface 3y agoThis doesn't match my experience at all. It's leagues ahead of react native in memory usage, disk space, responsiveness etc. Users are used to apps that don't look much like the out of the box platform toolkit by now. Even apple isn't very consistent about this anymore. Native is better if course if you have the luxury of writing your app twice or three times but not many of us do.
- livrem 3y agoEven 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. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/HTML/Element#obsolete_and_deprecated_elements https://developer.mozilla.org/en-US/docs/Web/HTML/Element#ob...
- oli-g 3y agoIsn't .NET Core pretty much what you're describing at this point?
- livrem 3y agoI must admit I never looked at that ecosystem. Does it just happen to have been quite stable or is it a serious design decision they made and are sticking to? From a quick search I do not get the impression that .NET has been deprecating parts of the API, including Core APIs, in the past, e.g.: https://learn.microsoft.com/en-us/dotnet/core/compatibility/fx-core https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
- stanac 3y ago.NET was pretty stable. I remember porting old .NET Framework 4.x MVC web app to .NET Core 2, and then to .NET 5. Both times it took less than an hour to port. Old directory structure and APIs still work even if they are not the new hot way to do things. Microsoft is known for backward compatibility.
- 3y ago
- bullen 3y agoThe Java Applet was this. Flash also was this. Now the browser is just a bloated pile of crap.
- Capricorn2481 3y agoAs opposed to Java applets?
- bullen 3y agoJava is the best thing we have gotten since C in 1970. That was 30 years ago. Since then everyone has been copying Java: C#, WASM, Go, Rust... nothing even scratches the surface. And it never was insecure, it was removed by the same people that leverages consume only devices and root certificates. That said I'm actually a proponent of bringing back the MIDlet, J2ME was the best software platform ever created.
- Capricorn2481 3y agoYou misunderstand me. I think Java's great. Java applets were quite bloated. moreso than Electron. You can still make Java Applets if you want, but people have moved on.
- bullen 3y agoApplets where bloated by programmers, my Applets where super lean. No, I can't develop Applets, they are disabled in all browsers.
- reductum 3y agoYou may find the Orca project quite interesting: https://orca-app.dev/posts/230607/orca_announcement.html https://orca-app.dev/posts/230607/orca_announcement.html
- Aardwolf 3y ago> 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.
- Iulioh 3y ago"100% more linux users than the average!" 1%->2%
- schemescape 3y agoI 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).
- mhitza 3y agoFeel free to name you're game so that I and others can check it out. It's not frowned upon to link to your paid for content if it's relevant to the topic/comment thread discussion.
- astura 3y agoIt's in their profile - https://github.com/jaredkrinke/sic1 https://github.com/jaredkrinke/sic1
- Pannoniae 3y agoThank you for showing me this wonderful game. That 5% is going to get a tiny bit higher:) You could consider having a donation "DLC" for the game, I would happily pay for it.
- deleted 3y ago[deleted]
- Iulioh 3y agoReally nice article, i was waiting for a conjecture of the dropped support of CS2 on IOS but it was still a good read :) Brb going to download idle industry
- deleted 3y ago[deleted]
- schemescape 3y agoOne 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!
- Vinnl 3y agoPossibly https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system https://developer.mozilla.org/en-US/docs/Web/API/File_System...?
- hoten 3y agoFF only support the origin private interface for the FSAPI, which has all the same problems re: persistence as local storage
- hoten 3y agoYes, the FileSystem API works well. 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=1011533 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 https://web.zquestclassic.com The problem of course is not all browsers support. As a backup, I use either indexdb or local storage.
- BlueTemplar 3y ago
- npunt 3y agoGreat read, very eye opening. > 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.
- Clamchop 3y agoOn the other hand, it's hard to predict where your product needs to be to find a spark that sets a fire.
- inhumantsar 3y agoI don't feel like it's terribly hard to predict that the Mac gaming market is going too small to make financial sense for a solo-dev game
- reactordev 3y agoThere is a market but not for the hobbyist. You have better luck on iOS than macOS for games. However, tools, you can make a killing selling simple tools with sexy UX on Mac.
- iamstupidsimple 3y ago> However, tools, you can make a killing selling simple tools with sexy UX on Mac. I've been thinking about doing something like this recently but I'm not a heavy mac user these days. Any tips on what people are looking for in small tools?
- reactordev 3y ago
- Narishma 3y agoWhat do they mean when they say Linux is saturated?
- schemescape 3y agoGood question. From context, maybe they meant "diverse"?
- MBCook 3y agoThat was my read too, though I haven’t seen the term used that way before.
- sdwr 3y ago"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.
- Tobu 3y agoI think the word they were looking for is "fragmented".
- Bellend 3y agoLoved 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.
- nine_k 3y agoApple is a hardware appliance company. They are not interested in you touching anything in their ecosystem not buying a Mac.
- bigstrat2003 3y agoIn this case they're shooting themselves in the foot. By requiring potential developers to own a Mac, they sharply limit their developer audience. Thus, fewer apps being made for their platform, thus fewer apps to drive using the platform, thus fewer sales of their precious hardware.
- nine_k 3y agoThey showed time and again that they don't want a too-wide developer audience. They already have too many apps, and see the choice fatigue in users. They want big companies professionally produce polished stuff that commands, say, $14.99 in app store, of which $5 is Apple's share. They want stuff like Beatmaker or ProCreate. Small fry need not apply; if they insist, they should at least clear the threshold of owning a Mac and paying $100/year for the App Store license.
- bigstrat2003 3y ago> They showed time and again that they don't want a too-wide developer audience. Indeed. And that is (one reason) why Mac will never be more than a third-rate platform. As I said, they're shooting themselves in the foot.
- guraf 3y ago
- itsmebucky 3y agoConcernedApe did a fantastic job maintaining the game on various platforms.
- MBCook 3y agoI won’t dispute the cost issues with the Mac. 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.
- calibas 3y agoWeb-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.
- karmakaze 3y agoI 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?
- kaz-inc 3y agoI wonder the difference between SDL or other native app dev VS webview and html for accessibility. 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.
- IggleSniggle 3y agoDoes 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.
- reactordev 3y agoSteam will track this for you. They have some excellent metrics.
- tensor 3y agoI 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.
- versteegen 3y agoThat'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"? Also, previously: "Microsoft Defender SmartScreen is hurting independent developers" https://news.ycombinator.com/item?id=23392404 https://news.ycombinator.com/item?id=23392404
- tonyedgecombe 3y agoI think the regular (cheaper) code signing certificates are going away soon.
- veeti 3y agoThe 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. It's not a protection racket... [1] https://github.com/vcsjones/AzureSignTool https://github.com/vcsjones/AzureSignTool
- samanbb 3y agoSurprised 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.
- julianeon 3y agoThis is a great idea for a game, btw.
- rendaw 3y agoAs 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)
- account42 3y ago> 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? Yes, for one you could stop spreading FUD.
- rendaw 3y ago> 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. per https://github.com/ValveSoftware/steam-runtime/issues/585 https://github.com/ValveSoftware/steam-runtime/issues/585
- tapirl 3y ago> 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?)
- koonsolo 3y agoFor those interested in cross platform game development, don't forget https://haxe.org/ https://haxe.org/! The usefulness / popularity ratio is very high on this one :).
- pjmlp 3y agoNow Electron has infected games as well. If I want to play a WebGL game, I use the browser.
- bullen 3y agoI'm going for the productive compromise: Windows on X86 and Linux on ARM Everything else is a waste of time. For revenue I'm going with http://itch.io http://itch.io
- cpill 3y agoIts weird that there is no online portal for selling access to HTML5 games. Itch doesn't really do it > 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?
- brainzap 3y agoPlease consider porting to macOS, I will buy it, I will send you thank you letter.
- jckahn 3y agoExcellent post. This is why I’ve given up on trying to monetize my web game (https://www.farmhand.life/ 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.
- asrael_io 3y agoSo, purely from an economic standpoint: Windows is the only platform.
- glimshe 3y agoAs it has been for 30 years...