Where's unity going, and it's place among other engines.

Hello folks, Joshua here, and I wanted to talk about Unity's momentum. Unity has always been seen as a small, weak engine, used only for mobile or small indie games, or easily prototyping ideas. However, with the additional features such as Scriptable Render Pipelines, Entity Component System, Job System, and the Burst Compiler, I'm starting to see the engine grow into the unexpected. So I'm left wondering what place will Unity take among other engines? Will I be able to use Unity for the larger and more complex projects now? Or will I still need to jump ship whenever my projects get more ambitious?

There have been many analogies that have been used to describe Unity, but the one that stuck out the most for me was, "Unity is like a compact car. Small, weak, but portable enough to fit in any parking space." I feel like this is true if you look at most of the games ever developed with Unity, which have mostly been mobile and small indie games, due to it's accessibility. The engine itself also lacked power since it relied heavily on interpreted languages (boo, javascript), especially when compared to Unreal, which uses C++. The graphics technology was also behind especially when compared to Unreal. The idea of using Unity for large, ambitious projects was largely scoffed at by gamers and developers alike.

However lately Unity has been producing some very interesting feature updates, expanding it's capabilities and, frankly, getting to a level to rival with Unreal. The Scriptable Render Pipelines gives developers who want to get more out of the engine a tool to do so. The HD Render Pipelines gives us access and more control over what's rendered, and how it's being rendered, so producing that AAA quality becomes rather realistic (look at Book of the Dead!) The Entity Component System changes from an Object Oriented approach, to using a Data Oriented approach which frankly works much better in practice than OOP. It allows us to then start using very powerful tools like the Job System and the Burst Compiler. The Job System helps us utilize the many cores and available threads to process multiple jobs, paralleling tasks and remaining thread safe. The Burst Compiler pretty much eliminates the language issue by compiling the byte code into native code using LLVM. These features look like they are bound to push Unity into direct competition with Unreal, and possibly other great game engines for the use in AAA quality games.

So again I say, I'm left wondering what place Unity will take. For the longest time, I've considered using Unity only for our first project, and perhaps for the next if we didn't get a good ROI, and then pivoting into Unreal or even Lumberyard. However the more the features get developed and the more advanced and powerful this engine becomes, I've started questioning whether or not I will pivot at all. I can see the many advantages of staying on Unity. I understand the workflow, the features, and the more I dig into the engine, the better I know how to use it. That knowledge is vital for creating a good, ambitious game, and pivoting would incur a new learning curve and wasted time studying. However if Unity can't get passed the point of a small compact car, then I would have no choice but to scrap it for that nice SUV or F1 formula. So I would like to pass the question off to you folks. Do you think Unity will rival Unreal in quality and fidelity, capable of delivering AAA gaming? Or do you think Unity will always be the small compact car, or should stay that way?

Thanks for reading!

 

Unity with the project they're doing will be a shape-shifting car. It can be a Polski Fiat, which fits in tight parking space (UTiny project) or it can be an Abrahms, which is just going ahead and really hard to stop it (the last architectural changes make it robust). Or it can be a street racer and go in the track with it (job system and such).

 

Please format your post properly.

 

What stopped you before? Just curious.

 

Engine speed and render features. I'll admit that even before HDRP you could get some good looking things in Unity with the right amount of work and custom shaders, especially when the post processing stack came out. However you still couldn't make, say, God of War 4 in the engine.

 

That's because God of War's engine was specifically built for God of War.

 

You could. Hire hundred people, buy a source license and invest a couple millions in dollars and you could do that.

 

True, however that same engine could be used to build non God of War games, but with the same fidelity. My point is that Unity couldn't do that before, or to say, Unity couldn't produce a game of similar quality.

The point of this thread isn't to say how great a difference Unity is from God of War (engine), but to ask whether or not Unity is heading in that direction.

 

It won't be though, and the act of extending the engine to make other games, both in terms of fidelity and gameplay, will be a non-trivial task to say the least. So no, Unity is not headed in that direction. Unity is designed as a general tool rather than a specific one.

 

People say stuff like this a lot, but I've never seen any evidence to support it.

Unity does definitely have weaknesses, however...

First, it's not productive to compare a general-purpose tool to a purpose-built one. Purpose-built tools can work based on many assumptions that general-purpose ones can't, which can give significant gains in areas that are of particular help to a specific project. For instance, God of War runs on two variations of one platform, rather than an uncountable number of variations of... is it 27 platforms now? Everything in that game could be designed around the specific strengths and weaknesses of that hardware. Unity can not do that.

Secondly, despite that, most of the time when people claim Unity can't do something it really means that they can't do it. When comparing stuff done in Unity to stuff done by SIE Santa Monica, remember that it's not just the engine and tools that are different, it's also the team. SIE Santa Monica has many (most?) team members with years of high-end commercial experience. If that same experience was available to the average Unity game then they'd probably get comparable results, too!

Edit: At a tradeshow a while ago I had a fellow from Unity ask what engine our game was in. He was surprised when I said it was Unity, saying he probably would have guessed Unreal. The point is that while your tools do make a difference, the thing that makes the biggest difference is what you do with them.

 

Good reply! I agree that unity is a general purpose tool, but we're starting to see it open up to be more malleable so that you can purpose build it. I agree that if you have enough time and money, you could use Unity to do just about anything, but I think my point is that it's not out-of-the-box and the time and money you spend on doing "God of War' in Unity could be almost eliminated by just using a different engine. But let me be clear that I'm talking Unity 5.X, 2018.X is a completely different situation, which is what I'm praising Unity for.

 

What engine?

 

That description was probably brought to you by the same level of internet echo chamber that describes Unreal as "only suitable for FPS games".

 

Unreal: Pretty much looks beautiful out of the box. You can definitely achieve the same fidelity with Unity, but with a little more setup, but doable
Lumberyard: I haven't gotten to much into it, but it's a derivative of crytek and meant to address some of the railroad issues
Crytek: There's definitely some issues here, but with the right engineers, it becomes manageable
Frostbite: Up front a beautiful engine, but pretty closed up so unsure of how easy it would be to get a good looking scene, but the engine has supported multiple genres of games from fast paced fps to open world RPGs, and handles the quality of those games with high performance. Only real problem is licensing or possibly having to fall into the EA bandwagon.

I would say the most powerful example here is Frostbite. But who knows, maybe Frostbite is based on core unity code.

 

Yeah no. Also no to all your examples. No generalised engine will ever perform as well as a specialised engine.

Honestly, you're displaying a lack of technical know-how here that makes me pretty certain you're not going to be making high fidelity games of this scope anyway.

 

Default settings are not the same thing as "fidelity".

When the Unity guy mistook our game for Unreal we were using the built-in standard shader, a couple of Asset Store packages for sky and water, and built-in fog. I am not a shader guy, so we have very little custom work in that area (and what we do have is really simple stuff). Our fidelity entirely came down to our artist being a good artist, and that's engine agnostic.

 

It's not unwarranted. I agree that it could be seen as short sighted, but making a game that uses byte code and/or interpreted languages (boo, javascript) will objectively be inferior to systems using C++ engines with the capability of writing raw C for maximum optimizations.

Running code through a VM interpreter will always be slower then well written native code.

 

Definitely, well that's great to hear!

 

Sorry, but this just reinforces @Murgilod's point. It's been standard for a long time for games to use a mix of technologies including both native and VM/interpreted code. A huge amount of the code in a game has no practical impact on performance. Even when you're using non-native code you're often still doing it on top of a native engine. So on and so forth.

Edit: And don't forget that Unity's C# actually gets converted to native code via C++, so your argument is moot there.

And also, all of that is coming from someone who definitely agrees that C/C++ is faster. No argument there. There are some tasks I would always want C/C++ over C# for. On the flip side, though, there are lots of tasks where it simply doesn't matter.

 

Yeah.... That's my point. It's been my point this whole time. Which is why I'm looking at the scriptable render pipelines as a way to specialize Unity. Unity has created the SRP in order to open Unity up to specialization. The ECS updates have also been done for similar reasons. I understand that base Unity will not be able to match specialized engines, but the whole point of this thread was to ask if Unity could be specialized using SRP and the other additional features, to hopefully achieve a God of War.

I'm not sure why you're attacking me and my competency, but I hope you have a better day.

 

I'm more or less looking at AI development which if not handled correctly can have a severe impact on time to frame render.

I agree that for the most part, code that you write for systems in general will be negligible, but when it comes to handling a massive amount of objects and running operations on them, Byte code becomes a problem. There's a reason why the Burst Compiler exists.

 

There will always be overhead and the SRP isn't going to change this.

I'm calling your competency into question because you have displayed several times in this thread that you lack the core competencies to make many of the claims you're making and in the questions you are asking.

 

Ok, this is a specific use case. In this particular use case I agree. I've done this type of work before in C#, and I definitely would have preferred to be doing it in C++.

Your earlier comment, however, is untrue. A game isn't going to "objectively be inferior" just because it uses VM or interpreted code. If it performs badly that's (probably) not because of the VM or the interpreted code, it's because something was poorly designed* or implemented.

* Choosing the wrong tool for the job, such as an interpreted language for heavy data operations, is definitely something I'd call a poor design decision.

 

Okay, thanks for your input. I hope you have a better day.

 

What specific things about God of War do you doubt could be achieved in Unity right now?

That would be far more beneficial to cover than fluffy high-level discussions of general inferiority or superiority.

 

Apologies for the double post, it seems I'm missing the later post and in two conversations.

So I'll take a step back and reevaluate my position on that. One thing I haven't taken into account is that performance of interpreted code is entirely based on the version of the interpreter, and the speed or 1:1 performance to native code is entirely based on it. Seems there are interpreters that can match native code. I was coming at it from the point of view that interpreted code has that extra step before doing operations, which was a source of speed issues from early interpreters.

 

I suppose I don't doubt that you could, or to better put it, I don't know if it could and hence why I'm asking.
If it could, if it can, if it will, influences whether or not I stay with Unity for future projects. I would love to stay with it since I've started getting deeper into SRP and better understanding of how to work with Unity in order to make great games.

However, if it's never going to be able to achieve a AAA quality, then I need to make a decision to pivot from Unity whenever we have the resources to do so.

 

Take a step further back. You're not taking into account the fact that only a small amount of the code in a project needs to be highly performant. The majority of code in a project can easily get away with simply not being stupid. Stuff like physics and rendering and handling Transforms all needs to be as fast as possible... and that stuff is mostly done on the native side of Unity anyway.

I'm not familiar with the game, so I have no idea what you're talking about. What is a feature or scene or visual in God of War that you don't think Unity could do?

 

Nobody can tell you if Unity can make 'AAA' quality. Nobody agrees on what term even means, just search for the term on the forums here and you'll see what I mean.

The first question is, what do you think of the Book of the Dead? One would assume that's very near the best of rendering that Unity can offer.

If Book of the Dead is not good enough, then have you spoken to some top artists who can produce God of War-quality scenes in other engines, and asked them what they can do in Unity? If you're going to make a God of War-quality game, I would assume you know plenty of them, or you should. Asking this kind of question on the Unity General Forums is like asking on twitter if AI will trigger a singularity - everyone and their dog has an opinion on this, but you know what they say about opinions.

Based on my perusals of Polycount and Artstation, where most of the people who know what they are doing art-wise reside, and based on the few artists who showcase (some of) their work in Unity, I would say it's not quite at the level of some other engines in terms of graphics. But should it matter, if all else points to Unity? It's up to you. Unity's a great engine, the post processing stack improved things a lot, and you can make something that looks pretty good. Maybe that's enough.

 

Yeah, I should move away from saying AAA and instead define explicitly what I mean. Open world, high fidelity (photorealistic assets, and advanced particle effects), competent/advanced AI, complex game event systems, all while running at a solid 60 fps or more without requiring a very powerful PC.

But I'm starting to get the impression that you are right, and I'll never get a straight forward answer. On one hand, I'm being told that Unity will never be as good as an engine specialized for such games, but on the other I'm being told it's always been possible.

Having great artists definitely goes a long way, but you still need the technology to get it the rest of the way there. Artists don't make procedural subsurface scattering, or atmospheric scattering, or implement the latest AO technique. You need developers, and you need an engine that can handle such things. I'm in no position to implement the newest technology from AMD or Nvidia, and currently rely on the asset store and packages that unity releases. I've done some shader work to port over the BotD wind model, but there comes a time where I have to actually start working on the game.

I'm sure that after making a game or two on Unity I'll have a better understanding what can or can't be done on Unity from a time/money perspective and decide whether or not I'll stay on.

 

You just don't get it. What you're talking about requires a more or less specialized engine. If you hire 100-150 people (which you need if you want to finish a game like that in a timely manner), you buy source license to the engine and you modify it to your own needs (and you can use C++). Like every other team did with their engines. Like Skyrim didn't built upon a "stock" Gamebryo engine.
So really, you didn't give us any help what are you talking about? Are you asking if you can make a Skyrim (or a GoW) alone? Or if you hire a big team? If you hire a big team, you can do anything if you're clever and talented enough to design the game and lead that many people. But you won't build a Skyrim alone. And the engine is your smallest problem. You just can't place that much content on a map alone. And script it and tweak it to make it any good. And we didn't talk about writing, sound design, creating every single item, organize them, etc.

Unity is a great engine, you can do a lot with its stock form and now you can see that they are improving it, which means if you start a big project, you will need to modify it less. But it never will be zero if you want the maximum.

 

Yes, I see this behavior with larger games, but I also see engines becoming more and more capable and needing less overhauls to be used for such large games. Let me clarify in saying that I'm not currently working on a large project with those kind of needs.

I'm starting to understand why this question isn't getting me anywhere. Because it's hard, if not impossible, to know when or if I would ever need to build a specialized engine, because that specialization depends on the technology that exists, and whether or not your engine supports those out of the box. If they don't you may need to update that engine, or use/build a different engine, thus specializing.

 

Back to topic. I think Unity is heading to "not be specialized" or lets say to be specialized as good as they can in "mobile sector" (where they have been always good), and now to the "HD Graphics sector", and of course to these other fields in the "non-gaming sector" like architecture, automotive, experimentel, etc.

The Unity engine tries to be very good in every discipline. I would say, that we all can say that they achieved really high class graphics in some demos, they´ve done. So they gota good catch-up to other big gameEngines. On the other hand, i don´t like that the mobile-sector suffers a lil bit in terms of performance and so on. But...as we saw, they are working on this project, called "project tiny". So i got the feeling they don´t forget where they´ve been strong, what made them big.

I hope they go the "indi"-way. Be on the side for indi-devs. Unity grows big. Therefore i am a bit afraid of big companies. Like Autodesk. They grow so big (a-desk), that they don´t care so much about their users, user suggestions, user requests, etc. Focusing only to big clients from Holywood / big game-studios. So i hope Unity, as they grow much bigger, will keep company also with the smaller indi-devs and have good license conditions (you never know what will come in the near future).

Currently i would say their biggest strength are in: 1.) mobile sector, 2.) indi-games 3.) non-gaming sector 4.) VR / AR stuff. Sometimes i think they should split up the engine for every specific field (could also be a more benefit for indi-devs in terms of licensing-price). I am curios what Unity 2019 will do to improve the UX.

 

Ha! Had to laugh at this. Yeah, because I couldn't make God of War 4 no matter what engine you gave me.

I don't have to worry about what engines might be "better than Unity", because as a simple solo developer, Unity already facilitates more than I can reasonably achieve.

I definitely agree with you, @felxaga, that Unity is broadening it's scope really quickly in the past two years (faster than I can keep up with). I think part of it is marketing( i.e. "These are things Unity was always capable of, but now we're really showing it off") but, on the otherhand, things like SRP are really a step forward and really surprised me. I'm sure Unreal Engine will come out with its own game-changer in a few weeks and the back-and-forth will continue, though.

 

I hope not. I hope they don't take sides anymore. And they really never have been by the way. In my opinion it was just a side effect of the "democratizing game development". Because Unity is easy to use out of the box and up until recently it wasn't really a rocket science depth you could take. Now it is changing, it should remain easy to use on the base level and they need equally serve people who want to dig deeper and turn those knobs to eleven.

 

Unity itself was written in C++. The code that game developers use when building a game in Unity is C#. You don't use Boo or Javascript with the latest Unity. And the C# code that you write is actually converted into C++ behind that scenes, and then compiled into machine language at build time.. The C# implementation in Unity is definitely NOT an "interpreted languages". It is definitely compiled. Unity can perform a lot better than you realize.

As for gamers or developers scoffing at Unity, that is another misconception. People usually own a bunch of Unity games. After all, most games are most in Unity. Even people who claim to dislike Unity will still play and enjoy many Unity games.

 

Quite simply you just test it to see if it meets your needs. You seem to be talking about doing a rather large scope game. As such, you test your tools. You haven't asked specific questions or details about features that may be deal breakers. You know your needs, your skills and abilities are key components when building a game, so you test. You build a vertical slice or tech prototype to find the edges. I not sure there any value (in development) in making a choice based on asking vague questions to random strangers. You are describing a projects that is going to take years, and many people, spending a few weeks testing a tool is a trivial investment.

 

No idea what that means.

 

Beating a dead horse on this one mate. All I'll say is there's a reason why the Burst Compiler exists and why it increases performance of ecs jobs straight out of the box. Not saying that the current C# implementation is slower than C++, but Unity has the burst compiler for a good reason. Perhaps it has nothing to do with compiling into C/C++ but instead compiles in a much more efficient manner since it's supposed to be used with the Job System. Either that or the Burst Compiler is completely unnecessary, unless someone can explain to me why that is not the case or if I'm misunderstanding what Burst Compiling does. I'm fully open to being corrected.

 

I got impression, that here we got big focus on performance and graphics, but little about the concept and game play itself. For which first one will get you nowhere, without a second.

Burst compiler don't have to be used with jobs. But benefits a lot. Specially with ECS data oriented design.

From my experience, I had at least 10x performance bust, using just burst, on one of my prototypes. And i am not alone in that. I let you judge by your own.

Personally I am not interested at this point, what really happens on machine code level. I am interested in implementation outcome. I leave rest to the specialists. In the end can not master every topic. But that is where Unity profiler, or any other performance tool in any engine helps, to measure and tweak performance.

If I would start diving into such micro details, for sure, no time would left for building mechanics, or graphics (shaders). That is considering for solo dev.

Answering question, yes.
Simply look at Unity titles. Not just small ones. Including City Skylines.
(Now and before)

ROI result, will be merely based on your design, concept execution and marketing.
What tool you are going to use, is least relevant. Graphically, if you want out of box Unreal solution, then you will end up with meh average looking product. In either engine, you would need put some effort, to look standing out, above the crowd.

But jumping between engines after each production, is counter productive.
Unless you just build, prototypes to test, or have resources to burn.

Also, you need consider available resources, tools and active community.
I think Unity may be winning this bit, over other engines.

 

The Burst Compiler has a reason, but it is not the one you quoted so far in this thread. The new Burst Compiler feature is designed to optimize the compiled code to improve the effectiveness of the CPU's internal cache when running data driven scenes with massive numbers of units. Think of it like a super charger for the ECS system.

 

So what implements, is called aggressive inlining.

Code (CSharp):

1. AggressiveInlining

 

I think you posted this in the wrong thread.

 

Nah, I wanted put reference to the topic, since we mentioning Burst Compiler, and what is behind.
Anyone interested, can look up further for details. Is just to state, what involves.

 

Agreed, but perhaps others could share their experiences which would give you a good idea of whether or not what you want to achieve can be done. Indeed, I'm still figuring out what that large project would look like.

https://en.wikipedia.org/wiki/Direct3D
This also would include different shader languages like HLSL, which was introduced in 2017.1 (hint, this isn't exactly a technology but a language, but I still stand by this not being introduced into base Unity even though HLSL has been around since 2011).

However yes, I know what you are going to say. Just because it's not a part of the base Unity Engine, doesn't mean you can't introduce it yourself with commitment and if you have the need.

 

Updated OP to reflect an error in associating Shader to Graphics. Although Shaders can use Direct3D APIs, it does not explicitly require them, and the intention behind "Shader Technology" was to point at the Direct3D APIs, and is more correct to be labeled as Graphics Technology instead of Shader Technology.

 

That turbine engine eats alot of gas, just take out the support vehicles and it will run at out of gas really quick

 

...You can just write your shader code in Cg.

 

Because apparently the competition isn't using bytecode or interpreted languages... oh, wait.

Blueprints are interpreted bytecode. There is a way to translate them into C++ and then compile them into native machine code but the performance will be nowhere near as good as Unity's C#.

You can develop entirely in C++ but the performance gain comes with a penalty. UE4 relies heavily on macros to achieve some of the ease of development that C# has but it still never becomes as easy to code and debug scripts with as C#.

Finally UE4 lacks an equivalent to Unity's ECS framework and I believe that will push Unity far ahead in the coming years.

Lumberyard and CryEngine V both use C# except they lack the performance optimizations (IL2CPP, Burst, etc) that Unity possesses making their implementations inferior. Worse yet like UE4 there is no equivalent high-performance memory-optimizing framework meaning that inferior C# is the best you get unless you want to dive into C++.

A C++ that, unlike UE4, has no macros to assist with making it easier to work with. Hope you enjoy working with C++.

Closed source engines are pointless to discuss because we'll never reach the point we'll have access to them.

 

You always ruined the game of other kids on the playground when you were a kid, didn't you?