I have been wanting to be able to objectively compare feature parity between different engines for sometimes. Most devs I encountered are too “cultist”, worshipping only their own is not enough but must try to obliterate the other side.. or just simply throw this line “try it and you’ll know why it is better” rather than addressing a specific advantage.
I have experience in Unity for 6–8 years, while Unreal Engine is just started around January 2019. I am quite sure I can pinpoint “what sucks” in Unity because I had suffered with them for years on things without improvement. It will come in handy when I see things in Unreal Engine that is sorely missing in Unity, or just recently added but in preview status, or in a development road, etc.
This article is not for Unreal Engine user, because I did not spend time explaining Unity terms. Unity user will be able to follow because you are just as new to Unreal as me while knowing what’s available in Unity.
This article is in-progress. Because I can’t know Unreal throughly to judge objectively overnight. It will probably takes years to complete and make a completely fair judgement.
This article is biased favoring Unreal Engine. Because I know what’s bad in Unity side but not UE side. For now, you will see multiple “I am guessing” on the Unreal Engine side, which I will edit out once I know more. I probably haven’t get in far enough to know things in Unreal that is not good.
How I get used to Unreal will be via smaller side projects.
I will not provide verdict like who wins and scores on each aspect like those phone review websites either, I don’t want you to be “too long didn’t read” on stuff.
It is to prevent ambiguous claim. If I say "Unreal is much more powerful in 3D rendering" (this is one of the most popular claim) I would have to say exactly what is it that make the difference, that make it more powerful. If it is "just" better but I am not able to know why, I will state that explicitly.
Otherwise this article will become like fanboy VS articles out there.
There is a huge drama about Unity and Improbable right now, and Epic Games joins in for the opportunity.
Epic is playing its own strength to the maximum right now, which I applaud. UE is taking % from your game’s sales, in a nicer wording “your success is our success” but Unity sells license and services so they had to protect their tech by laws and stuff more. No matter what the truth is, right now it is easy to make Unity looks bad and greedy but UE looked generous and positive. Such a scary business world, but I enjoyed learning the tactics employed by all parties involved. Anyways, you have to search for it if you want to read up more.
I would turn this whole thing into a chance. As a nice excuse I think I might as well try going through UE’s walkthrough while the topic is hot. (It appears after opening the program with glowing guide and stuff, so nice!) And here’s the article resulting from it.
The most subjective thing is interface design (if you "like" it or not), but in UI world we are able to compare their function and how it affects the workflow. We touch the UI at every moment. And so this is the objective part of UI. There are papers and text books that compare usability of UI regardless of you "like" it or not.
Unreal looks dated where the world had already moved on to “flat design”. It uses gradients, a lot of 3D in the UI that’s not the viewport, and a lot of curves/rounded corners. Thankfully, the UI color is industry-standard dark. It’s funny that Unity’s UI can only get dark after being “professional” lol. But overall, too busy UI for my taste.
Unity hasn’t update its own UI that flat either (though that’s coming soon in 2019/2020 or so they say with their new UI Elements system?) but default Unity is still flatter, with less 3D icons and less colors.
Unity had major update once where it became compatible with Retina display but that’s about it. The font is also pulled from the OS, if I run Unity on Windows the font would be different.
Well, this is a personal preference but I like Unity’s design better. I like things that looks “techy” and if I may put it in the worst wording “boring”. Like minimal/techno (many normies called bigroom, dubstep, trap, EDM as “techno”, it is wrong) /drone/noise music, not a single of my friend said they like minimal music when I introduce it to them. (some said is this even music??) So “boring” is not a negative to me but more skewed towards “playful”. I feel like I want to play around with it.
In 2019.1 alpha, Unity made more adjustment : the font are a bit whiter and sharper.
Unity’s UI is “tame and clean”. From a glance you can see that things take up a fixed line height mostly. (This goes long way into when making a custom inspector) I like this enforcement though. Also Unity’s dark is darker, similar level to Adobe CC’s dark vs Clip Studio Paint dark, CSP one is not dark enough that it makes the white them actually looks better.
To draw a comparison to other program, in a DAW (program for making audio for the game, etc) I liked Ableton Live’s design.
Other programs that I don’t like as much looks like this :
Am I nitpicking things? I think not at all. If I am going to use one mechanical pencil every day, I would also complain about the material it was made of instead of functions as I have to touch it every day. (GraphGear1000 is awesome by the way, just the right weight and good finishes on the barrel!)
In the DAW business, almost all DAW is capable of doing the same thing. But the difference is the feel they give, how they present the feature and keep the flow. Making music is very spontaneous, speed of getting to your idea became more important than features because you could make music otherwise not possible if the DAW is not inspiring you. For example Ableton Live I am using cannot do “prefab” equivalent kind of thing in music making, but in turn that encourage slice and dicing clips without worry about reuse. It encourages experimentation and mesh well with other “dirty” nature of that program. There are other DAWs suitable for more organized composers. I got the same feel from Unity, while feeling incomplete and wonky it encourage experimentation. (Something that usually waste my time on actually shipping the game to be honest.)
Unreal Engine is very resource intensive! I got a warning dialog on opening up about UE is best on quad core something something, but I didn’t think it would be this intensive. On the default scene with 2 chairs, rotating the viewport with a mouse already present some lags. (Around 0.3–0.5s, imagine I rotate quickly and 0.3s after I have already let go of the mouse the screen is still spinning, catching up with the remembered “motion” I did.)
Here’s the spec that is not enough.
I have no problem in Unity so far with this spec. Well there is a problem that no matter how fast your computer is you must face...
Play Mode iteration
One thing super notorious in Unity, assembly/domain reload time. That is the time it takes to enter play mode. At first it is not much but as you give in to Unity and grow your project.. years passed and now to enter play mode it takes 20 seconds!! No asmdef or anything helps.
It is a lot, it adds up the more you want to do iterative design and it throws you off the flow, most importantly. And what’s worse, it depends on the project not the scene. If I create an absolutely empty scene in a heavy project, to enter play mode on that scene would take as long as the other scene.
In UE I still didn’t go that far to make the project heavy to compare, but the test scene’s enter playmode is already faster than Unity. Faster like, almost the speed of pressing “Simulate” on the Shuriken particle system in Unity to make it moves.
Judging from this thread it seems UE can iterate pretty dang fast. It is one thing that make or break the engine choice to be honest. I can see myself choosing UE just because of this.
Also it is painful to be “tricked” into Unity by its deceptively friendly entry, but revealed later that the performance degenerates as you goes on at the same time you think you cannot go back now that you got this far. If you ask me if I can migrate project instantly without any time cost (but you cannot come back to Unity again ever) would I move this project to Unreal? No, there are more things I want to use in Unity. For others, I can see that this is a sound option given how important it is to quickly iterate on the play mode.
Apparently Unity is trying to improve on this reading from forum post about a year ago. Unity needs to improve their sandboxing approach. For now, try to exploit
[ExecuteInEditMode] or the new
[ExecuteAlways], any way to avoid the play mode is good. Again, this area makes Unity sounds like a still in-developement engine rather than a complete one.
There is an urban myth that “Ori and the blind Forest”, a beautiful game which used Unity, take 1 minute to enter the play mode!
This affects integration test badly
Or called “Play mode test” in Unity. Play mode! Yuck! Now even if I have a proper TDD design to automate testing of my scenes, I feel reluctant to click on the integration test because it would take so long to start one. The only remedy is to run multiple tests as entering play mode is only once. But that also has its own challenge as the test “spill over” to the next, because the “sandboxing/clean up” you got from enter-exit play mode is now gone.
UE also has “Automation System” to run integration tests. Still not using it yet, but it better be faster than Unity. In fact from Unity’s entering play mode performance, I guess it should be faster than Unity.
Unreal Engine has about a decade more development time in it compared to Unity. Both engine had transitioned licensing scheme to become more indie-friendly as it is today.
Unity needs more time to make up for those dev time difference. Not to mention there are a lot more breaking changes recently as opposed to the rock solid foundation of UE. I feel like Unity is now building “that” foundation that UE already achieved. If you enjoy underdog story or something in-development you may like Unity. I also liked Unity because it is bold in breaking things.
See these posts which summarize quite well.
Made in Unreal AAA titles are countless, like Monster Hunter World and Kingdom Hearts 3. Unity seems to be go-to choice for mobile indie devs but those game rarely advertises that it was made by Unity as compared to Unreal. This makes Unreal’s public face very strong, as it is “trusted” by big games. At the same time it unfortunately make Unity feel like a “less professional” choice. (Of course you could make your Unity knowledge a profession!)
If you use
adb logcat while starting a mobile phone game and see a log from Unity then you know that game is one. Almost all mobile music games I know was made by Unity, including Rayark’s games which rise from indie company to profitable big spending company. Or Arcaea an insanely successful game which gained 10k Twitter follower from a few days after open.
Unity is abstract, Unreal is practical
In multiple places, UI, and release note, I can see Unreal Engine is being very practical in each feature. This feature do this and that. Their features are high level and specific. And often looks like a result from their own games. Some feature like big map streaming is obviously from Fortnite, where in Unity the feature like this is called "DOTS ECS Scene Workflow" (which could be memory loaded and stream kinda the same way) but you see it is not as obvious as the "this could make this" style in Unreal.
In Unity, they often give us a blank sheet and some stationery to work on. I still remembered reading up the Playable API the first time and like wtf.. trying to understand how little pieces of the timeline/clip/playable asset works so you can create a custom one is also currently very difficult. Also HDRP/LWRP, and now ECS and C# jobs system. The timeline feature is described as “a graph of playables” instead of in a more layman terms like UE did. Timeline asset, graph, bindings, oh my god! I mean, it make sense when you know how Unity works. But it make no sense to an artist.
Unreal is even more opinionated and upfront in their UI. The terrain and foliage tab is there at the forefront. No wonders all those AAA-looking 3D first person games looks “Unreal”, UE is very very 3D.
In Unity, it is up to you to make the UI fits your game. It seems to not suggesting anything at all. Well, there is a button that says 2D to turn the camera flat, that’s one thing that is opinionated. One more example from timeline/sequencer feature from both sides, Unreal has “subtitle” and “dialogue” assets for both text for display and audio system. While Unity is more generic, just audio track. Just “activation” track. Just “control” track. This is the theme with Unreal, specific and practical.
In Unity’s side, there are things like “Avatar” which is designed for especially human model because Unity think the game should contains a human. But that’s some of a rare thing that is not so abstract.
Most devs I talked to enjoyed “just using” new high level features like Unreal offer, rather than having the company try to change up the underlying API often like Unity and have to build something upon it. In Unity there are still a lot of API under Experimental namespace too!
Personally I do like to tinker with things, so I quite like Unity’s “here’s something do whatever” release note. But more business people I talked with think it is a waste of time and unnecesarily increase time cost to finish the game.
All of these adds up, I think the difficulty of Unity is higher. But in general public view, Unity is viewed as “friendly and for indies” and UE as “realism 3D for AAA”.
Let’s talk about Burst, ECS, and UTiny/Tiny Mode
Unity is clearly trying to step ahead of Epic Games on this one. I can’t find something similar in UE that boldly tries to change up how you code the game!
Threading is not in this list, because UE do have a threading system, should be comparable to C# jobs system? I don’t know if it provides a nice “pipe” that tries to make the threading experience seamless with the main thread code like ECS or not. Haven’t got that far.
For those new to these things, Burst says it will make your compiled assembly super awesome and custom-fitted to each mobile device. But wait! If you want that you have to code this way. That’s bold! By the way if you use ECS, it would be more likely to be that way. And oh by the way, Tiny Mode makes your game super small but you can only code that way!
As I say everything UE presents in the release note looks very practical. It would be ridiculous to announce something super abstract like Burst and ECS. But here it is, if you are Unity user you get hardcore things like this.
Can’t deny that when UTiny’s UI get out to the normal Unity and when ECS is built-in, it would be a ton of fun and geeky goodness for me to play around even more. (Even more that I might keep on improving the innards of my game and never release it lol) As I said more business oriented people are not excited by this kind of thing as me. They want to finish stuff, thing that already worked must not be touched.
Tiny Mode/UTiny (get it? Unity.. UTiny lol) is one other thing that is bold, it completely dissect Unity and let you use just what’s enough, in a way not compatible with the old code at all (currently). And you have to use TypeScript instead of C#!(currently) You must use ECS to program on Tiny too, and not to mention a whole new world of animation, sprite sheets, etc. that was remade for Tiny Mode. Currently you cannot even use the Animation panel and animation clip, it is best to use sprite sheet frame animation.
Something this experimental and engine-breaking would looked really funny if introduced on Unreal side. But Unity has no fear of doing so. I have talked with someone switched to UE from Unity, he said it is stupid to always make the customer a lab rat for all the features. I kind of agree, but I don’t mind being a lab rat personally. I won not once but twice in a beta test giveaway program where you are given Unity swags based on randomizing through unique bugs submitted. I tried so many shiny features and submit a lot of bug reports.
Do you often select the hardest difficulty in a game, or remove armors just for self-imposed challenge without any kind of archievement or trophies to back up the reason? I think Unity feels that way. And it satisfied certain kind of devs.
Closed source, and the pain of “extern”
In Unity, when you can’t quite figure out why something went this way, is it your fault or Unity’s fault? You would turn to Unity’s CsReference which is the C# part open for view in the GitHub. But in the end I would always come to the dreaded extern . That means from this point it is in C++, which is the closed source part that Unity didn’t open.
UE definitely feels more reassuring when you know you can dig as deep as you want and even edit something. I have been researching about audio latency in Unity and it results in this huge article.
But to write this article, it is a result of rage-inducing probing around what I cannot go in and see. (Trying various input into a black box, and reason on the output) A lot of mysteries that I must assume why it turned out that way. It would be much easier and informative if I can go in and see why Unity set sampling rate to 22000Hz for some of my phone.
The dang Animation panel that don’t let me play only once for like 7 years ago and it is still that way. I wonder how animators can work on a short UI animation while seeing it loops like crazy. See this thread I got no answer.
And the curve adjustment UX is stupid. See this thread I got no answer.
If I have an access to the source like Unreal, I would have go in and add some small usability feature by now instead of waiting years because the priority is not high enough for the rest of the world for them to care.
They used a voting system on requesting a new feature, which everyone got 10 points to freely allocate in and out. Imagine I post a request to let the animation play once, now additionally I have to rally a campaign somehow to get points so that it is not only me that is requesting for this feature. (Others might encounter this pain, but did not come to check my request and vote)
Is the "source included" blinding you?
To contrast with the previous section where I had trouble debugging into Unity's black box, this one I think Unity get it right.
Unity started to bring up things you actually want to edit
Basically, very deep features are coming from closed source C++ to C# package which are all readable and editable. It goes very well with Unity's closed source + license fee scheme, the engine code is still closed.
The first revolution is the SRP (Scriptable Rendering Pipeline) where we could edit rendering steps to the point that it breaks all existing materials, then we have DOTS (Data Oritented Tech Stack) where we decided to use hand-allocated space in C# instead to optimize cache usage, then DOTS Audio is coming where we could essentially make a new mixing pipeline on thread if we want to. The incoming New Input System let you access the input buffer memory that hardwares are sending in.
These are things I actually want to edit. In Unreal, because the source is included theoretically I could do the same to surgically change rendering steps or audio mixing. However, the way Unity did is "serving up" to the user without the engine code in the mix. The modular approach.
In a way I feel even better than Unity one day says "the engine is now open source and is hackable to the core", because I don't have to worry breaking the engine, I could edit things I care about with full Unity support.
It draws parallel to Android where it is advertised as fully open OS, most Android believer attack iOS with this argument, yet most user will only "mod" the phone on higher level. We don't actually want to change the OS, how touch detection works, how audio HAL submit audio frame, etc.
The same in Unity, I don't want to change the UI to pink or move the play mode button to bottom bar (where if it is 100% open source like Unreal, I would be able to do). I want to optimize rendering and mix faster audio, and they are providing that without breaking thier own closed source business plan.
I think it take a lot more work to enable this in the most flexible and safe way, than just open up the source code and let user edit it freely like Unreal and claim everything is possible.
Could Unreal do this modularly too? I don't know. But my Google search yields no result about rearranging rendering pipeline. For example, switching the clear color step to the last step for some stupid reason, where in Unity SRP you are able to do easily by coding in C#. Still, Unreal's theoretically could do this by editting the source.
However, I heard big companies would go great length to make the engine "their own". This is the real strength of Unreal's C++ source included feature. And you could fix all bugs by yourself theoretically, because in Unity you are always at risk of waiting for Unity team to look or fix what's in the black box.
Unity's default is weak
Some perception that Unity sucks stems from the default scene. In Unreal you get baked lighting, blurs, and blooms. In Unity you see a cube. (Recent version has HDRP starter template that looks more like Unreal level) I believe with fair comparison Unity could replicate Unreal's chair scene. Just that it is not a default.
Unity doesn’t own a game
In a nicer wording they don’t want to compete with their own user. Instead they made a demo project to test a use case on various things.
In Unreal undenieably when you see Fortnite, you would think you would have the same feature set and resources to make a complete game like Fortnite. If some feature would be sorely missing, then Fortnite can’t do that either. They must have some pressure to keep Fortnite a good game. So they must implement something new.
In Unity, user sometimes feel if the team had any pressure to implement something real quick at all, because they don’t own a game? Like the sunsetted UNET networking system with the new one only on preview. If Unity own a networked game, what will they do in this situation? Or the “new input system” that the team had been working on for 2–3 years. It is just a feeling, but can’t deny the “wow, I am using the engine that made Fortnite!” feel.
For instance Unity can’t do localization built-in while in Unreal it is there. A game of Fortnite caliber should be able to accommodate multiple languages, and that feature should be there in the engine not from external bought packages. And yes it is really there.
“Do Unity cares about user’s success?”
Everyone hope it should be like that. But Unreal is stronger in this no matter what you believe, because it is tied directly to the business model. Because Unity gains from license and services, there are conspiracy theories like Unity does not improve the editor because they want us to make the editor complete by Asset Store, which bring them revenue. (Unreal does have a store too, but the editor feels more complete) Personally I think Unity do care, just that Unreal has an edge when claiming this.
Project-breaking, reworking madness
Continuing from the previous point, In Unity, I would need something like I2Localization asset store package. And localizing is something that should be done while you make the game, if you decided to add it later then have fun updating everything and every text… it should be integrated and thoughtout in the engine to prevent this kind of “mass rework” which cost time.
And also imagine pre-2018.3 era, you cannot even reliably make the button the same instance. The button usually contains a text, and that problem connects with localization.
There’re more deprecation madnesses I have went through, *inhales* the first time I remembered the UI system was bad, so I used NGUI asset store. Then uGUI caught up with still-bad tag-based sprite packing system, so I moved to uGUI with external sprite packer. Then SpriteSheet appears that makes the packing transparent and good, so I migrate again and have to relink all the damn picture I used in the project because all the GUID changed. Then, the font rendering system sucks. This is connecting with localization again of course. Then TextMeshPro came around which uses Valve’s distance field rendering, requiring a replacement of the entire game’s text. Then Timeline came, I ditched the yield return stupid sequencer I code up painstakingly and opt in to Timeline. But then there’s no event in the Timeline! I then hack up a portal to activate the event from clips, then in 2019 where Timeline “Signal” came I would want to opt in to that instead. Also discovered Timeline could only “hold hands” with the Animator and non-legacy animation clips. There are some legacy clips I used for performace which became incompatible with the timeline, previously compatible with the manual code sequencer madness I was doing. Then Unity Package Manager came, I was using Git Subversion to share common code between projects. It was not good because script GUID cannot be shared and it unlinks the entire project with just a small mistake. When I moved to UPM basically all my shared code got unlinked for the last time, and I have to manually rewire everything. (and never again, thanks UPM) UPM also adds its own frustration, every time you do an upgrade you have a chance of strucking in the state where packages error, but because UPM is a package you cannot see and use the “Package ManagerW menu to fix them. This cause a reimport-all and various combination of pinpoint Reimport for it to work, typically costs around 3 hours (I remembered because I did it enough time) Then the Resources folder system sucks because it is the only way to load things on demand at runtime, and it is a nightmare to maintain paths that it make sense. But we are all put up with it like it is so natural to load things from folder path. Then Addressable Asset System came, as I read the description I was drooling and wonder why I could put up with the Resources folder? Then I have to migrate Resources to AAS. I thought it would be easy, the API even said you can use Resources path as AAS key and it would still work. But no! Now everything are async-based. And your synchrounous code now have to be infected with callback hell. So it is not just “replace Resource.___ with Addressables.___” as advertised. Then I looked around for ways to minimize this pain and I found UniRx.Async package that would let me maintain linear code. I then go around and update Resources based code to await ing the AAS. Oh, then the drawer for AssetReference broke that I had to write my own every version. Updating AAS version also corrupts the previous entries I had built too. Then there are some UPM packages that you must use the “staging” version, but some package like AAS if you use the staging version then it break your project and officially discouraged in the forum. Then, using AAS you need a better resource releasing scheme based on reference counting. Also this invalidates the asset bundle system, which is a good riddance but I have to learn how to host things the new way. Then adding UniRx.Async would break the PlayerLoop hackery that ECS package is doing. Causing more problems. ECS itself cause my entire game to be remade, for the better future. Nested prefabs again cause my multi-scene Additive hackery to looks unbearable and I remade them into a single scene composed of prefabs properly. In remaking the UI to nested prefab I have to redo many animations because they are now linked differently. Next up is not Unity’s fault but the world had moved on to super long 2:1 screen and I was doing as long as 16:9 only, I had to remade many UI again to fit and to avoid the dang notch. It is lucky that this change occurs at the same time that TextMeshPro became built-in, so I migrate them altogether. Almost forgot about Assembly Definition File, the idea is great, but a code that went too far is difficult to separate into asmdef without cyclic dependencies, so one another thing that should have been opted-in from the start but at that time it was not available. The asmdef feature also got increasingly better in each version, like now you can put in custom defines and dedicated test assembly. This again cause a problem in asmdef planning for my Asset Store item as I would have to wonder if the asmdef will be backward compatible or not. In the latest 2019 alpha the asmdef just gain expression-based include, which I think should be there very early to prevent this kind of non-backward compatibility problem if I want to use the feature. In 2019.1, Timeline is becoming a package as a part of UPM movement, breaking many old code and plugins that assumes timeline is built-in and now needs usingstatement. It is inevitable for the better future, sure.
But the point is Unity make this kind of move very often!
This is thankfully that I am not making a networked game. I have heard some more rants from people that makes networked game and “mistakenly” used Unity’s built-in networking solution and are regretting. Imagine how scary it is to wake up and see a big UNet text gradiented by nice “sunset”!
You see, there are a lot of things that breaks in a massive scale! But they are all the things that make Unity feels “usable”, it is even more painful to not migrate to these new things when you know it’s there but you are still doing the stupider way. I could summarize that Unity was too incomplete. Seeing AAS and new prefab workflow, I wished these things are there from the start. Right now Unity looked much more reasonable, even though most packages are still in preview status I consider them essential.
But they are so hidden, I have to tell many, “do not use non-TextMeshPro text!” “Go to UPM and install AAS and LWRP!”, “Use asmdef early on!” etc. before it is too late. It is almost like I have to quickly tell everyone I know starting the game that there is a hidden life-up missable item at the opening stage that is impossible to come back to collect later. I wish Unity can step by step making the “performance by default” philosophy becoming real, because right now there are so many wrong paths to go thanks to “blank sheet” philosophy of Unity.
I wonder if Unreal is facing with similar remodeling as often as Unity. From a glance I feel like the base is very solid. Everything they could add would be compatible in some way with the old ones, I don’t know. But I do know what pain Unity did over the years to me. Font system in Unreal for example, I am already seeing “distance field” on the shader slot. If that was in from a very early version, I would like to laugh loudly to Unity’s blurry pixel-per-pixel texture-based font.. It’s a nightmare both visually and optimization-wise. (Tick dynamic text box and you are doomed!)
My hunch is telling that Unity is far from done doing this big migration, will UI Elements break your editor code next? What will become a package next? What if it is the animation system? How long will it take to fix? Will you maintain your shared code’s compatibility with litteringUNITY_2019_OR_NEWER everywhere on things that became packages but was a built-in? If you want to stick with Unity, you have to move forward with them constantly. And while it is tiring, I like that my project is becoming better overtime and my design has moved from monolithic to a more ready for change design. But as a result I have lose so much time too. Unreal is definitely more suitable for professional in this regard.
Prefab and Blueprint
Blueprint is kinda prefab in Unity. Recently Unity shipped improved prefab workflow as of 2018.3, after using it I think I cannot go back to the old, “no more than 1 layer haha!!”, stupid prefab anymore.
I am not sure why previously Unity felt usable to me, because right now that I have properly composed my game objects I think the old Unity is completely unacceptable.
Like, now all buttons in my games is truly the same and up to date even though they are baked in a “generic panel with 2 buttons” that I also planned to reuse. You know how that sounds very stupid, and that’s true when I said Unity just been able to do this stuff to my brother that has no idea about Unity but is an architect, and he replied “lol that sounds like a feature that should be there in the first place”.
But in UE, the “prefab isolated view” new in Unity, is already there. I guess from very early version?
Also you see more opinionated stuff at the left side. Event graph, functions, variables. In Unity, the Inspector tab is just displaying components after components, what it will do is up to the scripting. You see UE is more upfront about what you probably need to make a game but Unity is more like blank paper. This is akin to Firebase (Unity) vs Playfab/GameSparks (Unreal Engine). Firebase is more blank. Playfab presents leaderboard, inventory system, etc.
In UE you do C++ first to make a functional Blueprints, then you can connect up visual scripting and spawn Blueprints to make a game. In Unity as of 2018.3 you would make each prefab the similar way and compose up a prefab in the scene and connect using exposed variable slots. There is no visual scripting in Unity, it is in the research section of the roadmap though (Jan 14, 2019). Unity did promoted Bolt asset in the store as a goodies for purchasing Unity, so maybe the official one is still very far off.
You can compile each individual Blueprint
And look, you can “compile an individual blueprint”. Just from seeing this button I feel like this is one step ahead of Unity in both modularity, AND assembly management. If the “enter play mode” of UE is lightning fast thanks to this design, I wouldn’t be surprised.
It takes isolation to the next level. Out from just scripting isolation (That Unity ECS will provide) to game engine. And it affects other design massively. Event system for example, in Unity you could use EventTrigger , UnityEvent , or the new SignalReceiver . But the interface presented that you can select the method to invoke is a result of compiling the entire C# project.
But in Unreal, it can immediately show that a function does or does not exist. You can go script it and make it exist and then hit compile just that thing. I can imagine a lot of optimization that is possible in the engine with this design. In Unity, various things are gated by the big assembly it requires. (The UPM deadlock nightmare for example!)
If you like visual scripting you should use Unreal.. period. Unity is making one too but I doubt it will arrive in less than 2 years from now. It had promoted 3rd party visual scripting solution “Bolt” before.
However I know someone who is trying to program UMG (Unreal version of uGUI) and ended up with a huge zoomed-out graph and he think that visual scripting is not a natural design interface. If it was just a code it would be much more easy to understand. (Visual is not always the best presentation)
The advantage of visual scription is that it gives you directions. It can go “this way” or “that way”. Plus you can see connections. But sometimes all the logic needs to communicate with you is not directions but reasoning. Top-to-bottom text based presentation (that is coding) may be better in many cases, but you cannot see connections. The connection the coding way got is “line” which flows from top to bottom. If you are a code-person it even feels “visual” when looking at lines, it does not have to be literally visual.
But why for shader design visual graph is considered the “standard” presentation? I think it is because you often dissect and mix/merge things, that it benefit from the connections.
It is not always the case in coding, where if it ended up “waterfall-y” then visual scripting is having disadvantage against pure coding, because coding is exactly waterfalling from top to bottom.
It’s right there! As I double click the shader a very promising UI pops up.
In Unity I can’t imagine the frustration of material artist would have to face before even getting to this point.
- Somehow you have to know that they are not built-in, but available as an official add-on package. UPM is a good initiative, but maybe too geeky for artists.
- You have to on board on LWRP first. After this your game might turns pink and take some time to fix up.
- You have to then get the Shader Graph package.
- You have to migrate your existing material to LWRP then it shows up as a graph. At this point your draw call might be unordered or go wrong, requiring some fix up.
But one bad point of UE is that that UI is extremely laggy. Zooming in and out is steppy and takes a lot of time to pan around. I guess my computer is not good enough for Unreal. I like the explorable sidebars on UE’s UI.
In Unity however it is not very explorable, opening up Shader Graph and see almost nothing is not very comfortable. On the other hand, I like the cleanness overall of Unity’s UI. UE ones is definitely more flashy looking with environment reflection preview and all. Here’s a basic example of a material with a few nodes. *viewport contains some post-processing effects.
I am sorry UE fans... but I think Unity had delivered some serious usability threading upgrade with the HPC# subset design. It changed the perspective that now “now everyone can thread!” just like AirAsia said “now everyone can fly!”.
I have read how to do threading with UE and it looked like a typical threading nightmare you would expected.
But C# job system, it might irk you that you have to use struct or you must copy things, but it strike the balance between performance and non-frustration coding experience quite well. No race condition. No memory aliasing. Automatic dependency warning.
In Unity, you don't even have to spin up a new thread and manage it. It uses Unity's "worker thread" that it already is using for engine stuff. When they are not busy, they could do your custom work. This is great not only for reducing headache, it manages work stealing/scheduling automatically for you. (Flashback to that algorithm class!) C# could spin up a thread, but C# Job System that use the already existing worker thread is just better imo.
And if you use ECS, you will thread more naturally with automatic lockstep that avoid write dependencies magically. The downsides is that all these tech are still in preview. New comers probably have no hope on avoiding all the gotchas.
C# vs C++
C++ has been synonymous with “performance” and most assume that Unreal must be faster. But previously, Unity was slow because it often travels back and forth between C++ and C#. (Mainly the call to
Update) Now with the UPM movement, it stays in the C# realm for longer.
Also with ECS, you could make the majority stays in C# WHILE getting a good assembly with Burst that could beat C++’s assembly. You see, everything became an assembly so it does not matter if it is C# or C++. And Burst is trying to make C#’s assembly competitive. (Read more here if you want to see that assembly, see if you could handcraft C++ in Unreal to beat it?)
If you love C++ then you probably love Unreal Engine. But I don’t… my experience with C++ the entire life was not good. Naming convention irks me. And I made too many mistakes.
I don’t have any good memories with C++ throughout my master degree study (where I use it for OpenGL + Caffe stuff) so obviously I will be biased towards C# ! So from here I would like to mostly advertise C#.
If you are open minded and don’t mind any of the languages, then you will need to see what civilization in the latest C# that Unity just supported.
The most powerful and game-changing in my opinion is async/await . The key point is that it returns the value to the left side after awaiting, making async code linear. Even if I like C++, I can imagine programming much faster with async/await . Also I like how tuple syntax works. Firebase Unity comes with async/await compatible API and that’s a huge boost in productivity. I don’t know what Firebase API looks like in Unreal/C++.
One of the most popular claim about C++ is that you want to use pointers rather than reference type variable. You don't want that pesky Garbage Collector. Yes, you can go
unsafe if you want to do pointers in C#, if that is the reason for C++ for you. The
* deref syntax is the same.
void* is there for you. They even give you an
IntPtr as a safe alternative.
The majority of Unity ECS code (C#) is in
unsafe scope and used pointers a lot. With Unity
asmdef , the
unsafe can be contained in a small scope. (C#
unsafe requires an assembly-level toggle, previously a problem since it makes your entire project unsafe. Not anymore with
Also it is possible to do
unsafe on C# Jobs system mentioned earlier to do threaded pointer gymnastics. When checking the generated Burst assembly I could say it is no different from handcrafted C++ code, so the point about "C++ for performance" is not true.
If garbage collector is the reason of C++ for you, the latest 2019.1 Unity gives you more control of GC, you can temporarily stop it. And it became incremental, whic free garbage in smaller amount but more often than before, reducing spikes.
More, if you use ECS then your data is arranged in a way that GC cannot touch in the first place. Also, Unreal have garbage collector too.
Other reason for C++ might be the C# language restrictions, like multiple inheritance. And maybe C#’s verbosity. That’s a fair point if you would like to use C++ over C# because of those. But I had already jumped on the Data Oriented Design train so OOP concept like inheritance is not of my interest any more.
For other C++ advantages, if you are C++ expert then you may know more but I am not one. So I could not recommend you any more reasons for C++.
You also have NPM-like repository for C#. Unity supports .NET Standard, if you found something .NET Standard it would be usable in Unity.
If you are a documentation freak and like to tidy up your code the way you like to make your room orderly, I think C# is good for you. The XML code documentation is verbose, but the resulting integration with intellisense, etc. is great. I enjoyed seeing the code say something back to me as I type.
You can make link to jump to other code, you can use markdown that shows up properly in some IDE, and editor like VSCode can ease the verbosity pain for example typing just /// will expand to a big XML template depending on the thing under your cursor. Then mass-refactoring works throughout the documentation too if you get them linked right.
I don’t know if in C++ it is as civilized or not.
** This article is still in-progress, as stated at the beginning. Likely will be for years. **