Looking for Opinions on BluePrints vs Unity's alternative

Good day everyone

I am looking for some opinions on UE4's blueprints vs either Unity's C# or the visual scripting alternative available in Unity.

I am not really concerned about advanced lighting because looking at escape from tarkov designed in Unity 5 it seems to be that Unity 5 is a damn fine Engine capable of next gen AAA quality.

I personally am not seeing a very huge difference between UE4 and Unity 5 in terms of graphics. But would prefer to have opinions from folks here who have used both.

I am in the process of gathering all my ideas on a game I want to make, its an ARPG similar to Path of Exile and Grim Dawn I have the idea but have not figured out a name as yet. Opinions on this are welcomed on which engine would be a good choice. I also had another idea for a platformer which would likely be much easier to develop especially for mobile

From my understanding the C++ used in UE4 is as easy as C# in Unity as there is no memory management etc to deal with these days. But would be more interested in its Blueprints it looks rather interesting.

 

UE4 C++ is still far from C# in general and especially when compared to component based approach used in Unity. If you have basic programming experience then code is the best way to go in both. Since UE4 is free I would suggest trying it out to and prototype something with blueprints and then see if you actually want to do a whole game with them in the end. Unity does not yet come with visual scripting and it's unknown when it will be ready, if ever. Asset store has many of them however, free and paid. Remember that visual scripting will mostly lock your code/logic to that engine and is generally not that useful in the programming world where as coding skills are helpful in multiple things.

 

It goes like this:

C++ used in UE4 is significantly harder than C# in unity, because C++ is more complex langauge (despite unreal team's numerous attempts (many of them successful) to make programmer's life easier), and because C++ in Unreal 4 is poorly documented. If you're going to use C++ in unreal 4, you'll need a skilled programmer that can dive into unreal's code to figure something out. Newbies need not to apply, pretty much. In general I prefer C++ to C#, but I wouldn't recommend to use C++ in UE4 to someone new. It'll just kill their project.

Unreal 4 offers better visual quality out of the box than unity, due to preconfigured postporcess filters and slightly differeent PBR rendering model (reflective surfaces look better). Unity also has long standing bug where you can't really mix baked and dynamic shadows properly. Unreal 4 does not have this issue.

Unity also doesn't include any visual programming tool by default, although there are several solutions on the asset store.

In general, if you're familiar with programming, using code for game logic is a better idea than using visual programming tools, because code is more compact and easier to read than node networks. Unity also may be a preferred choice if you are going to need highly customized shaders (for example, if you want to render objects by raytracing), because unreal's shading model is harder to experiment with.

Basically, if you want nodes, then UE4 is a better choice.
If you want to tinker in code, then Unity would be a better choice.
Unreal 4 has steper learning curve.
Unity has a higher chance of running into some horrible bug 6 months into development of your project.
I'd say that Unity is more suitable for prototyping and 2d, while Unreal is better choice for 3d/high-fidelity project especially if you have some serious funding.

 

Lots of relevant stuff in this thread:
http://forum-old.unity3d.com/threads/might-have-bitten-off-more-than-i-can-chew.411321/

 

I think it is also worth mentioning that (if you get to that point) both Crytek and Epic offer indie grants to developers.

 

Yes, but the funding isn't anything particularly impressive. Epic's latest grants are only $20K on the high end.

 

And zero guarantee you'll be seeing any of it.

 

Gotta agree with @neginfinity

For a POE style game, Unity would be the far simpler and quicker choice. Not that you couldn't do it in both..

 

Yes and it's also more complicated and less intuitive out of the box, compared Unity.

 

Just look on the bright side though. It's a much smaller download for those with terrible Internet.

 

Thanks @neginfinity and others who helped on this thread.

So I am quite new to programming I do it as a hobby. As you guys have said Unity would be a better choice for a path of exile style game. I am also considering switching to a FPS project instead but I am not sure if it would be worth anyone's time to download and play considering the kind of free games there are out there such as Evolve Stage 2 etc

One of my reasons for a POE / Diablo style ARPG is because its a niche market and I would probably have a better chance at selling it cheap for maybe $5 or less if I had to.

 

Suggest developing something small in both - whatever you think is a small game - check Unity Learn section and Unreal learn and develop a couple small games.
That should give you the knowledge you need to proceed with whichever engine you like best.

OR you might find a variable that steers your decision to one particular engine over another. Myself - as an artist who is all about the visuals, you'd think I would naturally gravitate towards UE because of there demos and blueprints, however the component based design of Unity AND the community here - compared to over there - really made me feel like I could get more done as a lone wolf, and could get help whenever needed without getting immature remarks from - less respectful developers.
And check out Playmaker or any of the other FSM / visual scripting tools that are available for Unity.

 

Careful... This simply isn't truth, though is gospel... Even in C#, dangling references can become a memory leak.

 

Just watched a "getting started with Unreal" video where a guy made a spiral staircase and had a completely operational FPS available with starter assets, I didn't see him F***ing around with anything trivial. Lots of interface buttons for common tasks. Seems to have been designed with making games in mind, I must wonder if this mindset extends deeper into the engine and interface.

I never really talk bad about Unity. But it almost makes me wonder why you have to invest $300-$500 in Assets before it becomes usable?

Just started up Unreal for the first time and... honestly, the real time shadows on geometry, kind of make me giddy.
Looking back at the Unity shadows and I'm kind of like...



Pretty much, in a nutshell... what I gather is that Unreal is better in every way... the reason people have a hard time with it is that... C++ is hard?

Cause you know... programming is hard...
for people who don't... program...

 

^ well I get where you are coming from. I downloaded UE4 and I am trying both UE4 and Unity. The thing about Unity is the community here is much bigger and much more helpful. Lots of questions on Unreal forums go unanswered. Infact I have noticed lots of questions about game design are answered by EPIC engine developers.

It looks like EPIC staff is trying to fill the role of the smaller community don't get me wrong I really admire the epic staff they are quite down to earth but there is no replacement for Unity community.

I am doing the tutorials on both engines I will give a feedback when I have an actual completed don't want to give any feedback at all until I have a fully functioning game out the door. But I will agree with you, the demo projects given out by EPIC is really amazing. Its crazy what UE4 can actually do.

If you have never seen this video you should now, it shows the monster that UE4 really is and yes thats all full ingame graphics.

 

Death Wing is going to be the first game in a very long time that I will pre order for $60 gameplay looks amazing

 

...well at some level people are expected to become self-sufficient and not reliant upon hand-holding and spoon-feeding. And if you keep at this long enough you'll know what that feels like. And then you'll look at those simple questions and... just shake your head.

 

Well Unreal comes out the box with a game framework for most common tasks in pretty much any 3D game.

It has so many systems designed for 3D games (destruction, AI, widgets, IK, Root Motion, State Machines (including BTFST AI systems, also enviro queries (AI sub-system), Vector boundary streaming systems, automatic texture pooling, automatic instancing, automatic occlusion, GPGPU particles, Physx simulations (including Apex destruction and full cloth) w/ ragdoll, instanced workflow (mat's / geometry etc.), full cinematics system, complete sculptable terrain system with boundary vector streaming, shared derived data caching, material editor, multiple scripting systems (Skookum for e.g.) a platitude of content examples showing you how to make AAA MP games.. Etc. etc.

I'm not even scratching the surface of the workflow tools and systems it has and I've not even mentioned all the graphics tech above, but knowing how to put it all together does take ample amounts of time to learn.. Although it's fair bit quicker than making it yourself.

So in short yes, it is made with making 3D games in mind.. Although the 2D system from what I've heard is getting somewhere.

In terms of asset store "stuff".. Here's what I generally use with Unity, just to save me a boat load of time if nothing else.. Doesn't make it any more "useable" but it sure makes things much quicker.

- Final IK $90
- Scion $60
- Shaderforge (or / and alloy) $125
- Terrain stitcher / WM import system (all I need personally, easy to do but meh only a couple of bucks) $5.00
- Tenkoku $65 (as you can make a TOD system in Unreal in about 15 BP's (based off in-built), easier to buy in Unity)
- Rain AI (free)
- Cinema Editor (for cutscenes) $60.00
- Easyroads (or some spline altenative) $45.00
- Vertex / mesh paint tool $10.00?
- Decent erosion brush $25.00
- Apex equivalent $60.00
- Some sort of game "framework" equivalent $100.00?
- Sunshine for shadows? Whatever that costs..

So yeah, I'd say about $800.00 - $1000.00 or so??!

C++ in Unreal (even with GC and Mem allocation) ain't as simple as C# that's for sure, but I don't find it that much harder than Unity's scripting system.. I do use Skookum and BP's for a lot of higher level stuff anyway, so I couldn't really care less. It's only intensive systems I use it..

Honestly I've spend years with both, I can make them both sing and dance at this point and the hardest choice is deciding what would save you the most amount of time. Or money (potentially)?!

I don't really have a preference.

 

^ I would assume UE4 saves you the most money since it comes with $1000 Unity Assets for Free?

 

Hmm... interesting.

I actually get frustrated easily when things don't have a "right" way. One of the things that has rather annoyed me in Unity is just how much there is "no right way" to do anything, it's very "willy nilly". Everybody gets to do it however they like and nobody is much concerned with valuations of techniques, merits of different approaches, or anything to that effect. Unless you have a similar personality, it is unlikely that you will know what I mean in regards to this particular annoyance.

I think my first post on the forums was to the effect of "why does it seem there is no comprehensive guide about how to do things". Unreal doesn't seem to have that problem. If anything, it looks like you are directed toward a certain way of doing things.

What's interesting is that, at this point, I need to create a large industrial complex full of inter-connected rooms. The areas have to be loaded into memory and released from memory as you traverse the facility, as it will be larger than what can be loaded into memory at any given time. I find myself irritated in Unity because for some reason it doesn't feel like it was designed for this purpose of making modular 3D environments. Sure, if you hold CTRL you can snap but Unreal has this super-imposed grid.

I don't know, but I think Unreal will actually be faster for me.

Plus that visual scripting blueprint stuff looks fun to play with, removes some of the complexity of doing basic tasks since they're already pretty much ready to roll. Probably help with some of the fatigue, rather than staring at code 24/7.

OP to me this is my story so far... RPGMaker -> GameMaker -> Unity. Now it seems like Unreal is next. So maybe that helps answer your question.

 

I couldn't get Visual Studio to run properly and every one of my half hearted attempts to learn C++ so far has failed. So yeah, C# and Monodevelop originally brought me here. No regrets .
During the "Lithium incident" I looked at Unreal again with focus on blueprints and it seems like I have a hard time "reading" blueprints. I didn't try for long though. I was interested in starting a retro pixelart 2D game as a sideproject and I quickly felt UE4 is just the wrong tool for that.

 

^So if I am to understand this, Unity is easy because of C#. UE4 hard because of C++. However in reality unless you are spending $1000 US on assets for frameworks etc to actually do all of that from scratch in Unity you would in reality learn C++ quicker for UE4 and have those $1000 in assets Free?

so its not really easier and faster to get your work done in Unity really?

 

You don't strictly need any of those assets to create games in Unity. If you ask me that list seems to be more about achieving feature parity with UE4 than actually getting a game made. If you are targeting mobile or developing a more modest desktop or console title you shouldn't need most of them.

If you need feature parity with UE4 than you should just use it. Pick the best engine for the project and all that.

 

^ i see very good advice there.

 

Wrong. Unreal is harder because it has more features. If you want equivalent features in unity, you'll have to pay. On other hand unity has few features that are not present in unreal 4. Also I wouldn't say that "unity is easy because of C#".

In the end, there is no perfect engine. Just try both engines and see which one works for you.

 

You know because you totally have to use those features.

 

If you don't know how to make a game and you don't know how to program, figuring out which engine gives you the best toolkit for high end games might really be overkill.

Adding visual polish raises expectations, if youre new to game dev you will, absolutely, be unable to meet those expectations for quite a long time.

Making a half decent mid sized game is really friggin hard man, don't underestimate it.

 

Look at code of ACharacterController and compare it to unity's ThirdPersonController, you'll see what I'm talking about.

More features -> more complex architecture -> more stuff to learn -> steeper learning curve.

 

My expierience with Blueprint: horrible. Really.

The UE4 Material Editor is cool. There is Shaderforge in Unity that brings similar functionality, but its not free.

Blueprint editor for scripting was really a drag for me.

1) No ctrl-c, ctrl-v.
Yes, copy-pasta is often not the pinnacle of software development. But it works for quickly copying someone else solution and integrating it into your own code. With Blueprint, you are left with an image you need to rebuild as Blueprint script. As soon as this is more than 2-3 nodes, productivity compared to code is slowing down considerably.

2) Node names do not match the names in the context menu.
This is a nobrainer... no, Epic, its not okay to expect me to have the API documentation open for EVERY node I am planning to insert until I memorized TWO different names for each node.
This is especially annoying combined with point number 1. I now have to have the image of the node system open I want to copy, the API documentation to get the right menu name of the nodes shown. And then manually drag and drop all the nodes in. Compared to two hotkeys and changing windows, that is a lot of unneeded hassle.

3) As soon as the script get complex, readability is down.
Every tried to build a big complex node system in a flowchart based Visual scripting editor like Blueprint? Its not pretty.
Yes, Macros can help. But that is just leading to the point where you are again working with "multiple files". Need to look up what is going on in that function/macro? Switch levels to that macro, and loose sight of the overarching script.
Not much different to classes spanning multiple files in code, is it?

That is of course subjective, but I prefer reading clean code over having to look at a node system for complex code.

4) Epic dropped the ball on keeping the C++ and Blueprint API and documentation in sync.
Leading to the result where you either where already knowledgeable in C++ for Unreal Engine, or you had to search double as hard to find documentation for C++. Because everything is documented for Blueprint first and foremost.


Don't get me wrong, Unreal Engine 4 is really great. If you happen to like Blueprint, or are already fluent in C++ for Unreal Engine. Else you will have a hard time getting into the engine.
This is were I really like how Unity gives you the option between JS and C#, while keeping the API pretty much in Sync.
You are never forced to use one over the other because of missing features or bad documentation.

 

You actually can import and export Blueprints. They just don't make it obvious. To export a Blueprint you simply select the portions you want exported, you hit CTRL-C, you open a text editor, and you hit CTRL-V. Reverse the process if you want to import the nodes into a Blueprint graph.

Blueprint is simply stored as text in the clipboard. Check the spoiler below for an example of what it looks like.

Spoiler

Code (csharp):

1. Begin Object Class=K2Node_FunctionEntry Name="K2Node_FunctionEntry_904"
2.    Begin Object Class=EdGraphPin Name="EdGraphPin_69"
3.    End Object
4.    Begin Object Class=EdGraphPin Name="EdGraphPin_70"
5.    End Object
6.    Begin Object Name="EdGraphPin_69"
7.       PinName="then"
8.       Direction=EGPD_Output
9.       PinType=(PinCategory="exec")
10.       LinkedTo(0)=EdGraphPin'K2Node_DynamicCast_331.EdGraphPin_976'
11.    End Object
12.    Begin Object Name="EdGraphPin_70"
13.       PinName="Actor"
14.       Direction=EGPD_Output
15.       PinType=(PinCategory="object",PinSubCategoryObject=Class'/Script/Engine.Actor')
16.       LinkedTo(0)=EdGraphPin'K2Node_DynamicCast_331.EdGraphPin_979'
17.    End Object
18.    bEnforceConstCorrectness=False
19.    ExtraFlags=201457664
20.    SignatureName="UseSlider"
21.    bIsEditable=True
22.    Pins(0)=EdGraphPin'EdGraphPin_69'
23.    Pins(1)=EdGraphPin'EdGraphPin_70'
24.    NodePosY=48
25.    NodeGuid=C9B527BE43DC042E24B8C28443FF9D92
26.    CustomProperties UserDefinedPin Name="Actor" IsArray=0 IsReference=0 Category=object SubCategoryObject=/Script/Engine.Actor
27. End Object
28. Begin Object Class=K2Node_DynamicCast Name="K2Node_DynamicCast_331"
29.    Begin Object Class=EdGraphPin Name="EdGraphPin_976"
30.    End Object
31.    Begin Object Class=EdGraphPin Name="EdGraphPin_977"
32.    End Object
33.    Begin Object Class=EdGraphPin Name="EdGraphPin_978"
34.    End Object
35.    Begin Object Class=EdGraphPin Name="EdGraphPin_979"
36.    End Object
37.    Begin Object Class=EdGraphPin Name="EdGraphPin_980"
38.    End Object
39.    Begin Object Class=EdGraphPin Name="EdGraphPin_981"
40.    End Object
41.    Begin Object Name="EdGraphPin_976"
42.       PinName="execute"
43.       PinType=(PinCategory="exec")
44.       LinkedTo(0)=EdGraphPin'K2Node_FunctionEntry_904.EdGraphPin_69'
45.    End Object
46.    Begin Object Name="EdGraphPin_977"
47.       PinName="then"
48.       Direction=EGPD_Output
49.       PinType=(PinCategory="exec")
50.       LinkedTo(0)=EdGraphPin'K2Node_CallFunction_25802.EdGraphPin_982'
51.    End Object
52.    Begin Object Name="EdGraphPin_978"
53.       PinName="CastFailed"
54.       Direction=EGPD_Output
55.       PinType=(PinCategory="exec")
56.    End Object
57.    Begin Object Name="EdGraphPin_979"
58.       PinName="Object"
59.       PinType=(PinCategory="object",PinSubCategoryObject=Class'/Script/CoreUObject.Object')
60.       LinkedTo(0)=EdGraphPin'K2Node_FunctionEntry_904.EdGraphPin_70'
61.    End Object
62.    Begin Object Name="EdGraphPin_980"
63.       PinName="AsBP Slider"
64.       Direction=EGPD_Output
65.       PinType=(PinCategory="object",PinSubCategoryObject=BlueprintGeneratedClass'/Game/ExampleContent/AnimationDemo/BluePrints/BP_Slider.BP_Slider_C')
66.       LinkedTo(0)=EdGraphPin'K2Node_CallFunction_25802.EdGraphPin_984'
67.    End Object
68.    Begin Object Name="EdGraphPin_981"
69.       PinName="bSuccess"
70.       Direction=EGPD_Output
71.       PinType=(PinCategory="bool")
72.       bHidden=True
73.    End Object
74.    TargetType=BlueprintGeneratedClass'/Game/ExampleContent/AnimationDemo/BluePrints/BP_Slider.BP_Slider_C'
75.    Pins(0)=EdGraphPin'EdGraphPin_976'
76.    Pins(1)=EdGraphPin'EdGraphPin_977'
77.    Pins(2)=EdGraphPin'EdGraphPin_978'
78.    Pins(3)=EdGraphPin'EdGraphPin_979'
79.    Pins(4)=EdGraphPin'EdGraphPin_980'
80.    Pins(5)=EdGraphPin'EdGraphPin_981'
81.    NodePosX=336
82.    NodePosY=64
83.    ErrorType=3
84.    ErrorMsg="Warning Type mismatch between pins  Target  and  AsBP_Slider_C "
85.    NodeGuid=FF1EC8DB43EE6F0CFE6ED7A25AC48177
86. End Object
87. Begin Object Class=K2Node_CallFunction Name="K2Node_CallFunction_25802"
88.    Begin Object Class=EdGraphPin Name="EdGraphPin_982"
89.    End Object
90.    Begin Object Class=EdGraphPin Name="EdGraphPin_983"
91.    End Object
92.    Begin Object Class=EdGraphPin Name="EdGraphPin_984"
93.    End Object
94.    Begin Object Name="EdGraphPin_982"
95.       PinName="execute"
96.       PinType=(PinCategory="exec")
97.       LinkedTo(0)=EdGraphPin'K2Node_DynamicCast_331.EdGraphPin_977'
98.    End Object
99.    Begin Object Name="EdGraphPin_983"
100.       PinName="then"
101.       Direction=EGPD_Output
102.       PinType=(PinCategory="exec")
103.    End Object
104.    Begin Object Name="EdGraphPin_984"
105.       PinName="self"
106.       PinFriendlyName=NSLOCTEXT("K2Node", "Target", "Target")
107.       PinType=(PinCategory="object",PinSubCategoryObject=BlueprintGeneratedClass'/Game/ExampleContent/AnimationDemo/BluePrints/BP_Slider.BP_Slider_C')
108.       LinkedTo(0)=EdGraphPin'K2Node_DynamicCast_331.EdGraphPin_980'
109.    End Object
110.    FunctionReference=(MemberParent=BlueprintGeneratedClass'/Game/ExampleContent/AnimationDemo/BluePrints/BP_Slider.BP_Slider_C',MemberName="UseSlider",MemberGuid=35CF0AD241C69CFAAC3BAE90B484AB0D)
111.    Pins(0)=EdGraphPin'EdGraphPin_982'
112.    Pins(1)=EdGraphPin'EdGraphPin_983'
113.    Pins(2)=EdGraphPin'EdGraphPin_984'
114.    NodePosX=640
115.    NodePosY=64
116.    NodeGuid=8CDEA65A473090E20F199DA5D4845DC4
117. End Object
118. Begin Object Class=EdGraphNode_Comment Name="EdGraphNode_Comment_683"
119.    NodePosX=-48
120.    NodeWidth=1226
121.    NodeHeight=213
122.    NodeComment="Comment"
123.    NodeGuid=53990B834DED10705BDA1A9208119FBC
124. End Object
125.  

 

That is actually awesome. One thing to cross of in my list of things missing with Blueprint.

Now, it does seem that almost nobody knows about this option, given I only really found pictures of node systems being exchanged in the internet. Maybe Epic should spread the word, as this would tremendously speed up the process of copy-pasta for Blueprint.


Thanks for making me aware of it. If I ever get back to starting up UE4 again, I'll give it a try.

 

Well for a top down "POE" style game, you're not going to need most of them.. Probably just something like Ork Framework and Scion at a push, which is $150.00? Also you need to consider what you get from Unity store assets, something like Ork framework will be much more feature complete than UE's game framework which is more of a guide or base for your own functionality as opposed to a framework that does most of it for you..

@Master-Frog

Personally I don't find C++ in Unreal that difficult, I do find the lack of documentation in area's frustrating some times. But that's more of an Epic problem opposed to a C++ issue. There is definatley a stricter path of doing things, although it doesn't stop you making any type of game you'd wish to.. Doesn't even require fighting with the engine..

@Ryiah

Doesn't matter about feature parity, some will just naturally get on far better with Unity.. It's up to the individual, the good thing is you can have near enough feature parity if you're willing to pay for it.

@gian-reto-alig

There's more than just copy paste as well, you can import the .uasset with the BP's in it and right click > migrate BP's between projects.. As you can with all assets..

If readability is down, you're doing it wrong.. BP's can be used as a "pre-fab" system split for specific components, I've never used more than 50 - 70 BP's in a single instance and never needed to. Also for extremely complex / intensive mass data driven systems you'll use C++, I'd be tempted to use .DLL's in Unity as well tbh..

Also you have to take into account there are scripting systems like Skookum for UE which makes life much easier. You don't always have to rely on what Epic gives you with a small bit of searching.

 

That might all very well be.

To me as a Unreal newbie with a lot of expierience in Java in C#, and some in C++, but no interest in learning yet another syntax (Blueprint), the whole engine looked extremly unwelcoming.

If you didn't buy into the Blueprint hypetrain, you were left searching for documentation. Official documentation was "Blueprint this, blueprint that", with a few instances were you got a link to an alternative documentation showing how to do the same thing in C++.
The fact that you had to create a "Blueprint" as Unreals equivalent to Unity gameobjects was extremly unintuitive to me... "wait, I want to use C++ code, do I really need a Blueprint... isn't that, like, the name of the visual scripting language?".

The tutorials I got made things only worse (and some of them were books I bought).


Granted, maybe having had 5 years of practice in Unity wasn't the best start for trying to get into Unreal. But all I wanted was to get some good documentation and tutorials on how to use Unreal, WITHOUT having to touch Blueprints every step of the way. Seems that I either looked at the wrong place, or they are not there.


On the topic of Blueprint being not productive: the day I learn how to use the Blueprint System WITHOUT having to drag and drop things, but with simple hotkeys, is the day I will reverse my opinion (and might start using Blueprints even if I am not forced to)... on the other hand, using C++ with a good IDE and autocompletion gets pretty close to that, so for me as a programmer, the only reason to bother would be if Blueprint would achieve some usability miracle of cutting down on the amount of keypresses needed compared to C++ with autocompletion, while keeping the amount of mouse action needed at practically zero.

Might again be that this is already possible and I just didn't take my time to learn how to use Blueprint the correct way.

 

You know this reminded me of @GarBenjamin's thread where he mentioned trying to approach Unity in the way he desired rather than the way it was intended. He was just lucky that Unity doesn't make it that difficult to be productive while using it contrary to its design.

Normally you wouldn't use Blueprint as a programmer, but solo or in very small teams you'll be stuck dealing with it.

 

When you copy/paste a blueprint they are copypasted in text format which you can paste into notepad.

There's also a website for sharing blueprints:
http://blueprintue.com/

But OF COURSE nobody in the community ever uses it and everyone shares blueprints in form of unreadable pictures.

 

Sharing and modifying apparently.

 

None of that matters, as long as there is a way to accomplish a task the means in which it is done is irrelevant. Albeit removing complexity for the sake of it..

Every engine has "un-intuitive" workflows in some systems, some of them down right don't make sense. There's bugs in everything and you have to work around them, this is the nature of games development. If you have no "interest" in learning it, so be it everyone has options. Doesn't make Unreal a bad engine or unuseable..

It doesn't stop people making games in both Unity or Unreal, that's all there is to it.

 

Here is a list of pros/cons I made a couple of months ago for myself to decide if it was right for me when I was getting hugely irritated with UT and spent some time building things with Unreal.

Unreal Pros

· Blueprints are really flexible and extensive. Do almost anything. Custom nodes are easy to code up.
· Persona animator system is really solid and can use blueprints built in.
· Debug linking system is ideal. Debugging in Blueprints is also ideal.
· Lots of back end basic game systems are included like a proper hierarchy of Character>Pawn>Actor. Unreal understands that most people are making action games with characters, death, respawning, etc.
· Input system is fantastically easy to use.
· Proven engine with the developers being the ones making lots of popular games with it.
· Video tutorials are excellent.

Unreal Cons

· C++ only.
· Obscene amounts of visual noise in the workflow. Buttons, panels, icons, toggles, foldouts.
· Visual Studio is hella slow. ReSharper takes 45 minutes to parse the project and 5 minutes to warmup when opening. VAX is faster than ReSharper, but is still slow.
· Documentation is severely lacking.
· Immense amount of bloat and things you’ll probably never use.
· Across the board, Build and Compiling is a manual task with no clear advantages to actually being manual.
· Everything is catered to C++ including naming conventions instead of being more human-readable.
· The entry barrier is high due to fundamental over-complexity of the engine, interface, design and workflows in comparison to Unity.
· Royalties on published titles.


Why you might use Unreal

· You want polished, complex and focused tools from a company with lots of published titles behind them.
· You want a backend with an inheritance structure for action games already built in.
· You are a C++ purist and think it is better than everything else.
· You are not a programmer, but have piles of free time to learn Blueprints and really want to make something.
· You want an open source engine and have plenty of time.
· You like having lots of Post Effects on by default and want some free AAA assets that you’ll never use.

Unity Pros

· Proper C# front end that is easy to understand. Easily use your own dll's.
· Minimal product by default, very modular and cohesive across the board.
· Not bloaty.
· Visual Studio and ReSharper are extremely fast.
· Automatically detects code changes and recompiles quickly. No manual operation.
· Documentation is very robust, includes examples and references in addition to almost all class and member information. Video tutorials are exemplary.
· UI system is very easy to use, flexible and easy to hook in code.
· Flat up-front cost or 100% free license with a startup screen. No Royalties.

Unity Cons

· Mecanim has crude/clunky workflow and interface.
· Terrain system is severely outdated.
· Input system is garbage, outdated and severely lacking.
· Heavily relies on 3rd party tools from the Asset Store to fill in gaps where it is lacking. Does not actively fill those gaps since there is already a 3rd party tool to do so.
· Does not have a proper visual scripting tool built in. (everyone complains about this, but is it actually an issue?)
· Large parts of the current lighting system are buggy with serious problems and inconsistensies.

Why you might use Unity

· You don’t like C++ or you simply understand that it isn’t 1979 anymore.
· You want a very lightweight engine or need something you can rapidly develop a very diverse amount of different things on for a huge amount of platforms.
· You want a proper front end to code on instead of raw engine source.
· You want to make tools or plugins for an established marketplace.
· You don’t want a bunch of bloaty features that you do not need.



In conclusion, if you're asking the question "Should I use Unreal or Unity?" then you should probably use Unity unless you're a C++ purist. If you're asking aimless questions like "What would it cost to make things like this trailer?" for the purpose of doing it yourself then you are way over your head and need to stop being delusional about creating a triple-a title.

There are plenty of objective comparisons on the internet between Unreal and Unity. If you know your skillset and budget, it is easy to choose. If you find it hard to choose, you may want to reconsider your objectives and assets until it is.

 

Lol ... assuming you plan to commit to a project for an extended period of time, you'll be choosing one.

 

Sure, but my point is that you aren't stuck with it permanently. You may decide with the next project that the other is better.

 

My goodness sir what an absolutely fantastic post thank you very much for this detailed response.

 

You're still going to use one or the other on a per-project basis and that is how you should be evaluating what engine to use in the first place unless you just plan on getting nothing in particular done.

 

And the murphy's law says that you might pick least suitable engine of the two every time.
---
It is worth keeping in mind that when you are continuously working with the same engine, you'll end up accumulating code and experience which may make your next project easier.

 

UE4 get you top notch graphics, terrain, particles, water etc ... and more high level tools out of the box, your game at start will look better in UE4 than if you start in Unity without buying tons of addons.

Anyway, about Visual Scripting, the only one equals to Blueprints in Unity is Nottorus plugin, but it is too much expensive and i don't like DRMs on plugins.

 

This post really triggered me.
Unreal
1.Video tutorials are excellent (definetely not, unless you are not talking about random amateur posting on youtube some crappy video, unity tutorials are way ahead)
2. Proven engine with the developers being the ones making lots of popular games with it.(Completely irrelevant if we are talking about engine developers, if we comparing games developed by engine users i cant see any difference)
3. C++ only. (There is blueprints)
4. Obscene amounts of visual noise in the workflow. Buttons, panels, icons, toggles, foldouts. (Its true for both engines, if thats an issue use SDL instead of an engine, you will have to rewrite insane amounts of code though)
5. Immense amount of bloat and things you’ll probably never use. (Only if you are prototyping, or developing single type of game)
6. Across the board, Build and Compiling is a manual task with no clear advantages to actually being manual. (Are you kidding, its a pro if you are dealing with a complex project you dont want to recompile everything for a few minutes everytime you click something)
7. The entry barrier is high due to fundamental over-complexity of the engine, interface, design and workflows in comparison to Unity. (Unity is complex as much, just there is tutorial about almost everything you can copy. I used both of them exactly same time when i tried first time i didnt see any difference in difficulty.)
8. You want polished, complex and focused tools from a company with lots of published titles behind them. (Fail to see how its a reason)
9. You are a C++ purist and think it is better than everything else. (I dont think C++ better, C++ is the best is a fact (For game development). Forget about performance even you can access GPU directly is enough reason. I have same amount of experience in C (ok i have more experience in c then others), C++, C#, Basic (old school dos/unix version), VBScript, Python)
10. You are not a programmer, but have piles of free time to learn Blueprints and really want to make something. (You cant do S*** with BPs if you are not a programmer because its just C++ represented graphically, its harder to do things with it (keeping all picture in mind when things are getting massive) but it doesnt create tons of bugs because you made a simple syntax error somewhere, and it forces you to match variable types. So its better than C++ (unless you want to do really advanced stuff) because it cuts %90 of time you deal with bugs but what you are doing is still C++ programming and you can create all functionality needed except when you need to reach hardware)
11. You like having lots of Post Effects on by default and want some free AAA assets that you’ll never use. (It can be true but its strange way of thinking about a game developer, since you will need lots of assets which are compatible with each other, you will either end up designing your own assets or hiring an artist. A bunch of free assets wont make a difference)

Unity
1.Proper C# front end that is easy to understand. Easily use your own dll's. (C++ is as easy to understand as well, you can do same things using same logic and using same functions. Only difference is when you dont know how to program and stitch bunch of code together C# is less likely complain. Creating a functionality isnt any harder in in C++ or C# when you do it properly. If you are having problems chances are programming skills arenot solid issue is not with C++)
2. Minimal product by default, very modular and cohesive across the board.
· Not bloaty.
· Visual Studio and ReSharper are extremely fast. (Unity used to be faster than unreal, unreal is getting faster, unity is getting slower as time passes)
3. Documentation is very robust, includes examples and references in addition to almost all class and member information. Video tutorials are exemplary. (It is correct but you are contradicting yourself in what you said in unreal part)
4. UI system is very easy to use, flexible and easy to hook in code. (UE4 and Unity 5-2017-2018 at same level of difficulty using UI. Which is not easy even comparing with Visual Basic 4.0 from 1995. But they do their job enough i wont complain wish they are simpler)
5. Flat up-front cost or 100% free license with a startup screen. No Royalties. (Its wrong neither Unity nor Unreal is free, they operate with pay if profit policy. Unity is cheaper one since it asks for fixed costs (for 8man indie studio its asks 12k/year) on the other hand if you launch a game/2 years and having exactly 200k profit each of games you pay 5k/year total in unreal but if you sell your games at 5m profit you endup paying 125k/year. Unless you are super succesfuul you pay around same amount but slightly more with unreal. If your team is 2-3 man Unity gets lot cheaper for you but if you have team of 20-30 man unreal might be the cheaper option) (Cost heavily favors Unity but there there is a small thing payment structure makes Unreal really wants you succeed. )
6. You don’t like C++ or you simply understand that it isn’t 1979 anymore. (You probably meant C, C++ is extremely modern language, C++ and python are biggest players right now, C# has microsoft supporting it, python requires programmers donate their time to debug and improve the language still it has massive lead. C# is best when you want to use servers with microsoft architecture, python is easiest for less experienced and these days companies like google using it massively (one of their reasons is they dont have to rely on their competitors to develop the tools they use) All 3 have entensive libraries created for them so decent language for generic development.)
7.You want a very lightweight engine or need something you can rapidly develop a very diverse amount of different things on for a huge amount of platforms. (Unity supports slightly more platfroms, if have similar amount of experience i cant see how development is slower in unreal though)
8.You want a proper front end to code on instead of raw engine source. (there is no such thing "proper front end code" ?? go write jscript for webpages it thats your aim. You dont write raw engine source in unreal unless you want to. Its their advantage that you can write if you want to )

Tried to be objective as much as i can. I am personally using unity right now. I think unreal is a bit better but i am not professional, i am not writing code to generate income but using it for stress relief. My C# skills are not sharp these days but i didnt write a single C++ code for last 2 years either. I am more familiar with Unity editor. I dont mind Unity has more bugs then unreal (if its still true)
Unreal Engine two real drawbacks for me right now.
1. UE lacking in amount of proper tutorials, you can find 2-3 recent tutorial on a random thing when the only tutorial you can find in unreal is dated 4 years etc.
2. UE asset store is much more expensive and lacking in volume. ( I wouldnt mind creating assets for my project if i am developing games as an indie dev or in a some studio or i would have an artist but when my project size is at work 1-2 hours/day make a game in 1-2 weeks an play it few times then trash it start another one scale. Its meaningless to work on creating assets for some months) You can download unity asset and use it in unreal but i dont know the point of it. (And you cant use your overpriced unreal assets outside of unreal even if you paid)

 

That's some serious necro skills you've got there buddy.

 

Why nobody mentions system requirements? I understand that unreal-made games require more powerful systems.

 

This is a misconception.
Unity made games (or using any other modern engines) can be more resource hungry than a UE one.
It's how you made and optimize them.

 

too LATE I know but hey, you have to admit that both UE and Unity went a long mile with respect to visual coding and processes, I believe now it's a very narrow comparison between the both.