Best arguments for sticking with Unity on next project other than c#?

So I've been getting pressure from people I work with to switch to Unreal for future projects.

I really don't want to switch over because I'm very strong with C# and it'll take me much longer to do everything in Unreal. The big arguments I get revolve around better performance, easier modelling (nanite) and better lighting.

The projects are generally third person with team of 2 scaling up to around 4, ambitious for team size but relatively small scale all things considered. Target platforms are PC and console.

I've worked with Unreal a bit, and I don't hate it - but I really don't want to spend the time needed to get really competent (it'll take months).

Outside of my own personal hangups, are there any good arguments for sticking with UT for non-mobile, or should I suck it up?

PS: I realize this could just devolve into a generic unity vs unreal thread - and I'm not looking for that. I'm looking for sincere, practical arguments in favor of using Unity.

 

if it is run of the mill programming wise I doubt you have very much down time to get basic things in place. most of it is already there, you may just have a lot of questions like "where should I put this code?" but if it is not multiplayer most of these questions really boil down to preference for how you like to organize things - not like if you choose wrong the project breaks.



Artist and everybody else is probably going to vote for unreal.

probably the best thing to do is just blast through a couple basic "make a game" tutorials to get a quick sense where things are in the editor. There are some "unity to unreal" guides as well.

i've worked with a couple programmers who came from unity and at first they weren't happy about blueprints but within a few weeks they liked it a lot (it's super fast in general to work with, though of course you'll find some pain points like working with arrays or maps is more tedious compared to code), and just chipped at c++ a little here and there. But unless you are building a AAA game, blueprints will get you like 99% of the way there and its much easier to convert that to c++ than build c++ from scratch (especially if you are learning the engine).

there do exist some scripting languages like angelscript but with 5.0 i dont think its worth bothering with because live compile works great, and you actually have more documentation and examples of c++ than you do for the scripting languages.

basically for the programmer i'd suggest don't get too hung up wrestling with c++ because most things you want to do will be done very easily with blueprint, so you can get the game verified fast that way, and then for performance go in and refactor selectively to c++. Also always test doing things the dirty fast way first and don't assume that something which gave you performance headache in one engine will be the same case in unreal. That way you don't spend weeks building something like actor pooling system when just direct spawn/despawn would not present any issue even if done in the thousands.

on a team if there is more than one programmer you will have a hard time versioning blueprints. it will take some experimentation to develop a pipeline for that because blueprints don't play well with version control. I think it may be different story with perforce IIRC, but I've only been using github.

If there is only one programmer and maybe some more gameplay designer types, what you can do is setup the bones of your classes in c++, you put all the public parameters and functions there, and then blueprint class can be derived where they script the actual logic. But there is plenty written about workflows for that - MothDoctor had some handy guides in the unreal forum learn area for that.


if everybody on team is learning unreal it will probably be three times slower compared to if you have a native available on call to answer questions.

 

I recall having a very similar conversation whilst working at a company a few years ago.

We were embarking on a fresh project and the topic of Unity versus Unreal sparked. Ultimately, we opted for Unity due to the tight schedule of the project. We felt that leveraging the extensive Unity know-how within the studio would greatly reduce the project risk.

However, once that particular project had concluded, the studio made the switch to Unreal Engine.

 

Ridiculously fast prototyping. Basically, no contest. Especially if you're code oriented and dislike blueprints.

Related: https://forum.unity.com/threads/trying-ar-in-unreal-sharing-experience.1181896/ .

Basically, I've heard some people use both engines - they prototype in Unity then switch to Unreal in final product. I think it was @MadeFromPolygons , but I might be wrong.

 

Do you have an opportunity to bring an Unreal Engine expert on-board as part of your team? I've been in a lot of Game Jam situations where me, or someone else on my team, had to jump-in and learn a whole new system. There's always someone who already knows what they're doing, though, and can steer the ship. It's a great opportunity to learn quickly without all of the risks that come with the trial-and-error approach that you'd need to take if you didn't have the guidance.

 

Ideally, I would suggest coming up a small vertical slice that hits as many of the key things you think will be critical and trying it out in both engines. Get a real feel for what works and what doesn't. Might be hard to justify the cost of doing that, but might be worth it.

 

Not supporting Epic and their S***ty business practices is a good enough reason to not use UE, I'd think.

 

Why would you say that unreal is so much more difficult to deliver really rapid results in?

I've done work with some of their unreal guys on unreal projects, they're generally not particularly seasoned programmers. I think they were like 2-3 years experience. So It's not really something that would help me personally.

I was actually brought onto their unreal project to do some of the more technical work in the project since I have a much stronger programming background and at the end of the day, it's all the same crap.

 

Didn't know people were still on about that.

 

Because I cannot prototype in it with the same speed. It gets in the way. The slowdown is in ballpark of factor of five or ven ten.

Basically remember Terry Pratchett's death? "THIS WILL BE AN IMPORTANT LESSON". For me the first important lesson was when I managed to make a 3rd person melee game prototype from scratch in 4 hours (for the record, something like this from scratch can take half a year if you insist on writing every system), and the 2nd time was participation in ludum dare. In Ludum Dare I spent most of the time making assets, ran out of time making music, but basically the speed is nuts.

Basically, component based design unity uses is incredibly efficient. You can pull apart any example in minutes, and in a few more minutes you can make your own thing. When "alex" was part of built in package, you basically could learn half the t hings you want by reading its cs controller file. As a result, for example, it is easy to grab a VR example, and develop your own VR controller.

In Unreal... oh, boy. Basically, Unreal wants you to use Blueprints (which I hate with passion), and blueprint API does not match C++ API. Bluprint functions simply do not exist in C++ side. If you grab a VR example, you'll have a nice looking controller somebody probably spent 3 months developing, it is beautiful, but it absolutely does not suit your needs and you can't see a good way to alter it, because everything is blueprint and the damn thing seems to be tied into the half the engine, and there's no obvious point where it is being initialized. Last time I tried working with this untangling blueprints and trying to recreate controller through C++ took me about a day, after which I started questioning my life decisions.

So, if you're code oriented, unreal will be slow for prototyping. Also, inheritance based design is not helpful.

Speaking of VR, many VR games feature barely modified stock controller.

 

This is my thought, too, and for that reason I'd suggest doing what ZG suggested and having a go at both with the core project-specific stuff before deciding.

Really, there is no generally applicable "X is better than Y". It always depends on circumstances and there are often exceptions, and anyone experienced should know that. So unless you can share some project specifics for people to weigh in on, the only generic advice of any value is "try it and analyse the results".

 

I don't really buy into the "Unreal is slower for prototyping" thing. Mainly because when I did prototype something in it I was slower, but it all came down to me learning the tools as I went. Yes, it does some things differently, and yes, it took me time to look up that stuff and learn it as I went. But guess what? Back in the dark ages I went through exactly the same process with Unity.

Unreal does allow component architecture similar to Unity's. The fact that many things choose not to use it, and/or make code which is spaghetti, isn't a negative against the engine itself.

The other thing is that I wouldn't pick an engine for a large project based on prototyping speed. Being able to make something function is a pretty early step. For a full game you also need to make it scale, probably develop custom tools, QA the whole thing, etc., all of which should be considered in your engine / tools selection. I wouldn't give those things up for faster prototyping up front. And, of course, what I said in my previous post applies to this stuff, too.

 

There are two things here:

* The engine where it takes less effort to relearn something is preferrable. Component System clicks immediately, then it is with you forever. Whatever it is Unreal up to doesn't click to me.

* "Big project".... basically, most people are not going to work on big project. It is like an AAA argument. Someone making an AAA should have an AAA budget, or they're not making an AAA. Roughly same deal.

As I said, you can use both. Prototype and iterate over initial design, then slowly polish it once you settled on it.

 

Well, they're still doing S***ty, industry-harmful things and being giant crybabies when people (rightly) don't want to deal with them, so...ye; there are literally dozens of us.

Imagine suing someone so they can't tell you to F*** off after you intentionally (and underhandedly) broke the TOS of their service (and then sued them for it) because you didn't want to pay to use their platform.

Imagine crying about how a platform isn't playing fair/friendly (by being a better service that everyone wants to use) while intentionally not improving your own platform and instead throwing Tencent money around to get 'exclusive' game releases for your platform, which is functionally a black hole of marketing/visibility (for games. It's a great platform for visibility into the user's data though.). Double whammy of re-introducing the garbage idea of platform exclusivity on PC while also being a worse service. But yeah, Sweeny, the problem is definitely Steamworks...

 

Sure, I'll grant that there are cases where those things apply. There are also cases where they don't, per my earlier post.

 

Although I agree with most of the points you have raised, Epic is painted as a gaming industry savior or something but they are not that by epic proportions (all puns are intentional and I'm never sorry).
But I would like to remind you that Unity has similarly shady deals (deeply involved with exploitative microtransactions too, just like Epic) and also military contracts.
So good luck choosing between these two
I mainly hate Godot because it is upsold without really earned it and its boss is a smug snob SOB who doesn't know how to lead the development. Nothing personal, just the amount of WTF faces I made when I read his commentaries about gaming, engines and offerings. The product is a cool toy, but I wouldn't build a business upon it. This may change in the future, obviously, but not any time soon.

 

No arguments there, Unity isn't flawless and I think at this point to function in the real world you have to accept at least some small level of S***ty practices from large companies. Though, one major benefit is that I can choose to stop supporting Unity, financially, whenever I want. If you release a game with Unreal, you will have to track and report that game's income to Epic...basically forever? And if it crosses the million dollar threshold, you'll have to pay them forever.

 

Guys lets stay generally on target and not get into the politics of both engines please.

 

it might also be helpful to find people who've made something similar to what you have planned in unity and see if they'll discuss any of the big problems they faced.

see if unreal has anything to address the same problems (if they seem like problems you'd encounter as well)

 

The only argument for Unity is that you already know how to use it. But it seems you already know that, so I'm not sure what the point of this thread is?

If I may put my devil's advocate hat, it seems a bit that you have decided you don't want to bother learning something new and you are looking for excuses to rationalise your decision.

Look, DOTS seems pretty cool, are you willing to learn that? Are you willing to throw away a chunk of your know-how with Unity for things to get better? (if you are, then, what stops you from moving to a new engine?).

 

I kinda expected there to be better pro unity arguments. There are real arguments for using Unreal (performance, lighting), is there really no reason to use unity over unreal other than you already know it (on desktop/console)?

 

Maybe Unity has the performance edge at some use cases when using DOTS, but it's a new tech and I don't trust Unity's new tech / features so early (days?) after they release them.

Other than that..

Uhhh...

Ehhh...

Fast prototyping or something.

 

Unity has solid third party support. Odin Inspector, Serializer, and Validator always come to mind immediately, but there are others like Magica Cloth. Unity's UI system is much more flexible and easy to work with. While I'm not a fan of saying it out loud less they get even more complacent Unity has the better documentation too.

 

I think other arguments were already listed, though, but for some reason you chose to ignore them? For example, clean API is a valuable thing.

"Performance" claim is dubious. Unreal editor is more resource-hungry, resulting unreal game will usually have larger install size and will be running slower.

Also, games featuring massive number of agents in combat, like UEBS and TABS were made in unity and not unreal.

 

It's not worth having argument like this.

You are doing something, you need to know what you are doing to be able to decide what tool is the best for your situation, people, expertise, project. In general Unreal is great for TPS if you just make another boring grinder without any interesting stuff. As soon as you want to make anything unique and interesting, congratulation, you will think Unity's compile time and domain reload are suddenly great and perfectly reasonable. But seemingly your team made up their minds without any real analysis, because Unreal is the goat or something.

 

They are doing their best to ruin that though (unless I am the only one that really doesn't like their docs for the packages).

 

Same here. It's very much a downgrade from their previous documentation.

 

You made the ridiculously fast prototyping argument, but @angrypenguin disagreed. I'm not sure which of you is right so I kinda skipped the point.

I mean from everything I've seen, read and heard, it's easier to build dense environments faster that still run smoothly. Like if you have a fairly big scene with tons of foliage and stuff in it, that's something where generally Unreal will have a pretty significant edge.

This could be true. Especially with DOTS. I know TABS, whats UEBS?

Admittedly, I'm just looking for "casual chat around the watercooler" type arguments in favor of unity to fend off annoying comments from coworkers telling me to switch. Maybe I could lean into the ridiculously fast prototyping thing even if it might be dubious.

 

Related:
https://forum.unity.com/threads/what-are-the-genuine-limitations-of-unity.1444351/#post-9058696

Ultimate Epic Battle Simulator. Another swarm fighter.

Well, if they already made their mind, you can't change it anymore, no matter what arguments you provide.

Basically in my case, as far as I can tell I'm extremely compatible to unity approach in monobehavior API. Hence the fast prototyping speed.

Meanwhile, in case of indie Unreal games on steam it an UNreal title usually looks like this:

* Pretty.
* I saw that grass and those trees and those rocks in some other game.
* THe lighting style usually fairly similar to other unreal titles.
* Limited customization, usally restricted to attachment swaps. Changing limb length is almost never a thing.
* Usually uses stock FPS, TPS, and VR controller, unmodified or with base mesh sawpped. VR controller does not take seated play into account, and you can't crouch or add height offset to it. (this could've changed, though)

Spoiler

For the record, seated play support in VR is something I believe every VR dev must ensure is present in functional state. And that crouch, stand up and height asset is supported.

One huge issue here is that if the player has some health problem that prevents him/her from walking normally and uses VR to unwind, then by giving the player a controller without height offset you're giving them wheelchair experience. Which... can be soul-crushing.

* Animation is detailed.
* Gameplay is quite simple.
* UI is usually primitive, it can have pretty graphics, but it is on the level of bitmap sprites where numbers are printed at precomputed positions.
* Almost no 2d unreal games.

Unreal would be amazing for making movies, animation-centered games, visual novels with 3d dolls and so on. For making apps with high level detail but no gameplay, like a car configurator.

If you want to experiment, chances are you'll need to fight the API, until you develop a clean slate you're comfortable with. At least that's in my case.

Please note that right now I'm not looking for any sort of argument, as I'm feeling pretty S***. Just take the info as an opinion.

 

If you don't want to switch, there must be a reason. Surely if you argue your own position it will be more compelling than what other Unity users say.

 

I'll be the stiff-shirted fuddy-duddy who suggests changing the topic or avoiding that kind of office banter. I know that both banter and rhetorical debates can be fun, I engage plenty in both for that reason alone. However...

I get the impression that this particular topic is directly related to a thing you do professionally at your place of work. Personally, I wouldn't deliberately do anything which ties up people's feelings into what could be important decision making at some point, because there's a significant chance that it'll either influence the decision making or leave someone teed off.

Also, there's some potential for the type, quality and detail of your arguments to impact peoples' professional opinion of you. So I wouldn't get involved in it on a just-for-fun basis.

Of course, if the conversations are at work but aren't about work (maybe a bunch of you are discussing a common hobby?) then ignore all of that and enjoy the banter.

 

Easiest, most effective argument is gonna be: "Nah, I'm good."

 

I'd go "GET OF MY LAWN, ya silly kids, with your prints that are blue. LUMEN IS A UNIT OF MEASUREMENT YA HIPPIES, NOT A FEATURE! You'll pry C# and fast prototyping out of my cold dead hands, YA HEAR! In my days we used collaborate AND WE LIKED IT! You kids have become soft with versioning systems that actually work, BAH!"

 

I'm too old to learn a new engine... I'll give you my Unity when you pry it from my cold, dead hands!

 

I do, I use Unreal for anything that needs extremely high graphics performance or incredibly realistic PBR style shading, and unity for everything else.

I prototype in unity first (as I am a unity user for more than a decade so its just easier for me) and then move to Unreal and I find converting code quite easy that way.

I will say however that even after a long time trying to learn Unreal, I am nowhere near as fast in it as unity. This is nothing to do with the engine, its just really hard to get to the same level of comfort in the engine as I am with the engine I learnt gamedev with.

I work mainly in the XR industry so I also dont notice the pains of not having access to Unreal as much, because (At least for standalone XR) its just not as good as unity for that use case.

My advice is that questions like this wont answer anything - try the engine out yourself for a few months and then you will be able to compare their workflows for yourself.

 

Is Switch a target? None of the new Unreal tech runs on Switch. This is one of the reasons why I'm still here - Unity supports all platforms under the sun with sufficient performance.

On the performance note, you'll reach far more people with URP than Nanite/Lumen. Lumen lists GTX1070 or faster as requirement under Platform Support section. I asked ChatGPT4 to show total percentage of cards roughly equal or faster than 1070 from Steam hardware survey data. The number it gave me is 35.84%. So Lumen limits your reach, which is not a concern for big budget AAA, but might be relevant to a small team that might not want to directly compete with AAA industry.

Same applies to Nanite. From Fortnite news blog:

Spoiler

About 15.66% people on Steam have cards roughly equal to 2080 or faster.

 

Unity has their fair share of technology that doesn't run well or at all under Switch. I don't blame engines for that limitation though. I blame a device built off of mobile technology released eight years ago.

 

Wasn't a diss on Unreal, just a statement of fact. OP didn't specify which consoles are being targeted and listed new tech as reasons for switching. Although, perhaps the non-mobile comment eliminates Switch.

 

I would point out if you are starting a project and targeting the switch right now, you maybe need to rethink your strategy. Switch is very much near end of life, by the time you actually release you will likely have new hardware to target.

 

This is really helpful actually! That's all super relevant!

Switch has been a target platform in the past, I'm not sure if that market is still as active now though since the switch is definitely aging.

 

Chances are next Nintendo console will still run on a mobile chip and this is what Epic say about mobile in Lumen context:

Spoiler

https://i.imgur.com/RcuFsWe.png

EDIT: Although, perhaps Steam Deck and its brethren might've changed things with chips closer to laptop variants. The battery life is still poor on these though. So Nintendo could still opt for a mobile chip just for that since most gaming in Japan happens on the go. And even if they develop some kind of Steam Deck'ish APU, it's unlikely to run Lumen and Nanite well.

 

Unironically, I might use some of this...hahahah

 

Thanks, this makes it clear they don't even bother to optimize it even for the most popular desktop video cards. The reason to use Unity is that they actually do decently optimized features, unlike that company that develops everything to look good in marketing and that's it. There must be a reason why I haven't played a single UE game with stable 60 fps.

 

Speaking of which here's the Steam Deck running the Matrix Awakens demo.

What hardware have you been running that has a popular desktop card but can't hit 60 FPS?

 

With generally choppy performance and drops to single digit frames per second.

 

I should probably point out that what we can do framerate wise right now (as in this moment in time) with X hardware is sort of irrelevant when AI exists. Even just DLSS can make a crazy difference. The industry has been focused on hardware based increases in performance for a long time but with AI being all the rage and more use cases beyond generative AI coming more and more commonplace, I predict we will see increases in performance driven by the software side of things more and more as time goes on.

So Lumen not on mobile right now, but who knows in the future right? Also mobiles right now are like some laptops from a couple of years ago, the tech moves quickly.

All I am saying is the engine doesnt matter, what should matter is:

- are you comfortable using that engine - if not you wont finish the project
- can you find the info needed to navigate it / do you know how to reliably find info not in the docs for said engine
- does its pricing affect you (unity upfront price for example)
- do you target mobile or low end platforms with a release window of sometime in the next 2 years? if yes - unity or godot, otherwise pick what you want


If you are getting sick of unity and want to try something else to get away from it, then really it doesnt matter about which engine is good of what. I got sick of unity and that led me to unreal, and for a while that was great. I now work almost solely in XR and so I have again had to shift back.

 

It's a technical showcase running on integrated graphics.

Speaking of which Digital Foundry discovered the latest Zelda game is not only using FSR but dynamically adjusting the degree of it depending on the scene and how you move around the world.

Spoiler: Digital Foundry Tech Review

One major downside to Unity right now is that we don't have much in the way of upscalers. URP is limited to spatial upscaling (FSR 1) which is much less effective and much lower quality compared to temporal upscaling (FSR 2 and DLSS 2). HDRP is limited to just DLSS 2 (and I think there's a crappy in-house one).

Unreal Engine 5 has multiple upscaling options available to it including a solid in-house one, and they will be getting access soon to DLSS 3 which generates complete frames in-between rendered frames almost doubling frame rate albeit with some artifacts and higher latency.

https://videocardz.com/newz/nvidia-to-release-dlss-3-unreal-engine-5-2-plugin-soon

Spoiler: Digital Foundry DLSS 3 Analysis

 

Have you seen Unity sales model? The entire business model is setup in a way where they are rewarded for you taking as long as possible and struggle as hard as possible to make a project.

Unreal makes money when you make money. Unity makes money when you take long and struggle. Very expensive support, 100k I think to ask for fixes on the source code etc. Fill up lacking features with asset store purchases. I think freelancers have to pay 5k a year if they work for a larger company. You pay for seats even for build servers. Seats are more expensive than the build machines themselves.
Everything is setup in a way where they don't have incentive for you to succeed.

Epic game store only takes 12%, Unreal 5% only if you are successful.
Epic literally dosn't make money if you don't succeed.

 

Because they can afford to and because they have to attract content producers from bigger stores and bigger engines since they joined late in the game. The rates are not smaller than industry standard because of their good hearts or something, it's a user acquisition strategy.

Epic were a 1st party game developer long before Unreal became publicly available with several huge IPs and a long history of AAA licensing. And they have Tencent and Fortnite F*** you money, so income from the engine is not as important.

Unity Technologies do not have any alternate revenue streams from game development and the engine is not licensed by AAA with one or two exceptions so it's kinda an apples to oranges comparison really. All game engine companies are not created equal even if the products do similar things.

On top of that, asset store brings in very little money for Unity, it's barely on the map. Their intent is not for you to struggle for a long time, their intent is to lock you into the Unity ecosystem to keep monetizing you with services including some of the expensive ones you've already mentioned. Ol' boy Rich in the recent earnings call said they don't expect large growth in licensing revenue going forward, so they're focusing on services, particularly AI services they've been cooking behind the scenes for some years now that'll be monetized by usage rather than subscription.

 

I mean does it matter why they are doing it?

I assume the motivations behind the decisions Unity and Unreal makes are similar, but the end result is one gives developers and pretty decent deal for the engine and the other tries to push its terrible extraneous services on people (and then rug pull them and price hike, see cloudbuild / devops as a recent example).