Any reason I would choose Unity over Unreal?

Well I've got about 8 years experience in C++ and 4 years experience in C#. I don't pretend to be an expert at C++ in fact I'd call it "scratching the surface". However I only needed a short period to start harnessing a heck of a lot of C#'s power and became around 3-4 more times productive at an estimate. Ideal for higher level code like game scripting.

I'm not sure what I'm supposed to be arguing. That is my opinion and it's not important for you to change that. It's my right to express my opinion. I didn't say "ok this is the law" for instance.

Yeah I'm all for C++ being usable, perhaps like iOS, where you can just drop a cpp file in a folder and it works somehow.

 

Well fortunately we no longer have these sorts of issues with IL2CPP.

 

I've been using C++ for 15 years and I still prefer C# and scripting languages, I'm getting old I don't need that crap any more.!

 

I've used so many freaking languages over a lifetime, and I'm an expert in none of them. I have, however, made a lot of games and other software, with whatever language worked for the job at the time. I guess I never got into the "this language is better than that" thing, because they all have pros and cons. Just use whatever works for you to make what you want to make.

 

Hear here! That's pretty much me, too. Languages are tools and should be treated as such.

I love C# for "Getting Stuff Done" without spending time on details. On the flip side, sometimes details really really matter, and in that case C++ brings some big wins to the table.

Worth noting is that if we wind back 20 or so years people were having the same conversations with other languages. I remember reading about Peter Molyneux going to a developer convention while working on Populous, and being nervous about people's reactions when they found out he was writing it in C++ instead of assembler.

 

Look, I'll explain.

I'd prefer architectures to be reasonable. That's my inner perfectionist speaking of course, because one of the "pro-il2cpp" blog posts demonstrate scheme where you would compile C# into IL, turn IL into CPP, compile CPP with clang, turning it into IR, then run IR through Emscripten to turn int into JS. That's instead of originally using CPP, skipping two conversions. Not sure how close that is to the truth those....

There were multiple posts from the past about unity not updating old version of mono and instead concentrating on IL2CPP ... and said old version of mono runtim is said to be using old Boehm GC which is less efficient.

Also, I really like to have "extra firepower" when I need it. So, when I run into some retarded C#-specific situation that could've been fixed in C++ easily, I get annoyed, especially when I look at available C# choices and don't find a proper alternative. Not having const refs is one of the annoying things I encounter. Another one is not having var that works in class declarations. Or lack of non-hidden proper typedef. Or not having protected inheritance. Or arrays and lists not having some sort of IIndexer interface or random access iterator.

 

I have been looking for a proper answer for this myself.
Since I have committed myself to Unity, but do not have a proper argument as to why.

My general impression, after doing some research from what others are experiencing,
is that Unity has more flexibility for small teams and huge selection of plugins with asset store, while Unreal has the upper hand on pure graphical fidelity (for 3D), and more utilities "in the box".

Overall, I'd recommend Unity to small teams and pioneering projects, and Unreal to teams that can deal with a larger scope in a more traditional format.

But my impression is by no means a professional one, so I'd love to hear more views on it.

 

I don't mind C#. At one time my favorite language was C back on the Amiga and then DOS days. I found it very straightforward and yet a nice step up from Assembly and not too far from AMOS and Blitz. Sure I had to write the wrapper functions to get similar high level functionality as A and B provided out of the box but that was fine.

When I switched to C++ that became my favorite language. Although it did seem like there was added bloat overall it was a great language. Moving to C# was very straightforward. I've used it for development at various jobs for the past 13 years. Yeah at first I saw it as like a "candy coated" or "toy" language but over time have come to appreciate it. I definitely had concerns about using it for game dev but working with C# and XNA put those to rest.

It is just the way things go. Faster processors come around so new languages using new paradigms are created. I suppose a C# program today probably performs as well as a C++ program did 10 years ago, a C program 20 years ago and an Assembly program 30 years ago. Sure it is irksome that performance wise we aren't making much headway. But again it is just the way it is. The focus is more on developer productivity than on code performance.

 

Why is it that exactly? You're describing art issue, not issue with the engine. Standard shader is very close to being realistic if used properly as it is now, let alone with stuff like SonicEther's GI.

 

You pretty much nailed it... except I'm not too sure on unity being 'better for smaller teams' than unreal. It's probably the same.
Where unreal excels is 3D graphical fidelity/ shaders (tree leaf skin SSS shaders for eg), optimisation, better GPU particle effect, better SSR, better integration with baked and dynamic lighting.

Yeah I used to be on the same boat until I went ahead and did some serious testing. You can tell those that have gone ahead and done serious testing with unreal or CE (e.g @neginfinity , because the reality there just is no comparison with unity at this present moment in time... In the future who knows.)

 

I'm describing issue with the engine, not art issue.

Unity has broken mixed-mode lights and start acting funny in multiple ways on larger environments with lots of objects, for example, lights moving through the environment will reveal modular structure of the environment, plus placement of light probes was royal pain in the *** last time I had to do it. You can hide those issues in top-down or isometric game, but not in a situation when you need to look at something very close.

Sonic Ether's GI won't be suitable for flashing lights (like machinegun fire), by the way.

 

Also didn't know this changed into a C# vs. C++ thread.

Anyway, IMO C# is good enough for my purposes and for most applications and games. Sure, with C++ you could squeeze out more FPS here and there, but as long as it runs at least at target framerate (which is usually 60fps), there's no need to.

I wish though that I could take control of memory management if I so desire via optional destructors and marking certain classes as "untouchable" by the GC, unless I tell them to be destroyed.

 

This really never ends, does it?

 

Then don't use them and instead use dynamic Emit materials baked with Enlighten, like PAMELA is doing?

 

people, people...

C++ pails in comparison to the appropriate assembly language for the platform. We are really talking about Microsoft has busted their tails making C# better to use for the average programmer. These ain't people trying to show they graduated magma cum volcano but just get a job done correctly without being encyclopedic.

 

I believe you have absolutely no idea what you're talking about.

You NEED mixed mode lights for decent performance. And different GI won't fix other lighting-related issues. Nevermind baking times which make enlighten useless.

 

I'm sure you forgot to mention the Illuminati in there, somewhere.

 

Please don't.... don't ruin a perfectly good conversation. Just look what you two knuckleheads started.

 

Long term software engineer here.
Interesting discussion here, I loved each meaningful post, but I think OP is missing many points here.

I love C, but I hate C++. I used a variety of languages over my work life, my favorite being Java. I built complex systems using many of them (from real time graphic processing to telemedicine), and yeah I bumped into problems (complexity brings exponentially increasing problems) in all of them. Most of the time said systems included modules written in more than one language, and marshaling was, is, and will be inevitable.

Only thing OP complains here that he wants to code in C++ but Unity does not allow it, yet. Argument is quite bad and irrelevant (I am not judging a person's personal taste in any case). In 2013, Epic Games second in chair came to GameX (A gaming convention in Turkey) to promote Unreal 4, a kid asked him if programming language was going to be C++ again. I laughed so hard everyone looked at me, and I said "What does it matter? If you call yourself a programmer, that is ¯\_(ツ)_/¯ "

My two cents here, your solution is not Unity or Unreal or anything else. What will you do when Epic Games decide to switch to a scripting language, i.e. AngelScript? Will you rest same arguments there? Or fork the engine code? Good luck with that.

Your solution is building your own engine with C++, allowing in a way scripting gameplay and levels in C++. But oh, when your team gets bigger what will you do, teach them C++? Which one? 98 standard as my old mentors did? '14 standard? My final solution, is for you to use C# wrapper for your beloved C++ code.

Look at Frictional Games (my all time favorite developers). Thomas built an engine from scratch in C++, that was HPL (Penumbra). Then expanded it more, became HPL2 (Amnesia) and then HPL3 (SOMA), and HPL4 is on the way.
Guess what? Scripting language was AngelScript. No one in the team nor modders (I'm the creator of White Night) used C++ for that.

Being technically right does not mean argument is right. Last but not least, no commercial product can make everyone happy, but a nice feasibility can make up to that.

 

Best argument for C# over C...

In C, you can do this:

for(;P("\n").R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

In C# you can't do this

for(;P("\n").R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

Okay, this was originally from the Pascal vs. C wars from way back when, but yeah... a language is a language - use the one best suited for the task or all things being equal the one you prefer. Same for game engines. The time spent arguing about it is better spent writing code.

 

I knew exactly what I was doing

 

I still like Pascal but haven't used it since I was a junior in college.

 

Used Pascal/Delphi the first 10 years of my career and loved it. It's very rare now but I'll occasionally still type := for assignment. I still hate using == for equality - makes so much more sense to have a special assignment operator rather than a special equality operator since we already had the perfectly good = for that. Not that I'm bitter. Niklaus Wirth was the Tesla of programming languages.

 

Pshh no one really gave OP the true answer.

Objectively speaking one of the main reasons you should pick Unity, is that Unity kicks Unreal's ass.

.......Any day, any time.

 

You know because the thread wasn't doomed already with a title like that.

 

Offtopic, but I'm waiting for the day when one of Ony's posts receives less than 2 likes!

 

It would've been doomed even with a better title, because it is a general section of unity forums.

Spoiler

I mean, we had a thread about programming derailed into discussing of evolution once.

 

For me, Unity is a gateway and engine which is easier to get into and work on. Regarding smaller projects for me to learn with. Then if I ever want to go larger or simply switch it up a little bit then Unreal will be my answer. But for now I'm loving unity.

 

I read that book to get familiar with C++11, I thought it was pretty good. Stroustrup's style fits me though, he often explains the why behind things even if it gets a bit windy. My brain gets very distracted when I read technical books that obviously gloss over important fundamentals(I've pretty much sworn off anything by Packt these days).

 

C# is great for the level most of us are working at with the game engine. C++ isn't horrid-bad or anything though. I wouldn't pick the engine based on one or the other.

Reasons I went with Unity: great documentation and tutorials. Can target a lot of destination platforms. It's an all around general engine that's easy to use and be productive with and on the small team level it should deliver what you need it to. Oh and the asset store is really good. There are some dogs on in the store, quite a few actually, but also some real gem assets that can make your life a lot easier.

 

I don't usually like contributing to "this vs. that" threads, simply because most of the time they turn into uncontrollable messes, but I feel like this thread is already quite off the rails, so I might as well throw my opinions into the mix. So, in attempt to try and get this topic back on the rails (even though the OP has probably abandoned train a long time ago):

(I'm going to be writing this based on my own experiences with both engines.)
There are pros and cons to each engine, but as it has been stated a few times in this thread (among all the pointless debate), both engines are suited for different kinds of projects, as well as different kinds of users.

Unity Pros:
- Unity works well for small 2D and 3D projects and for individual people or small teams.
- I personally also like the way how Unity handles its components. The way you add functionality to things just makes sense.
- Unity is also really fast to work with, and its lightweight. With Unity, you are easily able to target devices with less processing power.
- Clean UI
- Unity's 2D tools are great
- Unity is good for you if you are more programming- oriented.
- Asset Store
- Unity is royalty-free
- Friendly community
- Devs take part in the community
- Lots of learning resources

Unity Cons:
- Unity games have a negative reputation due to crappy games made just as cash-grabs etc.
- Asset Store (I have a lengthier explanation of this later)
- Unity has poor grafical fidelity out of the box (awful shadow quality, image-effects are nothing compared to some packages in the Asset Store). This doesn't mean that Unity can't make a nice looking game, however.
- Unity's shader language is extremely outdated, and is very lacking in documentation (some examples in the official docs don't even work in Unity 5) EDIT: Basic things are better documented, but more advanced things or modifying the Standard shader have to be figured out by yourself or by reading the source
- Unity's docs sometimes leave a lot untold, and there are some things that are undocumented. The Unity docs are outdated at places.
- Unity doesn't have some functionality you'd expect from a modern engine (Key bindings during runtime for example)
- Unity's implementation of FMOD doesn't have some features that come with FMOD out of the box (sound occlusion for example)
- Bad viewport performance with lots of objects or massive worlds
- The terrain system is awful, but UT is looking into an upgrade

I haven't used Unreal a lot, so I can't talk about the more in-depth features of UE, but I can talk about what I think about so far.

Unreal Pros:
- Great visual fidelity out of the box
- Cascade particles
- Blueprints (for a gentle-ish introduction to the UE API and for less programming-oriented users)
- Aimed more towards artists (Not necessarily a pro, but definitely worth mentioning)
- Visual shader editor
- BSP
- Lots of learning resources for everything except C++
- UE is updated very often, and it feels like the engine is making actual progress
- Epic makes games with Unreal Engine, so the functionality they may need with their games will become available to the users later on
- Good viewport performance
- Friendly community
- Devs take part in the community
- Documentation. UE has quite clear documentation, with lots of screenshots. Epic has also provided a project which contains interactive 'halls' that allow you to get familiar with UE's features
- Source Code access


Unreal Cons:
- Bloated UI
- As of now, the Unreal Marketplace is pretty much deserted, and has no way of browsing only free assets.
- Some things that seem simple may take longer than you think
- Can't target devices with older hardware
- From what I've heard, sharing skeletons is a pain for animated objects
- UE requires a fairly beefy machine to run
- C++ doesn't have many good learning resources (For the UE API)
- 5% Royalties after passing a certain amount of revenue


So, why did I list the Unity Asset Store as a con? This may not make much sense, but I feel like the Asset Store is slowly becoming Unity's main selling point, and it can attract some new users who decide to get a few free assets from the store, pile them together and shove the end product on Steam for easy money. This is one of the things giving games made with Unity a negative reputation.

Well, I spent way too much time on this post, let me know if I made any mistakes with the pros/cons.
Sorry for the huge wall of text

 

Yes, but it's a dark UI!

The Unity Asset store does have some real gems that the Unreal Marketplace doesn't and what little they do have can be expensive too. That said I don't believe the Unity Asset Store strictly requires you to use any assets you purchase only in Unity unless a custom license specifies it, so I tend to buy from there and use elsewhere.

Realistically though you'll want a fast processor and plenty of available memory if you want to develop more than simple mobile games otherwise you will spend a very long time baking among other things. Even more so in Unity which has far longer bake times than Unreal.

That only leaves you with needing a modest graphics card.

Yes, but you can negotiate a custom license.

 

Err.... while unity relies on CG by default (which has been abandoned by nvidia in 2012), it also supports GLSL and HLSL, which are not dated. As far as I know HLSL shaders work for both OpenGL and DirectX modes.

 

For the sake of curiosity, anyone with enough experience with Cry Engine care to give a rundown similar to the one @TheAlmightyPixel posted?

 

This. One of the Unity devs maintains a fork of the HLSL-to-GLSL converter.

https://github.com/aras-p/hlsl2glslfork

 

Oh, wait, I think I wrote similar comparison once.
Also see this.

 

I really like the minimap generator and the graphics are shiny / realtime, I don't like that it bugs out every 5 minutes and the workflow is still a PITA.

That's about it really.!

 

Oh, that I didn't know, thanks! I assume this is geared more towards larger companies? I find it hard to believe that Epic would be willing to negotiate a custom license with any indie developer who probably wouldn't make it past the $3000/quarter mark anyway.

I feel like I should add that to the UE pros list

I was in fact talking about CG here, but I guess I could add this to my OP. How much of the GLSL and HLSL learning resources online actually apply to Unity? I'm not experienced with writing shaders, so I'd like to know if "badly documented" still holds water when it comes to shaders.

 

I haven't used CE a lot, but I did fiddle around with it a little. From what I've heard and read in the past as well:

Pros
- Great visual quality out of the box
- Free with no royalties to be paid
- Visual Scripting
- In-game performance
- C++ and source access

Cons:
- No proper FBX support, you need an extra tool for importing FBX files
- CryEngine's main selling point is its visual fidelity, and it's quite hard to figure out anything else about the engine from their website
- Steep learning curve
- The documentation is lacking and outdated, but the devs are supposedly working on it
- Devs aren't taking part in the community
- Lack of learning (official) resources for most things except generic FPS games
- A lot of users have said CE to be unstable, but I personally didn't have it crash on me when using it
- Takes up loads of memory

Again, if anyone wants to correct me on something here, please do

 

Most of the non-standard stuff you need for unity shaders are here:
http://docs.unity3d.com/Manual/SL-Reference.html

Aside from that, stuff you write for unity can be pretty much indentical to a naked GLSL/HLSL shader. If you're writing a completely custom vertex/fragment shader pair, you'll need very little engine-specific information.

IF you decide to mess with lighting system, however, there will be undocumented bits. Most people don't need this.

So, basically... if you want to rewrite half of the standard shader, it is undocumented and you'll need to read shader sources (they're available for download, but they're very messy). If you want basic stuff or want to write your own shaders from scratch, all information is available for you.

 

I don't believe it's geared for any particularly sized or successful company. Their custom licensing page appears to be on a per-project basis, allows you to specify as small as one to three developers, and as new a company as one that has never published a title.

https://www.unrealengine.com/custom-licensing

 

Have years of expierience with Unity, and tried out Unreal Engine 4 for 6 months after the catastrophic Start of Unity 5.

Have to say, there are PLENTY of reasons to pick Unity over Unreal.
I'll just list the most important ones:
1) Ease of use of the engine editor: UE4 Editor is not bad, but has so many knobs and switches you sometimes have a difficult time telling what exactly you are changing now, if you don't already know... which leads me directly to point #2
2) Quality of documentation: UE4 Documentation is there, and most of the Stuff IS documented (and there is plenty of undocumented Stuff in Unitys documentation too)... but the indexing of it seems very weird to me. Had difficulty finding the relevant pieces, had to ask on the forum and wait for someone to give me a direct link to the correct page. Also, with Blueprint and C++ UE4 Systems being way more different than Unitys C# vs JS API, there is a lot of confusion with most things only being documented for Blueprint. Good luck finding the exact same doc for C++...
3) Unity Asset store: UE4 also has an asset store, but it is... kinda dead. You find some 3D Assets, about 1-2 shader systems, some animations. Thats it.
Contrast that to Unitys asset store which provides you with systems to transform the sometimes dated out-of-the-box systems into something usable, sometimes even pretty advanced.
Yes, the out-of-the-box systems of Unreal are often better. But getting the same quality as with some of the thirdparty assets sold in the Unity store (like RTP) in Unreal means you need to go above and beyond what you get out of the box and start developing your own shaders, maybe even start changing the terrain system source code.
4) That might be just me, but I HATE that Blueprint system with a passion. I just find doing things the visal-scripting-way to be way less efficient FOR ME. Now, having choices is always good... only that UE4 kinda only supports you if you pick the Blueprint way of doing things. Documentation is clearly geared in this direction, so is the editor.
Of course you can program everything in C++, even change the editor source to loose some of the Blueprint centric aspects... but you are pretty much on your own by then. Oftentimes I had troubles finding C++ documentation on topics that were quite welldocumented for Blueprint.

Of course there are plenty of points why to pick Unreal over Unity. Horses for courses I guess.
The good thing is that both engines are now free to download and use, feature complete! So nobody is really stopping you from downloading both and trying out which engine suits you better.

 

Speaking of which, actual scene editor (window with transform gizmos and stuff) in unity is just plain horrible. Unreal engine has better transform widgets/controls within their scene editor and performs much better on large number of objects.

 

Hm, why would you say that? I haven't found a big difference in that aspect. Don't get me wrong, nothing was broken with the gizmos in the UE4 editor... but I also didn't found anything lacking in the Unity Editor.

If there is anything annoying about the scene view in Unity, its that the isometric perspective was totally broken in the Unity 4 days and you had no good tool to work in non-perspective mode to exactly align Stuff... A real pain when you try to fit colliders exactly to visual meshes.
No idea if that was fixed for Unity 5... knowing Unity, most probably not. But before I b*tch and moan more about old problems from the Unity 4 days, probably got to check that first

 

• Abysmal performance when selecting large number of objects (as in hundred or several). Depending on number of objects editor may freeze for a dozen seconds in order to repaint selectable objects. Unreal 4 definitely does not have this problem.
• Dragging object into scene always spawns it at some very random coordinates. (that seriously annoys me).
• Working with UI in a 3d scene is a pain. 2D ui exists in the same scene as 3d one AND 2d canvas blocks 3d objects from being picked.
• Workflow is too mouse-centric, there are no hotkeys to restrict movement to an axis, and gizmos are very small. For example it is extremely easy to misclick rotational gizmo and instead of x/y/z axis start dragging "rotate in camera space" circle.
• No visble grid in viewport.
• Grid settings are tucked away and are inaccessible in viewport.

This kind of thing. Basically, scene view is very close to being unusable, and most of the work has to be done within hierarchy/inspector instead.

 

Oh, I can relate to the randomized spawning... highly irritating. Also the UI thing, though I don't know how fond I should be of Unreals System. When I tried it, the resolution grid shown in the UI editor was quite off somehow, had to try and error it.


About the mouse centric Workflow. I found a Space Navigator really improves the way you navigate in the Unity viewport. Found it the only way how the Unity scene view was navigatable for a large world.
its 100$, but given how useful it is for working in 3D apps like Blender, some of the best 100 quids I spent.

On the other hand there is no Space Navigator Plugin for the UE4 Editor, yet navigation with the mouse is just as broken (well, navigating a 3D space with a mouse is ALWAYS broken). You can understand my disappointment finding that out and reading pages after pages of other devs complaining about to Epic with not real official statement on it.

Space Navigator Support for 3D apps and Game Engines should be a given in 2016.... oh, and 3DConnexion should get some competition, to drive thos insane hardware prices down!

 

CryEngine, starts with a "C". "C" comes before "U" in the alphabet. All of the most famous and powerfully elite programming languages also start with the letter "C". Those languages are particularly compelling for enterprising game developers working on open world MMOs, for the record. Interesting. But I digress.

CryEngine is clearly your best bet. [...although the cry in cryengine makes you want to cry when you use it...]

Now brudders pleaze givez me 15 likes.

 

It also supports C# now which I'd consider a Pro.

- FBX is supported now (at least according to Documentation, which was updated June 15)
- Documentation is getting better every week it seems. This used to be a big negative against Cry Engine but they have been working on it.
- They are actually pretty active in the CryEngine Slack, but the forums themselves are pretty barren from both users and devs.
- They've actually got some pretty good workflow / engine basic video tutorials. You won't find anything like Unity's Roll-A-Ball or Roguelike tutorials though, which is a shame.[/QUOTE]

 

Don't know about that, space navigation in blender worked fine for me, also positioning things was order of magnitude faster than in unity (and UE), because of hotkeys. Basically, pressing x/y/z restricts movement/rotation/scale to that axis, pressing it multiple times will toggle restriction between local space, global space, screen space, and you can just plain type values in from the keyboard. So you can type something like "s 2 x" which will scale object twice on x axis. It is ridicuilously fast once you get used to it.