I’ve seen a fair bit of hate for Unity over the years. It makes me wonder how much of it was valid. The usual example being “x game could never be made in Unity” (Factorio, Space Engineers, Starsector, etc). I’m by no means an expert, or even someone who could be mistaken for competent, but I feel like most realistic limitations for any engine would boil down to how creative you can get with optimizations and how much time you’re willing to invest in cleaning up. I’ve never stepped past simple self contained minigames. Are there serious hurdles present when you take on large projects in Unity that aren’t extant in other engines? Is there a game on the market that couldn’t, at the very least, be roughly approximated with it?
The common belief is that in case of unity while prototyping is fast you might stumble into a huge problem on polish phase.
From my personal opinion, the biggest issue is lack of proper C++ support. C# has its limitations.
The games you listed can be done in unity, but it is likely that at some point you’d need to dive quite deep into optimizations. For example, Empyrion is Unity, and I think Starship Evo is unity as well.
4 Likes
I think limitations is the wrong question. With tremendous amounts of effort, time and money you can probably hack your way around everything and anything.
The question is, do you want to be hacking your way around stuff, or do you want to design your game?
Are the features supplied to you in some decent ratio of robust, easy to use and performant?
If a feature’s not robust at all, it probably won’t suit your game, so it might as well not exist.
If it’s not easy to use at all, you are probably better off designing your own feature rather than hating being born into this world every time you use it.
If it’s not performant enough, you will eventually hit a wall, where your biggest performance problem is this feature and you have no choice but to spent a ton of time ripping it off your project and replacing it with something else.
IMO, Unity’s features do not fare well enough in the above areas.
Unity’s general feature design philosophy (if there is one) is also kinda insane.
Some features are like shitty undocumented low level APIs where the user is expected to do everything, where I can imagine designers tossing the feature to their users like garbage while wishing them good luck under their breath.
Other features are fischer price toys that do 1 thing well enough to get a blog post out of them, but out of the box they do absolutely nothing else and will be of no use to you unless you need that exact 1 thing and nothing else, which has me imagining Unity designers thinking “our users are so stupid, this is probably already more than they can handle”.
And a whole lot of other features that are so slow (and have been for years) that there is almost no game, no matter how simple, that can use them and also perform decently.
Combine all that with an editor that is unpleasant to use, and the velocity vector for that is not going towards improvement, despite effort from Unity’s side, and Unity, IMO, is not something people should be using to create anything more than prototypes.
But genuine limitations? No, if you have enough time and money to throw at various problems, there are no limitations.
Would your time and money be spent more productively elsewhere though? Now, that is an interesting question.
8 Likes
The way I’d make a decision like this knowing what I know now is that I’d first get a clear plan for the game that I want to make.
Then I’d seek out people who’ve published not one but a lot of games in that genre, or at least similar. Ask them not to make any broad conclusions or suggestions, but instead identify what tools they think you’ll need and develop some time estimates. Also estimates for what sort of knowledge and skillset needed. If anybody makes a strong claim like, " you can do this in X engine" ask them how they know. In a lot of cases it’s just parroting “conventional wisdom” or speculations. So take that kind of thing for what its worth, which is basically nothing.
From all of that you can get at least a vague gauge on what sort of time commitment you’d need.
Unity will be compared to unreal or godot so do the same thing with those engines.
Finally do some actual testing just enough to make sure your time estimates seem valid.
Asking general opinions and conclusions I doubt you get anything very helpful. You’ll get people who either have major beef or fanboys, and even from hte most level headed and experienced what can they say? What tool to use depends on specifics and they don’t know your specifics, it will take hours and a lot of actual work to understand and consider them.
5 Likes
Actually no.
Its quite the opposite.
Unity is great for people wanting to do wierd niche things which requires special implementations (until you hit a “no source code available wall” of course)
.
The engine has an (overly) loose grip on workflows and implementations and you can implement things in many ways (although of which there are many mistakes to be made)
Other engines like Unreal do things 1-2 ways, but one very good and polished way. If you want something else you going to hit walls which are hard to overcome. You use the systems which exist and have to figure out how they work.
So the weakness of unity is doing standard AA / AAA type games. Open world, RPGs, FPS etc which rely on standard industry features, like Terrain, Large Scenes, Good Scene workflows, Animations, Pathfinding, Audio etc, where Unity only offers minimum viable solutions. Unity is good if you don’t need all these things and make a special game with very untypical requirements, like Starsector or Into the Breach and all such.
6 Likes
As I said elsewhere: Unity becomes better as you use less of it.
6 Likes
Unity is in a transition period without end. It’s limitations, during this period, are your team’s ability to hone its performance/optimisation, stability, reliability and certainty across a moving landscape of changes, potholes, chasms and nulls, whilst also trying to find and create tolerable workflows for any significantly sized creatively led project. Good luck with that, not sure it’s possible.
Just about nothing of the modern/new Unity is finished, and some staples (audio, animation, light mapping etc) haven’t even really begun to get worked on.
During this indeterminable amount of time, the much older, and minimal feature usage of Unity remains the best option for getting things done.
Unity 5, if you ask someone like @Kurt-Dekker , who I think is someone well worth listening to and deeply considering the advice of.
4 Likes
I gotta say, this is spot on. Excellent for weird and niche things, not so excellent for streamlined common things.
2 Likes
I hate that you are correct, but I really think to be fair, this is true of many game engine APIs, indeed large APIs in general.
Unity3D implements things ranging from the trivial to the insanely complex.
- Simple things are easy to use simply: OS startup, OS abstraction, GameObjects, Components, animation, simple lighting, basic input, basic sound, basic networking, scene loading, Asset Bundles, particles, etc.
These simple things tend to “just work” and if they don’t, they have simple workarounds.
- Complex things are hard to use: Terrain, the HDRP and post-processing stuff, Addressables, third party library integration (especially native stuff), editor scripting, etc.
Complex things are where people hang a lot of their expectations and get flustered when they don’t work.
Complex things are often poorly-defined, incompletely implemented, feature poor, or they have weird side effects because they tried to go outside the boundaries of what is a reasonable abstraction.
There is a similar analogy to be had with automation in general: The first 90-95% of automation is where you get the most benefit and help. Trying to fully-automate things all the way out to 100% is where you burn massive amounts of engineering time and tie yourself in conflicting knots of requirements and abstractions.
Same goes for Unity and any other game engine: it feels best to leverage Unity for the great things it gives you: a cross-platform simple-to-use context with unlimited growth potential. When you play with Unity at that level, as I do, the gamedev process really becomes a dream.
And as far as “oh it’s hard to finish a Unity game,” that’s just a red herring. It’s hard to finish ANY game. 
ALSO: the “trivial” items listed above are in no way trivial to implement. Unity has done a phenomenal job in getting the simple stuff to work well, and that simple stuff delivers value to me and my team every single day.
6 Likes
Must it be really be genuine limitations or can we also complain a bit?
5 Likes
Unity’s DOTS framework has largely eliminated this one. You only need to be creative with optimizations when you start running into the limitations of a framework and DOTS has a much higher ceiling you have to reach than you do with Unity’s Mono framework.
With the official release a few days ago I started crash coursing my way through it and I’m seeing massive speed improvements with just Entities. It’s far less verbose than I was expecting too so it’s not like my code has swelled compared to what it would have been with Mono.
3 Likes
So what is so hard to do in unreal but is easy to do in unity.
3 Likes
I fully endorse a well supported rant or two.
All of these takes have been solid. As someone who prefers to tinker and make as much from the ground up as possible, the features part doesn’t bother me. I’ve never goofed with dots but thatll probably change soon. I’ve never had issues with tilemap lol, but I can totally see how someone with bigger goals and ability would be frustrated at limited features. Thank you all for the great insight.
3d editor. Spreadsheet software. AR application. VR application. Battle simulator with massive number of units. City builders, games dealing with construction of user-created mechanisms, and so on. Anything with non-equlidean geometry, portals and camera stacking. Video game that is easy to mod.
Basically, I’ve never seen Anyland, TABS/UEBS made in Unreal. Vermillion, OpenBrush, TiltBrush, Gravity Sketch are unity. VR Chat is Unity, Besieged is Unity, Cities Skylines is unity, Subnautica is unity. Pillars of Eternity, Shadowrun: Dragonfall are unity.
Those are not accidents.
5 Likes
worth noting that the latest iteration of skylines is being made in ue5.
These are two things that Unreal excels at, largely because it works in ways that “camera stacking” (a Unity hack) isn’t necessary, because overlays and underlays just work.
That was just a rumour.
It’s being made in Unity:
5 Likes
ah thanks for correction. That makes more sense I was pretty surprised. I think I had read it on their steam forums because a guy who was making a city builder had asked about it.
I imagine for a sequel it hardly makes sense to change engines especially for something like that.
1 Like
The rumor was fueled by the fact that they put out a teaser using some assets from the Epic Marketplace and people recognized some gas station model or something. Maybe even the teaser trailer was made in UE, IDK.