RTS - Character blueprint vs Ai Controller for units

[Fairchild1]

Working on an RTS. Currently I have nothing in any ai controller blueprints and everything is done using the player controller/HUD interfacing with the parent unit character blueprint.

So far it’s working fine. I am not utilizing a behavior tree currently, but before I get too much further i want to make sure this is OK, and that it’s not a big deal to not switch over to developing the AI Controller blueprint vs the parent character blueprint.

For reference I am not using a behavior tree as it seemed from what I gathered it’s not great for multiplayer.

[VenomStyx]

As far as it being an issue for functionality, I don’t believe you’ll run into any problems. I’d personally suggest keeping each system in its own component on the AI controller, but you can do it this way as well.

The main downside I see is that you likely won’t manage your AI based on controller references (which can persist through many characters) meaning you’ll be spawning lots of controllers when you could otherwise avoid it. Not sure how much this will affect things but since you’re going for lots of AI it’s definitely something to consider.

Check out this explanation on how to use the different classes:

What should I do in GameMode, GameState, and PlayerState?

Hi, I’m creating my first game in UE4, and I’m just sorting in my head what the above-mentioned blueprint classes should do. I know that a lot of people say there’s no set way to do things, but I’m trying to understand what these classes are intended for. My guess is that GameState and PlayerState should really be used to hold values and not implement any behaviour as such, whereas the GameMode should contain most of the game logic and be used to tie the player, level and HUD .etc. together. …

---

Also, I’m a bit bias, but consider checking out VisAI. There’s a free version, it’s multiplayer friendly, & it’s perfect for managing this kind of AI. If you don’t have some kind of framework it’s going to get complex & unmanageable pretty quickly.

---

Good luck!

[VenomStyx]

Also, one of many reasons to use components, you could easily just attach to the AI Controller instead of Character down the line if needed. Or just to a different character/controller. Just a few adjustments & you’re up and running.

[Fairchild1]

@VenomStyx

The main downside I see is that you likely won’t manage your AI based on controller references (which can persist through many characters) meaning you’ll be spawning lots of controllers when you could otherwise avoid it.

Ok, I’ve ran into a problem. The player controller and AI controller are interfaced, but when the player controller tries to message the AI controller it doesn’t make it through. On a Listen Server Net Mode, the “Server” client works fine. But the other local clients do not.

Reading around, it seems by design that a client can not communicate with the AI Controller via their own Player Controller. So, if I am going to build up my AI controller blue print, how am I supposed to access it via local player controller?

Do I still relay player controller commands to the character blueprint, but then everything else goes into the AI controller blueprint? Things like automatically attacking enemy characters in range, etc?