For the past 3 years that I’ve been exploring the world of Entity-Component systems, I still find Unreal Engine’s approach one of the most solid ways of handling input and character controlling, however, it is kinda hard to imagine a game that’s not a FPS or an Action game modeled around it, since it seems that’s what it was built for. Since very often I see the argument that Unreal is not good for games that are not FPS, in this article I’ll walkthrough how to setup an RTS/RPG controller system for Unreal Engine 4.

How FPS and Action games work

This genre of game has the actions tightly mapped to the controller, you press forward, and the character moves forward for the same amount of time you hold the key. Each time you press Left Mouse Button, one sequence of bullets goes trough you gun. The camera is tightly coupled to the character and the mouse.

How RTS and RPG work

Most RTS, some RPG (examples are Ragnarok Online, World of Warcraft and MU) and even some simulators (The Sims, Spore) work like this way: You act like an omnipresent god which see everything from above or a similar perspective. You don’t really control your character, you just command him to start doing something. Your actions are not mapped to the characters actions, but they trigger in the character the will to do something. For example, you right click the terrain to tell your character that you want him to go over there. He will check if he can go there and if there’s an available path for him to travel, if this succeeds, he will walk on his own to the target point, usually following the shortest or the safest path. Another good example is attacking. You right click an enemy to tell your character that you want him to attack it. Your character will travel to the last position he saw that enemy, and if he finds the enemy there, he will keep attacking him until the enemy dies or you decide he should do something else.

How does both differ, and why does it matter to the Unreal Engine?

It’s easy to answer, on action games, the character has no brain of himself, the player is the character’s brain. Almost all actions have to be trigged by the player to happen. Just ask yourself: How many FPS have you played in which the character walks on itself to a place where you told him to go and then started attacking enemies just because they were close? I think that clear things up: action games you do all the actions, RTSs and RPGs you tell the AI what actions it should take. All this matter because Unreal treat AI and Player Input as two totally different types of Controllers. A pawn or character can have only one controller, so you have to choose, AI or Player Input. For an Action game a single Player Controller is enough, but can a single AI controller be enough for a RTS? That’s what most people try to do at first, but soon they see that Unreal really segregate this controller stuff. The AI Controller can’t receive player input, and the Player Controller can’t calculate path or execute a behavior tree. So how can one make an RTS happen?

AI Controller or Player Controller, which to choose?

Both. We decided earlier that an RTS need both input from the player (to decide what task to do) and input from the AI (to do the task), so you should use both.



Oh you can’t use 2 controllers side by side on a pawn in UE4! And what about the camera, how can I move it while not being stuck to the character? Well let’s revisit our definition of the RTS way of controlling characters:

You’re a god-like spectator;

You can see everything from above (you’re a camera with very high Z facing down);

You can issue commands to your units;

Your units AI will execute the tasks you commanded

Take a closer look… Can you see that there’s one thing on this definition which we were missing on the implementation plan? I’ll tell you: there should be two different fundamental entities, the “godlike commander” and the “controllable unit”. This is how the hierarchy should be:

As only the player controller can receive input, and only the AI Controller can calculate AI and run behaviors, we keep all that by isolating them, and whenever the player wants to send a command to the character, the Player Controller is going to receive the input (Right Mouse Button, maybe?) and decide what kind of action this is, then send to the Top Down Controller, which is just a blueprint that has the AI Controller as Parent and implements some new Actions such as Follow Unit and Attack Unit:

When the player right clicks, call this Action function; Check if there’s something under the cursor, if true, then set it to a variable and continue;

If the actor hit was not an unit, call “Move to Location” on the Top Down Controller sending the Location in the ground which the mouse was hovering; Otherwise, cast it to a Top Down Character and set its value to Target Unit and continue;

If the unit was an enemy call “Attack Unit” on the Top Down Controller Otherwise, it’s friendly, just follow it by calling “Follow Unit” on the Top Down Controller

That’s pretty much all that’s needed on the Player controller, apart from the camera controlling, which you should model to your game style, so I won’t be showing that.

Now on the Top Down Controller, we should have some actions(Custom Events) which the Player Controller should be able to call:

Here’s the example of my Follow custom event, it’s very simple, it sets the target it received as the value on one of the blackboard’s keys, then change the task to Chasing.

Set task will set the task on the blackboard and then restart the AI logic, so it stops and forget all it was doing before and start the new task asap, that’s how a command should work on a RTS, but if you’re queuing commands, you probably will want to skip the Restart Logic part!

And here’s how the Behavior Tree looks like. As soon as you Restart the logic, it will enter in either one of the tasks set in the Current Task key on the Blackboard, and then keep on it.

Unreal Engine 4 for sure is very solid and robust, and part of this robustness is focused on making a perfect FPS or Action oriented game, but that is certainly not a good excuse to not try doing stuff in it! If you’re having problems modeling a system for your game, try shifting your view. There’s usually more than one way to do stuff!