Sicaria

Sicaria is a stealth assasination game that does not include combat outside of stealth assasinations. You play as an assasin/partizan sabotaging the spanish effort in Antwerp during the 80 year in the 17th century. The goal of the game is to kill a high ranking Spanish officer and sabotage their warship

The game can be found on steam through this link.

Process: I created a technical design of the required system using Miro to visually represent it. To verify that this design would work for the team I passed it by those who would interact with it, and after ironing out some potential kinks, I started implement it based on the design. The Image below shows part of the design in the program Miro.

Implementation: The goal for setting up the architecture was to create a robust foundation for the AI, centralizing functionality to a set number of functions to make debugging and adjusting the behavior easier. To-do this, I set up the following: states and state flow in a "root" behavior tree from which other trees branch off, state classes used to abstract away entry and exit functions, a function that handles all the steps of switching states from entry and exit functions to specific transitions between states, and lastly, a specific function that handles the conditions for and timing of switching states.

The functions that leave nothing to the imagination, such as setting the state, are handled in C++. The rest was developed in Blueprint to ensure that our AI designer and other that would need to look into it could figure everything out on their own without having to diving into the code.

Process: For the group behavior in our game, I implemented a token system where an AI can only perform an action if it possesses the relevant token for that action. I referenced a token system that was introduced to us by a lecturer. I built the foundation of our system based on his explanation of the concept and made adjustments where necessary for our project. I received feedback from him on the functioning of the system and from the team on its clarity, specifically the level designers, since they would be placing "groups" in the level.

Implementation: The design, as seen above, has evolved over time but remains fundamentally the same. There are token maps on individual AI and on the Group class they belong to. Certain events during the game, such as making noise that an AI hears, triggers the group to release an investigation token to a specific AI based on a set of checks. The group manages the releasing, returning, and general group-controlled behaviors, like triggering aggression in all AI in the group if one of them spots the player.

The core of this system was implemented in C++, with more specific checks, like determining who receives a token, handled in Blueprint for easy accessibility by designers incase it needed changes.

Process: The audio perception was mostly developed during the prototyping and preproduction phase, where we were not 100% sure of everything we would need. I ensured the AI could only hear the player when it made sense, and I made it easy for developers to add an audio event to anything they were working on, such as the gadgets in our game. I passed my work by the AI designer but also double-checked with Level Design to verify that I wasn't missing anything in the context of the level, as some areas might require more thorough checks that I may not have take into acount yet.

Implementation: The video above shows an early version of the system where the wall and roof block the noise, and the path around it is too long. For a more recent example, refer to the video shown in the upcoming suspicious state section. The audio perception system I developed for this has the following checks:

Process: I worked on all of the suspicious/investigation state behavior with our AI designer. I created all of the functionality and some of the design for this while staying in close contact with the designer during development, they were busy working on another aspect of the AI at the time. I went through several iterations by going back and forth with my designer and also by applying feedback based on playtesting data.

Implementation: The result, as seen in the video above, was an AI that turns towards a sound or something it saw, performs a voiceline, and then moves in to investigate the source. To get the point it needed to walk towards, I used Unreal's EQS (Environmental Query System) to get a point in visual range that is close to the AI and the source but not right on top of the source since that looked weird. For group behavior, we added an extra voiceline that nearby AI would use as a response and implemented a token system to ensure only one AI investigates. When the AI with the token starts investigating, the other AI that heard the noise will return to their normal patrol routes (might still change, WIP). In the video, there was a "scripted event" which got broken up by the thrown bottle, after which they went to their predefined stationary guard spots, hence why one of them moved away from the noise.

Process: Since the AI designer was busy with other tasks and I wanted to delve into design, I first began by researching how other games managed multiple AI in combat. I referenced games similar to ours such as Assassin's Creed Black Flag and Dishonored 2. I took note of aspects like how their AI surrounds the player and the timing of their attacks, evaluated why they implemented these mechanics in their respective games, and assessed their suitability for our game, making adjustments to the design as necessary. Finally, I compiled my findings into a visual representation wit text explaining the behaviour on Miro. After running it by our AI designer (since she had the final say) who agreed with the design, I also created a flow diagram for the required behavior tree. This help me implement it faster and with less problems along the way

The image below shows a segment of the design I created on Miro as a visual aid for explaining it to others. The second image depicts the flow of the behavior, which, aside from some additional checks, remained consistent in the final implementation.

Implementation:
WIP
The video below shows the current version of the Group Agro Behaviour in action. It still needs some itterating at this point to feel good but it still represents the design I made for it. The main points being: