considering a switch to Unity3D from unreal

so, ive been using unreal the past few months and im considering a switch to unity.. i like the way scripts are more modular and organized, even though i could do the same in UE4, it seems better organized on unity.. there seems to be more free assets, tutorials, and a better business model while graphics comparing two games between the two engines in the same genre done equally as well seem to provide equal results and i think with unitys new open rendering available in the current beta that unity3d will be able to do anything unreal can

some questions though.. i understand both unreals blueprints and C# used in unity are roughly 1/10th the speed of C++ scripts, and that C++ scripts are always going to be faster, but realistically how noticeable is this going to be and what sort of games would have a noticeable effect using C++?.. and with unity seemingly more adept at breaking up C# scripts into individual, somewhat modular functions, how much easier would it be to rewrite a C# script (say for a simple stamina drain or regen system) to a C++ script in unity than rewriting whole commented sections or functions of UE4 blueprints into C++?

 

Not all C# is compiled equally some C# project targets in Unity get compiled to native code, some get assembled to .Net code which is then compiled on the target hardware.

Also it varies depending on code and compilation technique from C# being faster to it being about 2-3x as slow.

Good article on C++ vs C# -> https://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET

There is also the new Job System (in Beta) that facilitates making multi-threaded code and once the Burst Compiler/Assembler is brought online it will convert C# code to native 'hand coded assembly' optimised for the target platform.

C# is very similar in syntax to C++ so you might be able to find a code translator or make one yourself using regular expressions.

You might find that Unity has less of a game framework API than Unreal so you might need to do more coding yourself. e.g. Unreals FPS game engine background.

 

Not 1/10th. You can get that writing mathematics-heavy code in Python, without C plugins, but not C# at least

Blueprints may have much lower performance than C++, but if it's used correctly it's still fast enough (glue code, occasional changes, initiating subsystems which are in the native portion of the engine). But Unreal also has "nativized BPs" which have far better performance. Context switches between BP systems and the rest of the engine can still cost time (or really latency/response time) in speed-sensitive cases, but not nearly as bad.

C# was reported to be within 80% of C++ code a number of years ago (by an employee of Unity Technologies), so it's far from awful. The JIT code is even better now. With IL2CPP producing native code, the main cost is again context switches, and the deeper the compiled code goes the less there are of those. Just write sensible code which does its thing in as little time as possible if it has to run every frame.

You wouldn't want to or need to rewrite something without measuring if there really is a speed hit first (or when you start to notice batteries dying faster, if targeting mobile). Profile everything, and consider other ways to write it, then consider writing native code if you can't get it to perform well. This applies to any engine.

 

C++ won't always be faster because it's not just the compiler that determines performance. A skilled C# programmer can very easily write code that is superior to that of an unskilled C++ programmer. Switching to a faster language will only get you so far.

 

And is also unsafe c# and .net 7.* and compiler improvements going on with UT that bridges the gap to c++ performance for gamecode and less gc, without all the headaches of having to write it with c++.

I would only consider UE for a game with a team > just me. Otherwise UT is far better all around really.

 

I believe the performance is not a critical difference from the choices of language.
If you are extremely serious about performance, you can pay for source code access license to kitchen your compile to remove build-in modules such as analytics and thin your build as much as possible.

 

obviously, but i was comparing all else being equal, equal coding skill, similar tasks being coded, etc.. but i did read recently that what can slow down C# and blueprints is when they actually have to talk to C++ and translate the code, that it might be better to code a larger amount of the code in C# when interracting with other C# or blueprints scripts than to mix and match a bunch of C# scripts with C++ scripts, but im not sure if this is true.. i could very well just be overthinking the performance hit, and my targeted platform is PC with no interest in mobile devices

 

GC is probably one thing which gives performance hit in C#, I believe Unity is doing it better and better.

 

Even if your target was mobile, the performance hit would be so small that the entire concept is basically a microoptimisation. There's really nothing to worry about on that front.

 

I vastly prefer being able to easily see my code line by line compared to the inevitable spaghetti of visual scripting. Side note: I wouldn't have thought the phrase "inevitable spaghetti" had been used much before, but Google shows 251 results. Hmm. Well now there can be 252.

Regarding switching engines: As much as I have given strong thought to switching over to Unreal Engine several times now, I always end up sticking with Unity. I know I could use C++ in UE instead of blueprints, but I also enjoy the speed of writing 3 lines in C# to writing 10 lines to do the same thing in C++.

As far as whether the speed of the code is different between engines, it totally depends on what you're doing with it. Unless you're an expert code manipulator/optimizer, I don't think it's going to even be an issue. Check out some of the bigger games made with Unity, and see if they meet your speed expectations. If so, then there you go.

 

Managed code vs C++ is not just a one is always better. This is a really good video on the topic.

https://www.infoq.com/presentations/performance-managed-languages

 

For most games, most of the time, script performance won't be your major bottleneck. High level optimisations are pretty straight forward, and can normally fix most script performance issues.

 

i notice people fairly new to blueprints do end up with a massive spaghetti mess of tangled and convoluted "wires" pointing to every direction, but thats mostly from people who do not understand how to organize it by creating custom functions or custom events to point to another piece of text later on in the code

for example, some of the coding i did had jumping decrease stamina, and sprinting as well, unorganized, you would have to individual write (or copy paste) the whole stamina regen segment to both strings of visual script or drag wires across the screen from both of them to the same regen segment, just as an example, but i set up the 5 second delay and regen phase to a custom event that is called by the above two events at the end, so no convoluted tangled mess of wires

im curious though that outside of preferring C#, which i dont mind at all either, why were you considering going to unreal?

 

Yeah I've seen some pretty crazy looking blueprint setups, and from what I read it's pretty much a given that you're going to end up with some spaghetti the larger the project gets. I'm sure someone who enjoys visual scripting could make it all work, but I'm less of a visual person when it comes to code.

I tried out Playmaker (visual scripting for Unity) in the last game we made, to see if visual scripting was better for me. Although it made things quicker to prototype, I ended up moving most of it to code anyway because it got too convoluted. So yeah, depends on the person, of course, but for me I'm not so into it.

Been using Unity since 2009 and would like a change simply for the change. Different work flows yield different challenges, and different challenges yield more creativity, for me at least. I'm also getting really frustrated with the direction the store and other things are going.

Just started working on a new game which is heavy in environments, and thought maybe Unreal would be the one this time, but again, it makes more sense for me to stick with Unity rather than learn an entire new system. And honestly, reading what people have said about Blueprints, it kind of turned me away from Unreal. I just don't work well with visual scripting. I am still on the fence, though, and tempted to switch over just to see how it all pans out.

 

Post-processing always makes the other engine look a shade greener.

 

what direction has the store taken recently?

 

The have been changing it and it's no where near as good as the old store. There have been a number of threads about how bad it is. They did the same thing with the job forum here. There used to be a section of the forum where one could easily find projects to work on or find people to work on projects. It worked great. They removed it and created Unity Connect to take its place, and, uhm, yeah, again, there are a number of threads about how bad that is.

Basically, I wish they would stop changing useful things just for the sake of changing them. As a long time user it just gets frustrating. Change is good. Bad change is... not.

 

Not always.

If you're using C# hashmap and it is slower std::unordered_map, then being more skilled won't help you.

I hit this kind of problem before.

To the OP:

C# scripts are going to be faster than unreal blueprints. For majority of projects you do not need supreme performance anyway, given the power of modern hardware.

 

Upcoming Unity versions allow you do write the fast code by default in C#. Their new compiler technology "Burst", generates even faster code than current C++ compilers, according to Unity.

What seems to have even a more significant affect on performance is making use of all available CPU cores, which now is possible due to the C# Job system.

https://unity3d.com/performance-by-default

 

well, the current CEO of unity was fired in complete disgrace from electronic arts, after changes to the company much of which shafted the consumer to try to squeeze more money on them (incomplete games like mass effect 3, selling parts of the game separately as DLC to charge more, online pass, etc) causing EA stock to crash by 70%.. so if unity is making unpopular changes that are pushing people away i wouldnt be surprised... heck, im quite disappointed to see their business model has changed from a one time cost of like $1,500 to now a subscription that costs an individual $1,500 per year.. im not sure how i feel about that compared to UE4s 5% royalties, but the $1500 one time fee was highly attractive

 

ive heard people claim blueprints are faster, ive heard some claim C# is faster, and i havent really seen much evidence to support either claim though.. but ive used a bit of both, i like both, they both have their pros and cons

 

Subscriptions are highly attractive too. Perpetual licenses encourage companies to hold off on releasing new functionality until it's time for the next major release. Essentially they're holding the functionality hostage. An excellent example of this is Microsoft Windows. Want DirectX 10? Buy Vista. Want DirectX 12? Buy Windows 10.

With a subscription license you're no longer waiting months or even years for new functionality.

 

Indeed, they will end up a mess if lack of "blueprint"(including myself).
Usually people said visual scripting is for those who can't code, I would said visual scripting is for object-oriented design experts.
It is useful for people who already has UML diagrams on their hands, and "migrate" the implementation.

 

Yeah, like the terrain system and [insert list of other feature memes here]. Oh... wait.

 

Unity 5 had major functionality that could likely have been made available earlier during Unity 4.

https://unity3d.com/unity/whats-new/unity-5.0

 

alright, well im interested to see the next release thats supposed to really open up its graphic capabilities.. unfortunately though the open beta would not work on my computer as i got a white, sometimes black screen where the menus wouldnt work either, so i never got the try the beta

 

hmm.. been working in unity3D today to give it a better try and although i do not mind the C# scripting itself, i really do not like either of the two options i get when it comes to scripting.. visual basic is in my opinion, over bloated junkware and monodevelop isnt exactly leaps and bounds above it.. i really like how blueprints is completely integrated

 

Try using Notepad++. You can actually use any editor you like, and have the Unity editor automatically open it up when you want to create/edit scripts.

 

If you want a solution that is integrated into the editor check out Script Inspector 3.

https://assetstore.unity.com/packages/tools/visual-scripting/script-inspector-3-3535

Visual Studio is one of those things you only appreciate when you're making repeated use of its advanced features or started from a time period when little else was better let alone affordable and that's saying quite a bit considering old school Visual Studio was thousands of dollars (but then engines were hundreds of thousands back then too).

You absolutely need a solid state drive these days to use it though. It's simply too heavy to run off of a hard drive.

 

As someone who has used many, game engines..... and experience....much more....I been using UDK, Unreal since the early days..Unity for 9 + years..... CRY and many, many in house engines...The issue with Unity, NO SOURCE code...which is a huge problem...Also for the most basic stuff you either have to spend a ton of time updating assets, tools you made....or buy them, and have to worry about the developer updating...and making quality assets....Unity I own hundreds of assets many for basic stuff, I also made about 13 or so tools through the years to maintain....... Unreal I own ZERO assets and used much longer years wise..... So they both have pros and cons.....Unreal you won't have to worry about buying assets......for the most basic stuff....

Unity, you have more people to find that know Unity....Sadly in the indie market Unreal its harder to find a experienced, user for Unreal in the indie market...that is good at the engine in general... Unity its much much easier to find others to help....Now I heard someone say Unreal is a team engine....I disagree 100% it boils down to learning the engine..If you learn Unreal, you won't have much of an issue if you ever worked for some other team,AA, indie or even AAA.....Since every time I have to use a new engine in house....Its easier for me to learn, due to knowing Unreal, Cry etc... They are more of a game engine....Not to bash Unity, just telling the truth.....Unity DOES not make games....Unreal , does...So that right there is a huge issue...I found through the years, many assets ARE NOT tested in a real game, through for , many are failed when it comes to actually releasing...Also Unity many users do not release, larger games, they release mobile or smaller scale games....which is fine....But not when it comes to some of these larger games, which can be done and has.....But do not expect to reply on many assets, you WILL have to make many BASIC functions your self, for nearly everything...Unity is missing so many basic functions compared to a GAME ENGINE, such as ones I mentioned, makes it inferior in many ways....Do I like Unity sure for mobile and smaller games..and yes easier to find a team when you do indie .....etc...games. In closing, I prefer Unreal....due to it being an actually game engine... at the end of the day, your game, and bank account will be alot more happy about it....plus your users...... Right now making a game in Unity a very large game....and have real experience seeing many issues with Unity... as I made others...

Unity is easier to learn which is why so many go to it.....But if your going to be a game developer....for a living, I suggest to learn other engines as well as Unity...Then pick THE best one for your team........I went with Unity for this game due to the team I was working with.....which I stated why this happens... but it boils down to experience of your self , the team if you have one.....Unreal many games are made solo...and can be..... for basic tools you do not have to make them like you do in Unity..Which saves alot of time......Using C++ vs C# boils DOWN to your experience, of how well you know each one....period.......Many engines use C++ for a reason.... not bashing C# as I like it....but I prefer C++.

 

I been using VS for years and in Unreal it works fine.. but I also use Script Inspector 3 in Unity, I believe is the name and opens scripts right away..and easy to use, I love it in Unity as my IDE and suggest it to anyone that uses Unity and dislikes VS... I like VS but not in Unity....its slow compared to SI3.

PS: The terrain in Unity is old and crap......biggest reason Unity upsets me and many others..

 

Insert random horrifically biased reply, followed by general quasi metaphysical philosophical advice about choice.

 

script inspector 3 isnt something i am willing to spend money on just for test driving an engine though.. and something that i am noticing about unity is that a lot of these tools that should be part of the core functionality of the engine seem to be only available separately as a separate purchase.. clearly these are tools created by third party individuals, so unity cant simply implement them specifically, but why hasnt this, and other tools been developed as part of the engine?

what i like about unreal is pretty much everything i need is part of the engine, and when it comes to 3D modeling and animation theyre putting a lot of support behind better integration with blender to provide that for free also

 

Choice of engine should always be about it meeting your needs and from the sounds of it UE4 is the one for you.

 

And lots of ellipses...

 

Word on forums is that Unity have smart people working on the terrain now... though they have been trolling us about nested prefabs for some time now.

visual basic? maybe you are talking about visual studio? still that sentence doesn't compute for me. Anyway did anyone else ever think the whole 'dim' thing in visual basic was like taking the piss out of the users who used it for coding? dim .. I mean look it up "dim+dictionary"

I always thought it was a S***ty language.. I've replaced my forgotten distaste for it with js, typescrap, python etc all these newer overpopular S***ty language designs.

you were saying all the right things up until that last bit... I don't think anyone is meant to prefer C++ ...even if you are an expert at using it for better memory and performance reasons...that's just a skill to have for a job...loathing an ancient mess of a language that has too much legacy sht to keep running while all the newer crap bolted onto just further adds to the complication I mean job security of those who suffer the years of headaches in using it. I wonder if C## could be it's replacement so long as its not designed by js/typescrap language kinda people.

They do seem to get it now.. give them like a year or so and so and so etc. for integration and features to look and work better. Or just go back to UE and enjoy those weird blueprint things because you're not taking engine ship jumping more seriously

That's great.. if only blender could put a lot of support behind better making their UX and design less garbage. I mean it's not zbrush bad, but its pretty close. I think I'm waiting for the day when a bunch engineers pref Maya team quit Autowreck and go work on a crowd funded Blendaya fork ...it could be great maybe.

 

At that level of experience, what you're using doesn't matter.

This depends on your architecture, not the engine. IMO you're already falling into preoptimization and wasting everyone's time, including your own.

Just get to work, put your mind into it and get results.

 

I don't understand this, could you give some examples about what is missing?

 

Kitchen sinks.. that sorta thing.. I didn't read it all actually but it's definitely missing things.

 

LOL Functions are already overwhelming in Unity, only your game is missing.

 

im not working on any game, just coding various mechanics to gameplay, testing and learning AI as well, just basic stuff.. im not even remotely artistic so i wouldnt be all that good with creating good textures or effects, and do not have anybody to help, or a solid game idea to go with right now, so at this point its just hobby/learning

 

Matlab could be an alternative, its really rich in libraries for such objective.

Hobbyist, you are welcome

 

This is double edged. Epic develops only features they need for their games because they do not have unlimited resources like Unity but Unity has so the chance to take a more systematic approach.

 

i need to do some more testing in unity3d first and try out some alternatives to visual studio and unitys version, perhaps a good open source option is out there.. i dont know.. it could just be unfamiliarity with the system but i have found it easier to add new characters and set up animations and parameters for those animations in unreal

 

The Unity editor is very extensible and normally workflows can be improved by creating simple extensions here and there. I believe that's "The Unity way™", or how I work with it. If something is missing or weird to use, I often fix it via editor-scripting.

If you find things that are better to do in Unreal, you could write such editor tool for Unity to fix that and even sell it in the Unity Asset Store.

Spoiler: Unite 2013 - Advanced Editor Scripting

Spoiler: Unite Europe 2016 - Editor Scripting for n00bs

 

It's very likely Unity is the most capable game engine on the planet due to serving so many beginners for so long. Rumour has it that Frostbite Engine, an engine that's really fast, good looking and popular does very little. And that's why it's so fast.

Whatever is missing from Unity probably is called Competence. People can find it between the chair and keyboard.

 

yeah, and thats how we get paid

 

Epic has basic features for any game.......its a game engine, as Cry..I have used many In house who do also make what is needed for there own games, which is common but they have basic stuff needed to make ANY game.....Unity DOES NOT......Unity DOES not have unlimited resources, I disagree, how many larger games have you made with Unity.?? I have...You end up spending much of your time, fixing, the most basic things, that you should have with ANY game engine..... So after 20
+ years in this field, and 9 years of Unity and many more with Unreal, Cry, INHOUSE, I would respectfully disagree..... Unity slightly now a day has more tutorials , BUT many are , not good and wrong information... but as I said all engines have pros and cons as I stated before.....but until you use MANY engines, which many Unity users have never made any game, or used any other engine, other than for a month and decided it doesn't hold there hand.....WELCOME to game development.....we work for a living...

 

Go use other engines, for 3-6 months, use Unreal, make a game, go make one with Cry, Sting ray, and so on...The list will stack, talk to most experienced developers who made games.... and I mean larger games...not a tiny mobile game... Unity shines with smaller mobile games..

 

Thank for your suggestion, could you give me some more details? related to architecture? or related to work flow? Truly want to know what is lacking here.