One of the biggest problems when getting into UE is that the documentation is very lacking in some areas. One example, is that they talk about their framework, but I didn't find anywhere is how this framework is organised between Server and Clients.

This post is meant to shed some light on how things are structured, so that you can get a better understanding on how things work and what exists where.

Unreal's network is the standard server-client architecture. Basically, the server is authoritative, and the clients send information to the server, which the server then validates and executes upon.

So when you're moving your character, the one that actually moves it is the server. You can specifically see this if you have a bad connection with the server, where you'll feel the character unresponsive  and your character position will be corrected, warping it to where it actually is in the server.

This also means that clients never talk to each other directly. If you want to send a chat message to the players on your team, what you're actually be doing is sending a message to the server saying that you want to send a message to your team, and the server will be the one relaying it.

When developing a game that you want to work in multi-player, I advise you to always keep this in the back of your head, never just "do something", tell the server to do it (exception being client only things, that should just be "visual stuff", nothing that actually influences the game).

So given this, it means that the framework is laid out between:

• Server Only - an object only exists on the server
• Server & Clients - an object is known to everybody, so if the server changes it all the clients will get the update
• Server & Owning Client - an object only exists in the server and the client that owns it
• Owning Client Only - an object only exists in the client that owns it

The next picture shows how the objects would be distributed through the network:

Notice the intersection between client 1 and 2 doesn't have any objects, just like I mentioned above, everything goes through the server.

The Game State (AGameState) is probably the most important globally shared class. It holds a list of the players in the game (Player States), so when you want to get a player you go through it, NOT through UGameplayStatics::GetPlayerController (which is a very common beginner's mistake).

So if Game Mode held how much time a round of the game took, the Game State can be seen as the class that would keep track of the time remaining.

The Player State (APlayerState) is the most important player related class, because it represents the player, and as such is where the important information about the player will be kept (e.g. how many lives he still has, team he belongs to, username, etc).

The Pawn (APawn) is a thing that the player can control (through the Player Controller).
There can be multiple Pawns in the game, however the Player Controller can only possess one at a time.

For convenience, UE has a Character (ACharacter), which comes from Pawn, and adds a "network movement component", which handles the movement of the Character. Like I mentioned above, the server is the one that moves things, not the client, so it is because of that "special" character movement component that we're able to just say locally to move the character, but in fact that abstracts for us the fact that the data is being sent to the server to act upon it.

The Player Controller (APlayerController) is in my opinion the biggest trap for newcomers to UE.

Most people associate the Player Controller with the representation of the player, which is wrong. The Player Controller can be seen as the "player high level input".

Basically when the player possesses a Pawn, this is the class that will control it. The reason that I call it high level input and not just input, is because you CAN have the input in the Pawn; in fact, I recommend you do your input in the Pawn, because in a lot of cases you possess pawns with completely different input and behaviour (e.g. a human and a car), so it is much easier to handle the input in the Pawn it refers to, than globally handle all input in the Player Controller.

By the way, the way input works, it will first be passed to the Player Controller, and if it doesn't get used up by it, it falls through to the Pawn. So you can have different levels of input, for example handling menus in the Player Controller, and then the movement of the Character itself on it.

Something that a lot of people stumble upon is how to get their Player Controller. Although it isn't easier to find, there's a rule that states that when you call UGameplayStatics::GetPlayerController( 0 ) it always returns your Player Controller.

So if you're running a server, GetPlayerController( 0 ) returns the Player Controller of the server. If you're running a client, GetPlayerController( 0 ) returns the Player Controller of that client (remember that clients only know their Player Controller, so they can't access any other).

If you're running a dedicated server (i.e. pure server without a local client), then GetPlayerController( 0 ) will return the first client.

The HUD (AHUD) is an object that is automatically spawned per player, and added to their Player Controller. Although you can use it for low level things (e.g. drawing text on screen), it is mostly used for debugging purposes. You can think of it as Unity's immediate mode UI.

If HUD is the immediate mode UI, the UMG is the new default UI system in UE, which has more complex elements (e.g. labels, text fields). Thankfully, the engines are getting away from scaleform (which I'm not a fan), and UMG is very similar to Unity's new UI system (specially the anchor system which I'm a fan).

As of 4.7.6, UE still has some issues when spawning the HUD at the start, so what I advise for now is that before you spawn any UMG widgets, add a delay (e.g. 0.2s) to let UE properly initialise stuff before the widgets are created.

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.

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).

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.

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.

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.

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.