I’m guessing garbage collection.
Unreal has Blueprints, which is 10X slower than C++, and therefore slower than C#. Garbage collection is generally avoidable, so overall I doubt using C# for game logic would really be an issue for anyone. If you’re using it to replace a major, performance-critical part of the engine, such as the terrain system, it might be more of an issue, although these days you’d be using shaders to do a lot of the heavy lifting for that sort of thing anyway.
–Eric
(I was just guessing what he probably meant. I as well think that C# for game logic is fine, even great)
I want to echo this as well. AAA developers rely heavily on custom tools, middleware, and workflows that rely on having this control. When these devs run into a Unity bug that they can’t dig into the source to fix you can see the veins pop out of their forehead. This is why a lot of the bigger ones still have their own engine. However, with Unreal being the only commercial engine with this level of control the answer is easy for them.
I’m a Unity guy and I have worked at larger and smaller studios that have used it. However, when you use it you need to accept a loss of control. You may be unable to ship due to a Unity bug without upgrading and breaking everything. Or you may be unable to reduce start-up times to match a native application. Unity as a final product is a black box that can be impossible to fix to reach native performance/control.
The sooner a unity dev accepts that, the happier the dev will be. However, larger devs aren’t willing to make that sacrifice, and I don’t really blame them. Unity is a shortcut and there is a price to pay for that shortcut. For smaller/medium teams that would never be able to spend the time to manage the controlling factors that a AAA dev expects it can be a valuable way to get a cross-platform product released. Which is why I am still a fan.
Plus as others have mentioned, Unity hires some amazing talent (especially recently). I have hope they can continue to evolve the product. With the new ECS and data driven code design, the engine is definitely keeping things interesting.
I can see how some studios may want to retain maximum control of a game engine they use. But I think the quoted post is a bit misleading in blaming it on C#. It’s mainly an issue of how much of platform API or source code is exposed to the public, rather than in which language it is written.
And I think just releasing the source code is not sufficient to ensure that level of control. When a framework or platform is not designed to be extended, modifying its source code is simply asking for trouble, especially if you ever want to upgrade it in future.
If big studios indeed prefer Unreal for its freedom of control, I suppose it’s specifically designed that way to allow such extensions. But as I don’t have much knowledge of the game engine, so I can’t really tell if it is actually true.
At any rate, what binding language a game engine uses is quite irrelevant to the problem. So, if it is indeed such a big problem with AAA studios, I suppose similar things can be done in Unity without its dropping the support for C#.
Let’s be realistic though. How many AAA developers have a license that doesn’t include source access? Unless Unity Tech charges a truly exorbitant fee the cost of licensing source code is a relatively minor investment compared to the overall costs of developing a game that is typically labelled as AAA.
Plus, Unreal Engine 4 implements a Garbage Collection as well:
https://docs.unrealengine.com/latest/INT/Programming/UnrealArchitecture/Objects/Optimizations/#garbagecollection
Oh relative to the whole project the price is small. However, it is a cost that isn’t typically thought of upfront by the production/business side. The problems usually rear their head late in development when tensions/frustrations/cost overruns are high. Having engineers work to try to diagnose difficult issues, then requesting to get the source code later is typically an “unexpected” cost to the development late in the process. Also Unity tries to get companies like this to pay for enterprise support in addition to source code support which is a pretty hefty price tag to swallow. After factoring in all of the seats, source code, and enterprise support, Unreal’s 5% is typically a much better financial prospect. Plus it gives them the source “out of the box” without all of the seat management problems that come with Unity. It just doesn’t make sense for AAA development to be honest.
The game industry has a thing with control. It’s understandable but it’s often not balanced. And very often we do a bad job at evaluating the cost/benefit in the larger business context.
It was one of the first things I noticed when I got into game dev after a decade in web dev. The environments we work with in games, limited resources, has ingrained into the industry a natural bias towards more low level control. While web dev with basically unlimited resources put it’s focus on productivity.
So while there are times when you need it, that large companies just defacto need it at this point in time, I don’ buy into. I’ve been tech lead on large games so I know the context. I know it well enough to know that if anyone can screw it up, it’s a larger company. The bias is just inherently more strong there, to almost ridiculous levels actually.
I agree, I think you make a very good point about control sometimes being a detriment to productivity during development. Which is why I’m fine with using Unity. It’s a tool that quickly moves me forward.
I’m sure this could be an entire thread in its own, but I would guess the controlling mentality stems from games historically being written to very specific hardware. The hardware often did not have cross-platform APIs and required very specific engineering to get the game functional. Where web development (I imagine), cross browser/device support is a fundamental tenant of their development process.
Speaking of control and graphics specifically: the new Scriptable Render Pipeline tech is almost shipped, and will give you greatly increased control over how rendering happens (if you want it).
I want it.
I may have expressed myself incorrectly given english isn’t my native language.
I wasn’t blaming C#, I was just reflecting the things I see and hear from those people on the subject.
I can only speak of asian studios as those are the ones I have experience with though.
Personally I’m a fan of C#, but I hate that its generated IL code can be “hacked” so easily; but that’s off topic subject…
So, even though Squeenix have Luminous Studio engine up and running, UE4.16.3 is currently used to develop Final Fantasy 7 Remake.
The main reason is in-house engine’s networking layer is pretty much a WIP by now, just like Unity’s networking; And multiplayer features (extras) are planned from the get go. Unreal 4 has a rock-solid multiplayer integration plus all productivity tools for asset management are already there by default, plus the factor I was talking about before: the engine relies only on C++ to get your game running.
Paying the necessary efforts, Blueprint VM can be removed, C# VM can be added, Python, NodeJS and etc can be used for scripting. The whole renderer module can be replaced by in-house developed one, so on and so forth…
Now, I’m pretty sure people know that each UniyEngine.Object suffers from wave-particle duality phenomenon; Unity object exists both in unmanaged memory and managed world of C#. When you create a script Unity manages this object for you so you don’t need to touch any C++ code.
Let’s say then your company has a code-base of over 50.000 classes developed across many projects shipped along the years and you might want to use them whenever you see the need for any of these classes;
Being raw C++ code these classes, with a little effort, could be relatively quickly ported to fit Luminous Studio API, fit SnowDrop API, or fit Unreal 4 API, etc…
But, you have picked Unity so now you just have to create a C# wrapper for each class you use if you want to use such code-base in Unity and of course your 50.000 objects are now 100.000 that you’ll have to fit inside your frame budget somehow; Creation of the C# wrappers will take considerable development time; Your programmers will do things with the C++ objects and completely forget about the C# counterpart, you all are going to run into == operator issues constantly; You’ll run into internal bugs and people will have to learn how Unity works internally to solve these bugs. People around want to work in C++ only then go home and call it a day and constantly argue that only designers should use scripting languages and why the hell C# is needed for core gameplay classes.
Class constructors are going to flood bug tracker because nobody is ever going to figure out how to use constructors in Unity, or how to work without using them.
People will beg for moving back to a C++ engine and someone may be ‘let go’ in the process.
Now let’s say you have over 50.000 classes built on C# that work well in Unity you developed along the years and someone suggest next game should be done in Unreal 4… Would you?? Good luck with that.
Basically that is what I meant with “prohibitive” and “unnecessary overhead”.
When I made this point before you did earlier in the thread, I avoided going too far down the language side of things and implied that most of the work needed would actually be ripping out unwanted middleware and rendering. So even if you stripped all of C# from Unity (hint: you can’t - a lot of Unity is also built on C# not just C++) you would still need to accept the rendering and middleware integration.
So the take away is, you pick Unity if you want Unity to make decisions for you. I kind of do - these days at least
People seem to also assume that if a developer doesn’t choose Unity they’ll automatically choose UE4. That’s not the case, proving C++ isn’t the be all or end all of choosing the right engine for the job. Let’s say Unity goes with C++ as an option for developing in. I bet you any money it won’t change anything.
I wonder why they don’t. Of course it has their business interest and they are doing very well. But it would be a good thing to have it open source that would create long term strategic vision for them.
Why?
I think if anyone needs to replace the whole rendering stack and scripting engine with a custom built one, they better think about creating their own engine, rather than using either Unreal or Unity.
Maybe some studio actually decided to rip Unreal’s codebase to build their own engine, but I wonder if it’s anything we can regard as a standard practice for AAA studios that purchase Unreal license.
What you are describing is basically ripping the whole user API layer off a game engine and migrate into another one. I really doubt many of game studios actually have such a requirement when they choose a game engine, not even AAA ones.
Correct me if I’m wrong, as I’ve never seen how AAA game studios work. But to me, it sounds like a really peculiar corner case rather than something most of big studios do.
Try porting 50,000 classes Unreal game to Unity and see if it’s any easier. I’m afraid you are a bit confused about abstraction layers. You can’t just grab the whole user API layer from one engine and put it on to another, simply because they are both written in a same language.
If you absolutely need to build that kind of a frankenstein game engine and have resources to do that, you can just put Mono VM and implement Unity API layer on top of Unreal engine. There’s zero need to rewrite each and every 50,000 game logic classes that way, and I’m pretty sure more or less similar level of effort would be needed if you go the other way around from Unreal to Unity.
More likely scenario would be porting just the game logic, rather than the entire user API layer from one engine to another. In that case, being written in C# or C++ doesn’t have inherent advantage in itself, as it’ll be much harder to port an Unreal game to a game engine that uses C# like Xenko or Godot (when 3.0 arrives) than porting an Unity game in that case.
Are you sure? I ask because capcom decided that UE4 was still more cost effective with bits ripped out than upgrading their existing engines.
It would cost a lot of millions to make anything remotely approaching a modern AAA engine, especially a cross platform one with no code licensing issues and no surprises. And frankly, a lot of studios can’t find the people for it not could they afford the time and problems taken to do it.
Case in point: you’re smart, so tell me how you’d construct frostbite engine for under 25 million dollars within 2 years? Can’t be done.
When you see that, you know UE4 makes way more sense for these teams than to roll their own. Big AAA has already rolled it’s own. Eveyone else out there - hundreds of studios - are still having quite a battle with in house vs off the shelf as their ambitions try to keep up.
Meanwhile the rest of the entire planet just uses Unity and has to endure my obnoxious forum commentary.
I think I’m confused here. Are you basically saying that Unreal is better than Unity because it’s a standard practice among AAA studios to build their custom engine on top of Unreal, replacing the whole rendering, scripting, networking layers?
If it’s indeed the case, kudos to Unreal people for their smart licensing policy, and maybe for better design decisions.
But I guess it’s no longer a matter of pros and cons between C++ vs C# in that case, and what you are implying becomes simply that Unity or any other off the shelf game engine isn’t fit for AAA studios, which is quite surprising, considering you have been a quite consistent proponent for Unity in the past.
I though by now people would have it figured out that such thing as “better” choice makes no sense. People stick to what they know, stationary by nature.
There are industries, multi-trillion industries, still using MS DOS for their systems and machinery.
As hippo guy said, Unity serves his purposes well and giving Unity some of control that Unity needs to take out from you to run, it’s a plus as it’s less work for him he have to be done.
For studios out there, that is a no-no and why build another engine again? They have Luminous Studio already, remember?!
@mysticfall I have the feeling you would totally hate and be terrified if you ever work for studios like Ubisoft Montreal because, in there and alikes, each game project is using their own “Frankenstein” to get the job done and for every sequel frankenstein is gonna have a baby.