If Unreal was ever an option, developers would've been using it instead of Unity in the first place.
I certainly like Unreal, myself, but I can't say it's an easy move from Unity to Unreal. That aside, one of the very first options you see is whether to scope your game for mobile or for "desktop", so I'm not sure why this commenter thinks that Unreal would not be an option for mobile development. It sucked before UE5, so maybe that's the hang up, but so did a lot of things.
Unfortunately, I know what I'm talking about. I've even modified the Unreal source to get a package size of 20mb, for a full game. I've digged through configurations to enable a simple forward renderer. I've faked all lights since a simple lit material would destroy performance.
That was on Unreal 4.20, I don't know how much has changed ever since, but probably not much since I don't see any low-end mobile improvements on the roadmap, they're all focused on high end.
Still, Unreal sucks for mobile, compared to Unity. It's unperformant to run on a mobile, and unpleasant to work with. It supports mobile? Yeah. Should it be used for mobile? Nope.
Also, you've just mentioned that you're using a hacky workflow to work with 2D. You're already sacrificing too much, for something that would work better in Unity.
Source: Worked on a company that had a mobile Unreal game. It ended up being ported to Unity.
All that said, yeah - 70MB is perfectly "small" in the context of a mobile game. Hell, I WISH 70MB was normal. These days, you'll eat up 300MB on a game just so it can serve you an ad network with 80% of your screen time. The mobile games market is a travesty.
- The built in Contacts app
- Degiro (investment management)
- Doubletwist (music player)
- Sony Headphones
Some apps above 150mb:
- Element (chat)
- Kindle reader
- Pocket Casts (podcast player)
I don't have too many games installed but layton and the curious village, a point and click DS port, is 700mb (10x larger than on its original platform of the DS). I guess a lot of that increase is replacing 200p backgrounds with 1080p and midis with audio recordings.
Filesize is a weird one to complain about - that ship has long sailed.
Not everyone is living in the first world with flagship devices, unless you mean only those are entitled to play games.
Right, but unity and unreal performance were possible to make adequate on my HTC One M7 a decade ago, a device so old that you can't publish apps compatible with it to the play store any more because of the minimum target SDK version rules.
To be fair I don't care about the app size either (Though once you reach a threshold, you'll have to care, since extra config is involved in the stores), I just wanted to point across how much work you have to do in Unreal to reach what Unity does by default, and app size is just an easy unit to explain.
> Jesus christ. You say I'm absolutely incorrect, yet you're happy with a default package of 70MB?
It's true that 70MB is very small for games, especially if you're talking about something with 3D contexts and meshes. But it is also true that most mobile games could be built with Javascript and still be just as performant and served as Progressive Web Apps in less than an MB. So, in the frame of reference, 70MB is gargantuan. I certainly understand why OP took offense, because their frame of reference isn't "all games", it's "games that focus on these very specific metrics I care about".
If that's your only criteria, then obviously Unreal would be bad because it doesn't optimize ONLY for size, it optimizes for a bunch of other stuff, and leaves a lot of optimization on the table for devs to do on their own. Of course, all of that is true of Unity too, which is why you can get smaller package sizes (20MB is not impossible for Unreal, but it's easier with Unity), but you still can't come even close to something that is "efficiently" packaged. For that, you'd need to move into lower level stuff like engines and frameworks in Rust or C++. Eschew the niceties of the IDE and really get that package size down to zero!
Of course, that's not feasible for a lot of people, so (as always) you're talking about what kinds of things you're trying to optimize for. And Unreal produces package sizes well within the range of acceptability for even Unity games. Most of those are at least 200MB+. So it's a petty complaint made from a place of self-interest, that is only true in contrived instances, which seemed worth pointing out.
As a stray aside, though: I have had games developed in both Unreal and Unity on the play and app stores and no one ever said anything about performance on either of them, so I really don't know what kind of devving OP is talking about that results in such poor performance. I can't imagine I'm doing anything uncommon, so I'm very curious as to what the hang ups are, mainly in a "are you sure you're doing this the Unreal way, instead of trying to force the Unity way in Unreal?" kind of way.
As far as "hacky workflow", I don't know what I said to make you believe that. The Unreal UI is a vector rendering process. Same as a browser's rendering context. Or most form designers like ImGUI or WinForm or Qt. I used the Unreal UI just like I used any of those APIs - using what they've already provided where it works and rolling my own controls were it doesn't. It's no different either in conceptual development or in literal programming routines than manipulating a website's DOM or a Canvas element with javascript. It is, in short, a 2D context; same as any other 2D context.
https://sampruden.github.io/posts/godot-is-not-the-new-unity...
This is the reason people were already fed up with it, this license change just pushed some over the top.
The trajectory of this project is not good at the moment and that is as much of a problem for users as the recent events.
I started a project 3 years ago and none of the features I based it on shipped with production quality in the meanwhile (and that was the assumption when going in back then, that this will eventually be fixed while development of the game was going on).
Godot is certainly not optimal, that is what people are discussing. The C# and expert userbase was missing. But the fact that people are raising these points meens that they see it worth to comment on. If Godot leadership takes the hint, they might bring their project to a trajectory which allows serious projects to give it a shot. So this time now will be critical. For both, Unity and their competitors.
I think none of the conversations and comments put out there are surprising. But I would argue that if people already had the motivation to switch, they might just go to Unreal if Godot gives them not enough performance. Or stay with Godot if their project is simple enough to be not effected.
For example, I see my Twitter timeline full of people slowly realizing that Godot is not Unity 2, and complaining about the UX, GDScript, C# and performance problems.
So, they either have to live on that hill and contribute to Godot (And sometimes these problems are by design! Godot is made to be slow so it can have more usability, just check out the creator's Twitter),
or, y'know, they can (And will) just go back to Unity and keep making stuff, even if they at any moment they'll put a knife on your throat.