Of course, I don't think it would be worth writing your own game engine to work around that one bug, but at some point, one wonders how many oddities it takes to justify a rewrite. People still play the game despite this one bug that's existed (I hear) since launch, so I guess it was a good cost/benefit decision to use Unity. But for a game studio that prides themselves on polish, that particular bug makes me die a little inside every time it happens.
The joke from the java days was "Write once, crash anywhere!", although I suppose "Write once, freeze anywhere!" was more common unless you ran out of memory.
A bit of this is also just the fact that with Unity you don’t have to personally deal with the Android NDK, which is the software used as punishment in the fourth circle of hell, if I remember Inferno correctly.
I think this is more of an indictment of the Android NDK than anything else.
That's assuming the game is appropriate for a given platform. A mouse-based game with a lot of very small click targets (such as SimCity 2000) would not be playable on a touchscreen. The game would have to be dramatically re-designed to the point where it's a different game entirely. At that point, the advantage of having a "build for Android" button is greatly diminished.
If you're only targeting PCs (and I think most Indies are) then a framework like SDL gets you most of the way there to having your game run on Mac/Windows/Linux. It also does so without any of the financial cost of a proprietary engine and keeps things very simple so you can focus on building exactly what your game needs.
Not at all. Handling different input styles (mouse vs touch), while not trivial, is a tiny fraction of the other work listed above that goes into targeting multiple platforms. Unity/Unreal let you focus on just that tiny part that actually matters to your game.
> If you're only targeting PCs (and I think most Indies are)
This is also not remotely true. The current generation of consoles, in particular, have been huge for indies. The majority of the games released on them have been from indies. And if you're taking gamepad input, you don't really even have the input-mode speed bump when it comes to supporting multiple platforms at once. Probably the only concern you'd have to deal with is level-of-detail, but you'd have to do that for PC anyway, and the engines give you tools that assist with it.
- Either figure out how to transpile the language you're using to the one for each target platform, or find a runtime for it that will run there.
- Write unifying input-handling code across platforms; treating all analog sticks (PC, Playstation, Xbox, Switch, maybe touch screen sticks) the same, treating touch on iOS and Android (and mouse input?) the same, etc.
- Manually hook it up to each platform's SDK that you might want to target; each game console, iOS and Android, the web, etc. Graphics, resource loading, network access, audio.
This can be a massive undertaking, which is why most indie games that don't use a major engine just stay on PC.
Whereas in Unity I can take an existing project, with little to no knowledge of Android development, with zero code changes, and plug in a device and click "build for Android" and have it running flawlessly on-device in 5 minutes. Same for an embedded Web version. Presumably the same for iOS and Xbox and Playstation and Nintendo Switch, though I haven't tried those personally. But that's an enormous differentiator if you have any interest at all in making your game cross-platform down the road. Even Godot, while it supports mobile, doesn't support consoles out of the box.
Edit: Oh, and I forgot to even mention VR support. And cross-VR-platform support.