What are the genuine limitations of Unity?

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.

 

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 S***ty 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.

 

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.

 

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.

 

As I said elsewhere: Unity becomes better as you use less of it.

 

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.

 

I gotta say, this is spot on. Excellent for weird and niche things, not so excellent for streamlined common things.

 

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.

1. 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.

2. 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.

 

Must it be really be genuine limitations or can we also complain a bit?

 

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.

 

So what is so hard to do in unreal but is easy to do in unity.

 

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.

 

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:

 

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.

 

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.

 

I'm really curious what you mean by this. Do you mean that the Scene view in 3D is easier to navigate and build levels with than in Unreal? Because if you are, I couldn't disagree more. Unity's 3D workflow feels like some clunky ancient technology in contrast to UE5.

Unreal controls like butter. Things go exactly where I want them to go on first try, I can click on objects and immediately select the correct one and something about the scene movement just feels 'right'. In Unity I often can't even tell how far away an object is. I'll place it somewhere only to find I'm like 50 units away from the actual position. I'll make a collider and it looks correct from one perspective, but a different one reveals that I'm completely off. Sometimes the zoom bugs out and the mouse wheel becomes extremely slow. I could go on forever.

This is actually something I wish Unity would put some work into. I find it extremely frustrating and cumbersome to control 3D objects. It feels way easier in UE and also Godot. But, to be fair, I can't really tell exactly why that is.

 

"3d editor" in this case refers to a standalone program you create, and not some editor extension.

Meaning you write a game where within the game you can create and edit models.

"Scene view" has nothing to do with it.

Also see OpenBrush.

 

Use F key or double F key in some cases.

 

Use it on a laptop under battery power.

Unreal absolutely MELTS batteries.

Unity barely warms up the laptop.

 

Not true. If you've got a MacBook Pro from anything prior to the M1, Unity will nearly melt the bar above the keyboard, and make the fans into vacuum cleaners. It flogs the AMD GPU's so hard they beg for mercy. Particularly the 560X, but also everything either side of that generation, too.

 

Good luck running Unreal Engine on one of those.

 

Not bad if you run it in Windows via Bootcamp

To be fair, Unity also ran better in Bootcamp, not least because the throttling can be overridden in Windows.

The throttling when using Unity under MacOS prior to the M1's was abhorrent.

 

Ive got a good thread for you here, make sure to bump : P

Feedback - The Unity Editor Scene experience is still completely ridiculous in 2022 LTS and defies any logic - Unity Forum

 

You can make pretty much any game in any off the shelf engine (or even without one!) with the right skills and resources (time, people, money).

There is no specific game that cannot be made in unity or unreal and these days even Godot, if you can put in the necessary.

People argue all the time that you cant make X in unity or Y in unreal but there are people and teams breaking those conventions all the time.

The limitations of the engine are far less important than the limitations of your resources and skillset. Its not about what the engine can do, its about what can you do with it?

 

Unity: Silent when prototyping
Unreal: Fan goes crazy with simplest scenes
Using macOS, YMMV
Also, AFAIK, Unity performs much better for low end devices and mobile. At least last time I researched.

 

I spent last night working on a fast paced arcade game in 2022LTS on an m2 Max MacBook Pro. Less than 4 hours of full battery life, on a computer that's been averaging ~20 hours of more normal usage (Maya, Reaper, Logic, Affinity Designer, After Effects, Ableton, Safari, Opera) per charge, and is probably the strongest combination of power and battery on the planet.

And I wasn't spending a lot of time in Play Mode, probably about 1/3rd of that time. So what I said above, about Unity being bad on Intel Macs... it's worse on m2 Macs, relatively speaking, as an Intel MacBook Pro goes from about 7-8 hours of normal usage to less than 3 hours when working with Unity on the same project.

 

There is significant overlap between the two engines but they can both do something that the other cannot. Those extreme ends should be cause for serious caution and testing and I think it is important to identify.

It can be hard to do though if people stick to absolutisms and speculations. Like what you said here is certainly true, but there is some nuance which, if ignored, could end up resulting in some poor wanna-be developer wasting serious time and money, simply because they took advice from people more experienced and chose wrong tool for the job.

For instance, if you try to make a large open world in unity, you'll need a team with many experts and at least half a year of time before you reach the starting point you would with unreal. So we can say it is possible in unity, but for virtually anybody asking questions here, it practically is not. Nobody asking questions here is mega-millionaire, right?

And plenty of games that if somebody tries to make in unreal, they'll find that none of the tooling available there is appropriate, there is no support, and the editor itself is way overkill for the job. Or at the most extreme, they'll find the engine doesn't even support target hardware.

So choosing right engine can make or break project for indie developers who don't have enormous amount's of money.

Instead of dismissing the potential engine war threads it would be better to dismiss the people who regularly inflame them and turn it into something not useful. People ought to be able to get an accurate handle on what to use unity for, what to use unreal for, and not have discussion polluted with useless speculations like "well genshin was made in unity and tarkov so if you cant make an open world, git gudder", or "unreal made fortnite, so if you cant get your third person online shooter running on switch, you suck". Like we have to consider the audience rather than treating every post as a way to boost our own ego.

 

I am not dismissing anything, I am simply saying that what one person see's as an engine limitation others see as skill or resource limitations.

Many of us would say "unity cant do x" but then genshin impact team adjusted unity to do X. Thats because they have source access and a large team (i.e. better resources).

Same is true for unreal engine.

So yeah all I am saying is that anyone looking into the limitations should be more concerned about what they themselves can do with the engine, rather than anything else because thats often the deciding factor.

No idea where you get all the "to boost your own ego" stuff from but I suggest you stop trying to infer meaning from my posts outside of what they say. Nothing I was saying was "to boost my own ego" and I would prefer if you in general took a less antagonistic tone to what is a perfectly harmless and well meaning post that was clearly not meant to inflame. I am here to discuss best ways to help people get into our industry, nothing less nothing more. Anything else you see is your own interpretation of my post.

 

The ego and inflame isn't at you directly, it is in general. Though I do disagree about your post being dismissive, even if you don't mean for it to be. It is hard not to interpret it as, "the tools are equal, everything hinges on your own skills." But the tools are not equal - not even close (for a lot of project types, not all).

At same time I can see how the general premise of the thread is probably too vague to give any real answers other than just listing our own experience facing problems in either engine. Sadly almost nobody actually does that! It's all big extrapolations.

But nearly every time somebody says, "im having some issue with unity" or "can unreal solve such and such problem" the A team comes out and immediately devolves thread. Like somebody says "why is unity running slow here?" and five post later its, "yeah well unreal has S*** animation tools".

I understand what you are saying about difference between engine and team limitations... but it's kind of semantic. Whether we say it is unitys fault that it can't render at the same level as unreal or it is the teams fault for not being able to make unity into unreal is kinda pointless... the important thing is that they know what the cost is going to be to make either engine work for their project. If somebody here has done some testing that would be great to here about. Or at minimum, if somebody has faced the problem and knows what sort of work is necessary to overcome it, that's helpful to. Making speculations and getting upset because somebody thinks best thing might be to check out other tool just devolves thread.

this sort of thing doesn't exist anywhere else that i've seen. If somebody is saying all the great things about blender, maya users aren't getting bent out of shape like religious zealots afraid of losing followers. I don't feel compelled to talk about mayas superior animation tools if blender user talks about the great sculpting tools and realtime rendering. I'm glad that there is a good alternative out there i can try out sometime if maya stops making sense for me to use. And even though i'm not using unity for my projects now, i still have interest and hope that it stays viable and fills the niches that unreal lacks in. I love working in unreal but its definitely not good to have a monopoly on anything.

 

This thread was asking about limitations of unity, some people gave some. Unreal started to get mentioned too, so I simply chimed in to state my take on it. I think you are maybe conflating things that have happened in other threads with this one, because I really dont read anything in this thread as anyone dismissing anything from me or anyone else.

Ultimately its all text and we will all interpret the tone and meaning in different ways so I am not really that bothered, I just wanted to make sure to point out that I really am not saying "yeah well unreal is just as bad". I am also not saying "its all on you/developers" which your responses seem to suggest you took it as.

I am saying to anybody who comes here to read this who is going to actually take the things said and act on them, to measure your own abilities with the engine first before measuring the engine itself.

Just because unreal has world partioning and lumen and nanite etc for example, doesnt mean the average developer will be able to utilize them all to a performant degree and ship a product. Likewise another single developer might use them all and then some and get amazing results and ship a great game.

I am absolutely not saying that the engine doesnt have strengths and weaknesses. Ofcourse they do.

Im basically just saying weigh it all up together. And my comments are only really aimed at newcomers who may come and read this, I dont really care what regulars like us think because we are all just friends essentially that come here to chat (or thats how I see it )

We are both forum regulars and I am sure you know from my posting habbits that I try to (mostly - we are all human) not dismiss anything, in fact for the last year most of my comments have been to help steer newcomers in the right direction and I make a concious effort to try not to come across as negative or inflaming, hence why I took your post (which I realise is not targeting me specifically) badly and as a bit of an unnecessary insult (even if it wasnt meant that way it very much reads as it).



Just FYI I am also tired of certain members devolving threads into arguments about semantics and pushing people away from certain avenues as if their interpretaion is the only one, but that doesnt mean we shouldnt be truthful and speak our mind here. What I said is the truth as I have experienced it throughout my career both in the games industry professionally, and in the serious games industry - as always your mileage may vary

I guess what I am trying to say (but probably didnt word very well and my apologies for that) is lets not try and say X engine is better than Y or you can do X and not Y because its unlikely to be actually true, but simply our own experiences with X/Y engine. People defeat these experiences all the time - just because I suck at Unreal engine (and I really do) doesnt mean everyone else here does for example

 

Well Gigaya couldn't be made without using third party assets

 

@MadeFromPolygons

i am just using you as a vector to make broader points to help bridge a gap between "people who talk about unreal sometimes" and "unity zealots" because you are a reasonable person.

my hope is that whether a person is asking on unreal forums or here about what engine to use for their project, the best responses would be people delving into the specifics (if they care that much) of the proposed project and then giving actual experienced based suggestions.

Personally I wasted $6,000 and six months time trying to make a game that would be impossible to make in unity without a AA team at minimum, because virtually every person told me that it was perfectly doable, even though I am now almost certain no one has even attempted to do a similar thing.

 

Requiring third party assets is not an engine limitation.

 

how people define words isn't important... the important thing is that if somebody wants to make a game like gigaya, they'll be helped if they know what money they'll likely need to spend to do it. you can frame it as a benefit that the asset store exist if you like.

 

Hey no harm done, and as I said everyones mileage varies - I would be way more interested in hearing specifics about what you tried and what was not possible in this thread than anything else (I mean not for me specifically, I have followed you quite closely so I am pretty sure I already know what you are going to say) as that will be very useful to others.

If I read "unity cant handle large worlds" for example I just think of all the bonkers large worlds we have managed to make during my day job and assume its not true/correct. But when someone says "I tried to make X and it didnt work, I tried Y in unreal and I was able to make it work due to etc etc" then I find that super useful.

To be honest I dont really know what I am argueing for, I just dont like how negative the forums can get based on peoples own experiences as I remember being a new dev put off by that and it stopped me trying things out, and sometimes failing is necessary to learn (I used to be so negative in these forums I would have absolutely contributed to that). But at the same time to hear about you losing capital on things that didnt work out, is also going to be an eye opener to some and very valid discourse!

I hope anyone that comes here tries things out for themselves and takes all our points with a heavy pinch or pile of salt, and as long as they do I am sure they will make the right decisions for themselves, those that dont hopefully will learn from the failure.

I totally feel you about lost money by the way, I have also invested a lot of time and money into projects using engines that just havent been possible or the workflow has made it so painful that it got untennable to continue.

 

Depends on the level of specialization you need, but generally I would say it is.

 

I wrote a blog post about it but it looks like at some point I decided to hide the devblog from webpage. I'll copy paste transcript here (formatting gets a little screwy so some stuff may seem out of sequence):

TLDR: i attempted a navigation simulation game in unity that requires large open terrain with high amount of foliage. gameplay and everything else is dead simple though. Unity editor slowed so much that it was not workable.
As a non-programmer, I was able to rebuild the game in a month using unreal and performance was a non-issue.

Spoiler: Article

One game - Two Engines
Unity versus Unreal



Before September 2017, I couldn’t tell you the difference between Windows and Mac.

I had recently moved to the city and needed to find some job to do. I heard about some friend of my wife’s was trying to make a video game. I grew up playing video games, so I thought that sounded pretty cool. Make my own version of Halo or Ghost Recon.

I did some googling and learned that game development consists of digital art and programming.

I took interest in 3d art because in school I always liked to doodle. I won’t say I was a good artist, but I was always making art.

I took a look at programming too but it’s full of big words and math and I hate math.

I determined that my goal was to make games, but it seemed that the sensible approach was a long one - first become a 3d artist, get a job in a studio, make connections, and over the course of 10 to 15 years then I might be able to be in a position to start my own studio.

I spent about 3 years learning most disciplines in the 3d field. Then one day, I met a guy on the Unity forums who wanted some help making a game.

We had a talk about our goals. We both agreed that we would make a game in one month and publish to Steam. No matter what the game looked like, we would publish in one month.

This was all about simply getting the experience of publishing a game.

We didn’t market the game whatsoever, but nonetheless it did alright in the post-indie apocalypse world. It sold a couple thousand copies on Steam and got mostly positive reviews.

The biggest joy for me was that I got to watch strangers playing it on Youtube (see left).

In that game I made all of the art and designed the missions. Pretty much I did everything except write code. It was a lot of work, but I really enjoyed all of it. That experience made me realize making my own games didn’t need to wait 10-15 years. I could do it right now.




As I understood at the time, Unity is the engine of choice for indie developers. Unreal is another option, but it is difficult to learn and not as user friendly - especially to beginners.

That’s what the internet seemed to suggest.

I had already made one game in Unity, so it seemed logical to make my next game with the same tool. I was curious about Unreal because it does boast much more impressive rendering, but all of the most sensible people I could query made a strong case for Unity. So I started developing LANDNAV in Unity.

The first big task was to decide which render pipeline to use. I did a lot of research, and many weeks of exhaustive testing. For me the question was not, “what looks the best,” but rather, “which workflow is broadly compatible with other tools I’ll need to use?”

I am not the most technical person, but if an answer exists, I can discover it. To this day, I still couldn’t tell you which render pipeline in Unity best suits LANDNAV. Each one offered few solutions and many compromises.

Next, before I could prototype the game, I needed to be able to support a large terrain. In this case, conducting landnav exercises in a small space wouldn’t answer very much about the viability of the game, so there wasn’t a smaller, simpler way for me to get started.

The terrain was going to be big, and then we are also operating relatively small tools. This necessitated origin shifting operations and level streaming. To accomplish this, I had to hire an experienced programmer.

It took not insignificant time and effort to get the game to a playable state. Development felt like slogging through a marsh in an iron suit of armor. Exhausting, rigid…not conducive to creativity and adaptability.

The problem was most of this time and money was not spent making forward progress. Nearly all of it was spent developing tools to build the game, then developing work arounds because with a hodgepodge of tools - many third party - getting systems to work together becomes like herding cats…and later, once the game was built to scale, we ended up having to redesign the game in an attempt to conform to rendering shortcomings.

I did not feel proud of the product I was producing. I felt like I was losing a fight.

In the end we ran into game breaking bugs that caused memory leaks, crash to desktops, and overall bad performance. But never minding those development stopping issues, daily work had become onerous. Opening the project took up to 30 minutes. Entering play mode would take 20 seconds or longer…


My After Action Review Sequence logic in Unreal Blueprint.

Some people don’t like visual scripting. They complain that you end up with spaghetti code.

Not if you are organized. And even if you are a bit messy, you still can click a noodle and it highlights to show where it is going.

This is what makes visual scripting so powerful. You don’t have to waste any mental energy holding a complex architecture in your head. You can see it in a physical, easy to understand way.

It’s like the difference between memorizing books and having a library.

This empowers you to rapidly create game logic so that you can get in the creative zone faster and stay there longer.



My experience doing landnav training in the Army was a pivotal moment in the development of my character.

Being out in the woods alone, trying to do something that seems impossible…pushing my mind and body to the limit, and then going for another 100 kilometers…it makes one into a person that is hard to defeat.

So, this experience I was facing with the development of LANDNAV was nothing new to me. A challenge to be sure, but I know how to get around a challenge.

I didn’t know exactly what to do because I haven’t been a computer guy for very long, but I got a few techniques for handling a situation like that.

One thing I’ve learned that can get you out of a bad place: if S*** is broke and you don’t know what to do, try the opposite of whatever you’ve been doing.

So, Unity was giving me a hard time. Everyone seemed to suggest that Unity was the right tool for the job, thus insinuating that if I couldn’t make it work with Unity - well that just meant that I must suck at game dev.

Maybe, but it would be better to actually know.

I downloaded Unreal 4.26. The first thing I learned was that I might not need to hire programmer help this time. Unreal has an in-built visual scripting system that makes programming like stacking Lego’s.

I can stack Legos.

Initially, I figured I might need several months or maybe a whole year to get fluent enough to even consider rebuilding LANDNAV in this new engine. After one week of doing beginner tutorials from Youtube and Udemy, I felt ready.

After one month, I had all the basic mechanics implemented. I had done the work myself this time, so I had complete control. I was able to experiment a lot and thus improve many systems.

I did hire occasional consulting help - basically if I hit a snag with some math problem, I just have somebody show me what to do.

Within another two weeks, I had the game rebuilt as completely as it had been in Unity. Most importantly, I was now able to stress test the new engine. I went overkill on the world size and density of the foliage. I left the art unoptimized. I built the project and played it for hours. Zero issues. Performance was good - no bugs, no crashes.

I accomplished this in just over a month. You can surmise then what the workflow was like, and how the in-built tools kept me productive without having to spend weeks verifying compliance among third party systems (read: herd cats.)

It’s a simple story. If you require a summary, this is it: for a project like LANDNAV, Unity gave me many problems. Unreal gave me productivity.

Could a more experienced developer make a game like LANDNAV in Unity? Sure. But in the time it takes an experienced developer to write the tools needed to make the game in Unity, I can write the entire actual game in Unreal. As a beginner. Consider that. I think it’s important.

In your own decision making process, there is big questions that must be answered first. Is target hardware supported? That’s the big one. If that is a go with either engine, then I think you need to test real-world workflow, and then stress test a vertical slice of your game.

Don’t let anybody sway your opinion without doing your own test. Nobody really knows anything. Every game project is so unique, nobody can speculate which approach is best for your project. Only reality can guide you, so you have to put in the leg work and test. You must validate your entire workflow and stress test on your target hardware.



Whatever your belief is - challenge it.

Workflow is king. If your mind is wasting energy on battles that don’t contribute to developing a player experience, you are fighting the wrong battles.

If you don’t already know, understand that prototyping a game is easy, but polishing an experience to a marketable degree of quality is 1000 times more work.

Here’s an analogy - try roofing with a cheap plastic handled hammer, rather than a wood one. In just a few hours, you’ll understand that details about the tools you use make a serious difference.

Digital work is not different just because you’re sitting on your ass. Your brain works not unlike skeletal muscles. It does work, then it suffers from fatigue and must rest. You must manage your energy and choosing the right tool for the job is an important part of that process.

I don’t think the general consensus that Unity is the engine of choice for beginners or tiny indie developers was necessarily wrong - I think it’s just outdated. Game development was very different 5-10 years ago, but based on the work I’ve done on this project, I think a strong case can be made to say, “Unreal is the more appropriate engine for beginners and tiny studios.”

In conclusion, if the shoe fits, wear it. Or not. I don’t care what you do, but I hope that whatever your belief is - challenge it. The question of which tool to use is not insignificant.

 

Absolutely, thats basically the definition of a engine limitation
We'll its not a theoretical hard engine limitation, its hard limitations of the engine feature implementations.

 

A very real limitation that's hard to explain until it's happened to you: - an inability to stay with a version that just works. You'll need to stay up-to-date on Engine Versions in order to keep submitting updates to the increasing requirements of various target platforms, unless you have source access and the ability to meet those requirements.

 

This one I have always found interesting, because with unreal you can theoretically build using Unreal 3 and still publish to the major stores.

Somehow with unity thats not possible, and I wonder what architectural decisions have led to this being the norm and if its even possible to ever rectify.

Why cant I build something using unity 4 and submit it to a console or app store?

 

I just wanted to point out that this line of criticism is quite common in these forums for some reason. Basically compare what Unreal is absolutely the best at and designed for then come to the conclusion that Unity is not up to snuff. Not a fan of Riccitiello, but he makes this point quite well towards the end of this interview.

We could instead agree that "a good game engine will work on multiple platforms, perform well on mobile and should be general enough to for any style of game or non-gaming application". Using that as our baseline, Unreal is complete crap.

I think this bias comes from a kind of built-in shock when a computer achieves photo-realism in real-time. It's kind of similar to the shock and awe of what AI is doing right now with words and images. It's just plain impressive to see that and it sort of rubs off, if it can do this really impressive great thing, it must be the greatest at everything!

@MadeFromPolygons is quite right regarding genuine limitations of engines. With enough people and will-power Unity could make a photo-realistic FPS look as good as Unreal. Would it be fun to do? Absolutely not, anyone would use Unreal for that as Riccitiello concedes. Likewise there are tons of non-game, 2D, XR, applications that could be done with Unreal with enough work, but what's the point?

 

I don't know why people think Unity is good for mobile though. Unless when they say mobile they mean 2d ad ridden skinner boxes, in which case, yes, but as I recently had to disable Vulkan, and disable Multithreaded rendering, and gpu skinning, and find alternative for sprites, and avoid any Unity UI completely and much more, to have a decently performing non stuttering Android build for a 3D game, I don't know why people think Unity is not complete crap for mobile.

I think the people that say that are mostly people that don't make mobile games.

 

Right, exactly. I thought we were talking about hard-stop, project breaking, dead ends. Types of projects that are impossible with Unity. That's what I thought we meant by "limits."

 

Agree, Unity's performance on Android is bad. In my tests, Unreal is better even on mobile but Unity seems to be more polished where it comes to sdk setup for building.

 

Old Unity (BiRP and Legacy Animation, old Input System, the Audio System such as it is and unlit shaders) run really well on iOS, not by design, but because Apple focused on single core performance and ensuring the OS gets out of the way a reasonable amount, too, and because old Unity was designed around single core prowess of old Mac/PC world.

iOS based chips came to where Unity was at, so to speak. Just a matter of luck, not intent on either side.

Android phones don't tend to have any of these benefits, and have a truly horrifically inefficient OS in the way, too.

Jobs and Burst would be well suited to Android, if Unity cared about Android, as almost all modern Android phones have at least 1 to 3 extra "big" cores doing nothing. But Unity barely manages to offload anything to extra cores, still, despite Jobs and Burst being the ideal mechanisms to do just that for all manner of systems.