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

News & General Discussion
1

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.

2

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.

3

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.

3 Likes
4

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

Related: https://discussions.unity.com/t/858454 .

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_1 , but I might be wrong.

4 Likes
5

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.

6

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.

5 Likes
7

Not supporting Epic and their shitty business practices is a good enough reason to not use UE, I’d think.

1 Like
8

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.

9

Didn’t know people were still on about that.

10

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.

4 Likes
11

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

1 Like
12

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.

5 Likes
13

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.

2 Likes
14

Well, they’re still doing shitty, 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 fuck 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…

15

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

16

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.

2 Likes
17

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

18

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

1 Like
19

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)

20

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?).

2 Likes