It’s difficult to find arguments if he really hates UE4. Like if someone hates Windows you’ll have a hard time talking him into giving up OSX…
My guess is that he just never got into it deep enough.
Personally i originally thought Blueprints are a bit clumsy - pretty complex functions might be difficult to read on first glimpse and i often re-arranged nodes to look “prettier”. However i got used to it pretty fast and now I can barely imagine programming 10 lines of code that i click together with the mouse in like 20 seconds. After a while you get used to it that much that you feel like you click together functions at nearly light speed, you only used the keyboard to enter 3 or 4 characters to pick the right node and it is really pretty fast.
I think the first week or so two were really hard for me in UE4 since i never really follow any tutorials or books and made loads of wrong assumptions and mistakes that way, but afterwards the learning curve was pretty nice.
Have worked with both the UDK and UE4.
Can confidently state that UE4 is not UDK.
It will take some time to get acquainted with changes, but this is true for everything.
There will never be enough documentation, but at the same time, having full access to the source makes this less of a problem.
No information on how something works?
Just get in there and figure it out.
>>
Perhaps it would be better to list out what underlying features you require before making the switch.
If there is some major feature that is missing in UE4 that you have already created in Unity, it may be best to stay.
For coders it is much more complex. Access to the source code does little to mitigate this issue, although it does at least allow you to step through and learn how things work. UE4 compile times are hideous and the monolithic nature of the code means trivial changes can set you back a number of hours. Programming with C# inside Unity is much more productive. The turnaround times are an order of magnitude quicker.
UE4 API’s are cluttered with legacy chaff which can really hinder the learning process. Unity’s core API’s (GameObject and MonoBehaviour) are very clean and simple to learn.
Object lifecycle in UE4 is much more complicated to learn - especially when this lifecycle is different between PIE, server, client, standalone etc. Same is true for most of the core systems inside UE4 - they are simply badly or not documented.
Epic’s focus on Blueprints really shows in how poor their for C++ workflow is. Proper technical documentation about how the engine works is virtually nonexistent, and trauling through 800MB of source code is not a productive option. Try using BP for anything non-trivial and you will quickly hit some hard problems. Refactoring from BP to C++ as your project scales is absolutely awful as the dependency analysis seems broken - you will spend most of your time rebuilding and watching log output rather than actually working.
Cooking is slow, error-prone and laborious. Iterative cooking is buggy.
UE4 feels like it is in a constant state of early beta. Nothing really works properly until a few releases after it’s initial public outing. With Unity things either work or don’t - and there’s nothing much you can do about it outside of waiting for an updated version. It’s possible to struggle through with UE4 by finding workarounds and hacking at the engine source, but it’s pretty demoralizing to hear about the all-new features and then when you try them hit continued problems. Blueprint nativization enyone ?
I’m not hating on UE4 here - after a year of using it I’m actually liking it, but I can really understand your friends reticence about switching. Unity and UE4 shouldn’t really be directly compared since they solve the ‘game engine’ problem from different directions. UE4 is nicer for artists - there’s no doubt there - but switching from Unity to UE4 is a HUGE investment of effort for a coder.
If your programmer must have other people on forums find hacks for him, and does not have the skills to read through the source code and find the answer himself, then perhaps you need to skill him up?
When I ask a question in the Unreal Forums, and sometimes don’t get an answer (because my questions are often not on the mainline path,) I’ve always managed to find the area of the engine that implements the feature in quesiton, and read through it and understand what’s going on.
That being said, if your programmer isn’t great at C++, then Unreal may not be a great fit for him/her.
People are resistant to change; that is something that’ll never change. * pun yay *
All I can say is one of best things I have ever done of my life was taking the time investment to learn UE4.
Doing so has provided me the opportunity to visit another countries, work with very interesting people from everywhere, meet other cultures and etc… With Unity, not so much, it seems Unity’s freelance market is almost entirely internet based (you sit at home and just work online)
