Sicaria

Sicaria is a pure stealth game where you use stealth takedowns and gadgets to finish objectives. You play as an assasin/partizan sabotaging the spanish effort in Antwerp during the 80 year in the 17th century.
The game can be found on steam through this link.

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

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 desing 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 (Allot of smaller adjustments made by programmers and designers)

In short, the system works by handing out "tokens" to AI actors based on specific variables to allow them to peform 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)

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 in action. The debug lines represent some of the checks described above.

• 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

The Implementation was done in its 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 the 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 another designer)

• 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

I picked this task up because the other designers and specifically the AI designer was still 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 and 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 and with less issues I also 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 its flow (besides minor adjustments in variables and decorators its mostly still accurate)

• Implemented the 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

The flow in the behaviour tree makes active use of the Token system I made and Unreal's EQS (Enviormental query system). Melee and ranged AI uses EQS to decide where to move to at specified ranges around the player, keeping some distance from eachother and the player to not overwhelm the player and 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 acording 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