I've been working with Unity since 2005, and recently started doing a prototype in UE4. So this post is meant to help people like me that either have experience in Unity or are simply new to UE4.
It doesn't make sense for me to go into the differences/similarities between Unity and UE, since this article already does a good job explaining them.
It doesn't make sense for me to go into the differences/similarities between Unity and UE, since this article already does a good job explaining them.
Scene Component
The one thing that it took me a long time to find out it existed (didn't see it in any docs at the time) was the Scene Component. This component is very useful, and it's name is very misleading (IMO it should be called Anchor or Transform Component. It basically allows you to offset components internally when you're building your Blueprints (BPs), which is something that you just do naturally in Unity by chaining GameObjects.
Keep in mind that in the World Outliner it will still show up as a flat object since they are Components, unlike in Unity. To actually chain them like that your option is Child Actor Component, since that's the one that uses Actors (which are the only things that can be placed in the world).
Use Blueprints
Speaking of which, I highly advise you to start doing things in BPs. As a programmer I've always been skeptical about these kinds of tools, but I have to say that BPs have far exceeded my expectations.
The main reason why I suggest starting with BPs is because IMO the worst part from UE so far is that its API shows it's age.
Finding things in UE most of the times (specially when you're starting to use it) is very cumbersome. I'm used to Unity's API, which is pretty intuitive. For example, if I want to open a new level I just think about "who should open the level" and it leads me to think about the Application class. In UE, for example, it is in UGameplayStatics class, which kind of looks (from it's class hierarchy) like a class that was created to expose common useful things to BP.
Another example is raycast, which in Unity you just think about "I want to cast a ray, let me search the Physics class", and in UE it is in the UWorld. And a lot of times figuring this thing out just takes too long, because usually the oficial documentation shows you how to do it in BP.
The main reason why I suggest starting with BPs is because IMO the worst part from UE so far is that its API shows it's age.
Finding things in UE most of the times (specially when you're starting to use it) is very cumbersome. I'm used to Unity's API, which is pretty intuitive. For example, if I want to open a new level I just think about "who should open the level" and it leads me to think about the Application class. In UE, for example, it is in UGameplayStatics class, which kind of looks (from it's class hierarchy) like a class that was created to expose common useful things to BP.
Another example is raycast, which in Unity you just think about "I want to cast a ray, let me search the Physics class", and in UE it is in the UWorld. And a lot of times figuring this thing out just takes too long, because usually the oficial documentation shows you how to do it in BP.
Try to Use Windows
This one pains me to say, but unfortunately I'd recommend you use Windows. ATM (4.7.4) UE still has some sluggishness in the editor - and some crashes - that seems related to input on OS X (which I've been told should improve with 4.8). The experience in Windows is far smoother.
The other big problem is that OS X only allows you to build for OS X and iOS, which is a big let down for me. One of the big pros of Unity is that I can just build it to whatever platform I want from any OS (the only exception was iOS which forced you to build from OS X).
Besides that, I have to say that they are pretty much always behave the same on both platforms. Initially I was seeing some weird behaviours which I naturally assumed it was from the OS X version only, but turned out that they were bugs present in Windows too.
However, that being said, I've been using OS X for most of it because so far I've been focusing in BP, which only require you to use the Editor. The problem comes when you try to go into C++ land, which has a horrible support in Xcode (e.g. you can't do simple things like refactor a function name).
So if / when you're going to use C++, I'd advise you to go with Windows.
The other big problem is that OS X only allows you to build for OS X and iOS, which is a big let down for me. One of the big pros of Unity is that I can just build it to whatever platform I want from any OS (the only exception was iOS which forced you to build from OS X).
Besides that, I have to say that they are pretty much always behave the same on both platforms. Initially I was seeing some weird behaviours which I naturally assumed it was from the OS X version only, but turned out that they were bugs present in Windows too.
However, that being said, I've been using OS X for most of it because so far I've been focusing in BP, which only require you to use the Editor. The problem comes when you try to go into C++ land, which has a horrible support in Xcode (e.g. you can't do simple things like refactor a function name).
So if / when you're going to use C++, I'd advise you to go with Windows.
Extending The Editor
I have to say that I haven't delved into this one yet, but from what I looked at it, it is far more complex to start using than in Unity, which tbh is a shame (specially given how Unity is so easy and I've used extensively).
Eventually I'm going to step into it, and I'll post some thoughts.
Eventually I'm going to step into it, and I'll post some thoughts.
Network Ready
I'd have to say that probably this is the biggest thing for me (from my programmer view), network is very built into UE. It is very easy to get networking stuff working, specially if you want to have characters moving around.
However, not everything is roses. You're going to get into a lot of issues which IMO comes from 2 things: UE gameplay framework (which you'll have to learn and get used to), and dated APIs.
It's clear that UE is still not fully revamped, and in some areas this is quite apparent. In the next post I'll try to put out some hints about what issues and solutions you may come across when developing a networked game.
However, not everything is roses. You're going to get into a lot of issues which IMO comes from 2 things: UE gameplay framework (which you'll have to learn and get used to), and dated APIs.
It's clear that UE is still not fully revamped, and in some areas this is quite apparent. In the next post I'll try to put out some hints about what issues and solutions you may come across when developing a networked game.
RSS Feed