Sicaria

Sicaria is a stealth game where you use takedowns and gadgets to navigate through the levels and complete objectives. You play as an assassin/partizan sabotaging the Spanish effort in Antwerp during the 80 years war.
The game can be found on steam through this link.

• Both implementation and design work
• Designed and implemented the flow of the behaviour tree
• Implemented audio cues and animations
• EQS (Environmental query system) tests to find valid positions

Summary:
The Implementation was done in it's dedicated investigation sub behaviour tree. Any AI can respond to a noise or something it saw with a group related voice line but only the closest AI investigates, both actions are determined using a token system. To find a point that is at a valid distance and in line of sight of what triggered the behaviour we use EQS.
I also took on part of the design since the person assigned to this was already busy with other aspects of the AI. To verify the quality and direction of the work I did, and to learn a bit about designing AI in the process, I passed my work by the AI designer for feedback and iteration.

Example of AI reacting to sound and only one of them investigating (breaks up a scripted event made by a designer)

• Implemented a token-based combat loop as defined by the design
• AI surrounds target
• One melee AI attacks at a time with cooldown
• One ranged AI attacks at a time with cooldown
• Other details defined by the design that I implemented

Summary:
The flow in the behaviour tree makes active use of a Token system I made and Unreal's EQS (Environmental query system). Both the melee and ranged AI use EQS to decide where to move to, at specified ranges around the player, keeping some distance from each other and the player to not overwhelm the player and to allow them to try and run. By only assigning one melee and ranged attack token to a group, the token system is used to avoid overwhelming the player by only allowing one enemy to attack at a time.
This was all done according to the design I made but it was still passed by our AI designer to verify it worked and fit the game in the way they expected from my design.

The AI behaviour showcased in my test world using geometry from the main level

• Technical design documented in Miro
• Implemented the whole system
• Robust and easy to adjust
• Centralised functions for easy debugging
• Low level components in C++ (Only programmers touch this)
• High level components in Blueprints (Programmers and designers touch this)

Summary:
The system was made using a core behaviour tree that used a state machine to control which sub tree to run.
To get feedback on the technical design I passed it by the AI team and communicated with level design regarding their needs for the AI.

After the project I learned that while a state machine does work, part of benefit of using a behaviour tree is no longer needing to not maintain a state machine. I used a behaviour tree, as intended, in a later project and through this experience I learned to-do a bit more research into systems before using them, even if you think you know how they work.

The technical design as documented in Miro.

• Technical design documented in Miro
• Implemented the whole system
• Groups that manages actors and tokens
• Tokens used that allow AI to act
• Releasing and returning tokens in C++ (Only minor adjustments needed)
• Specific checks for releasing tokens in blueprint (A lot of smaller adjustments made by programmers and designers)

Summary:
The system works by handing out "tokens" to AI actors based on specific variables to allow the actor to perform specific actions, this way you can for example have one or more enemy’s attack at a time or have only one enemy in a group investigate some sound they heard. The core of the group behaviour was based on a simple token system as explained by one of our lecturers.
To verify the system was clear and easy to use I passed it by level design since they would be adjusting it the most.

The technical design as documented in Miro:

• Custom noise component for trigger an audio signal on any object
• Line trace and pathfinding checks
• Check if walls block audio
• Check if audio can pass through the wall
• Check if audio can pass over the wall
• Check if audio can pass around the wall (pathfinding)

Summary:
The audio perception was developed during the prototyping and preproduction phase. Using the existing unreal perception component as a basis, we wanted to test how we could handle audio perception, if we needed to make something new for it and to what detail we should make perception checks. The perception stayed mostly the same as the prototype with the core of the system in C++ and a modular structure in blueprint for the specific checks. This way design could easily add on to and adjust the flow of the checks without having to dive into the code.
I passed my work by the AI team but primarily checked in with Level Design to address the needs of the level.

Example of audio perception with it's relevant checks in action.

• Researched group behaviour in other games
• Evaluated aspects of the behaviour and how it would fit in our game
• Made a visual representation in Miro to support the design

Summary:
I picked this task up because the other designers and specifically the AI designer was too busy with the other aspects of the AI, and I was interested in practising some design anyway. I researched similar games to ours like Assassin's Creed Black Flag and Dishonored 2 to see how they handled group behaviour, took notes and evaluated why and how they implemented certain aspects of the group behaviour, and assessed their suitability in the context of our game, including the "feel" we wanted for our AI. I compiled these findings in a document and passed it by our AI designer. After iterating on the feedback and making a visualization of the design I got a final pass by the designer since they still had the final say on the details.
To make implementation easier, with less adjustments and with less issues I created a flow diagram for the structure of the behaviour tree.

Visualized design of the group behaviour for both melee and ranged enemies, does not include some of the reasonings that would be described in the research document The technical design for the behaviour tree and it's flow, besides some minor adjustments to variables it's mostly accurate to the final product