Bots
Last updated
Was this helpful?
Last updated
Was this helpful?
Bots (also known as "simplayers") are fake players that help creators representatively test game performance, rendering and networking by simulating high player counts.
You can add bots directly to a launch world by clicking the đ¤ Add Bots button
After a few minutes, you should see bots start to appear in your world
In the Play dropdown, set the Number of Players to 2 (or more) players.
Open Editor Preferences, search for Editor Client Connection Types
First, add J_PlayerClientConnection, then a J_BotClientConnection (and more if you added more than 2 players in the previous step).
Pressing Play will now spawn an additional window for each bot connection
Bot behaviours describe what actions the bot takes after spawning.
In the Outliner panel, ensure your level has a BotBehaviorStore (if not, add one).
The bot behavior store controls what behavior is run on the bots, based on what command you give them.
In a PiE session, press ` to open the console.
Type Morpheus.Bots.List to list available bot behaviours in the Output Log.
Enter Morpheus.Bots.Run emote (or another entry), and all running bots should change their behaviour accordingly.
The "default bot behavior" is controlled via live config: Bots.BotDefaultBehaviour (in the Game config). Whatever value this is set to, bots will start up running that behavior.
(If this value is set to be empty, then the bots will not run any behavior until you explicitly tell them to)
Bot behaviors are implemented using Unreal behaviour trees. To implement behavior trees, you can reference the existing behaviors or consult the Unreal docs:
Once created, add your behavior tree to the list of behaviors on the bot behaviour store in your level (giving it a unique name).
In a PiE session, type Morpheus.Bots.List and you should see your new behavior name.
Type Morpheus.Bots.Run <behaviour_name> and all bots should start to execute your behaviour tree
Since behaviors can be stopped at any point during their behavior tree (e.g. if you call Morpheus.Bots.Run [Some other behavior] whilst one is running, we can get into bad states if any logic was set for the duration of the test that should not be present when running other behaviors.
Our solution to this was adding TearDownBehaviors to the behavior store. This behavior is run once you switch away from a given behavior, so can be used to clean up any state the behavior used.
If you have a behavior [behavior_name] in your behavior store's Behaviors map, that requires teardown logic, add an entry to the TearDownBehaviors map, with a matching [behavior_name]
Do your cleanup logic in that teardown behavior tree. Once you are done, call BTT_MarkTearDownComplete to inform the bot manager system that the teardown of the previous behavior has finished.
The bot will then move on to running the next behavior.
Unreal's StateTree system can also be used to run bot behaviors, in a different setup to our existing setup. If you want to use this, you can, but we would recommend you disabling the existing bots system (turn off the default behavior in Setting a "default behavior" to make sure the two systems are not conflicting). Otherwise, this system should largely work in MSquared in the same way as native Unreal.
Some things to take care with:
Any replication will still need to be handled through Morpheus Actors
If the state tree is set to start automatically, the logic may run before the bots have set up correctly. The bots are given their appropriate bot controller via the morpheus actor, and this may not be set up when the character starts running its behavior tree. This can be handled by waiting for the appropriate controller, e.g. by using the bootflow
Make sure that the state tree is only run on bot clients!
In test deployments, multiple bots can run on the same cloud instance, each pretending to be a player with their own client connection. That means that multiple client connections share an Unreal client.
To get round this problem, you can use the AMorpheusActor function PushRpcSenderConnection to specify which client connection to use, before calling your RPC. Make sure to either set its PopAfterNextRpc flag or else clean up manually by calling PopRpcSenderConnection after calling the RPC. For example:
N.B. The default client connection used for an RPC is the one which was used to created the AMorpheusActor which the RPC belongs to. That means that you don't need to bother with this step if the RPC belongs to a PlayerCharacter actor - each bot's own character gets created by its own client connection.
This introduces a complication: when client code invokes an on the server, it's not always obvious which of these client connections the RPC should go via.
For example, suppose you have a AMorpheusActor with a server RPC, let's say KillCallingPlayer. The RPC's handler function will rely on ServerGetRpcCallerConnection to securely identify which player to kill. By default, the RPC will be sent via the client connection which created the singleton. However, when multiple bots share an Unreal client, they also share the client's singletons, so by default it's probably the wrong bot who'll get killed.
emote command will run the BT_BotEmote behavior tree, and so on.roles teardown behavior (BT_BotSwitchRolesTeardown) is run when you stop running the roles behavior, and makes sure that the bots return to the default role, rather than being stuck in whatever role the running behavior had previously set them to.
