The Thief's Trail

The Thief’s Trail is a gameproject that created over the span of 7 weeks. In the game you take on the role of Alexis. Your goal is to make your way through the game, past the minotaurs that are after you.

My role during the project was creating an AI, Character Movement, Implementing Animations, scripting World Events, implementing UI and scripting Character Abilities. Modularity in the scripting was key as it allowed me to reuse code and quickly create states for the AI, Buttons for the UI and subtitles for the game. Public variables were also important in order to create an easy workflow for the Level Designers.
Project Information
Lead Scripter
UI Designer
Game Designer
Team Size
4 Design
6 Artists
Unity 5.6
SVN Tortoise
Production Time
7 Weeks
Role Playing Game

Enemy AI

The AI was created with state machines at the core of the behaviour. This helped speed up the implementation of different types of behaviour. Whenever the state changes, the exit function of the current state is called. Then it calls the enter function of the new state and then the execution function of that state is called once per frame. This system allowed me to easily change variables between state such as run speed, animation variables, color of the vision cone and more.

The AI followed a very simple logic as shown in the flowchart. Variables such as walk speed, run speed, patrol points and idle points were all editable from the Unity Editor to help increase workflow. Collision boxes and raycasts were then used to determine if the player was visible, states would then change accordingly.

AI Watch State

If the player becomes unreachable via the NavMesh, the AI run towards the players last available location. It then watches the players movement waiting for it to become reachable. If the player is not reachable within a set amount of time, it runs back towards its original position and continues with either patroling its routes or idling waiting for the player.

AI Sound Information

Each player action sends out a sound value to the enemies nearby. The code then checks the distance between the AI and the player and determines if the AI should be alerted. Different actions produce a different amount of sound, as demonstrated in the video, the amount of sound emitted from walking depends on the speed of the player.

AI Vision Cone Detection

The AI has a vision cone represented by light to the player. The game object itself had an actual cone model where the mesh renderer component had been removed so that we could have an invisible collider on it. This collider would be the heart of the AI vision. As soon as the player entered the collider, a script would check to see if the player is in line of sight. If it were, then the AI would switch to the chase state.

AI Patrol System

The patrol system was based on game objects that were placed in the world by the level designers. The game objects were then added to an array in the editor and the AI would then walk through them in the correct order. Each game object’s position in the list could also have a corresponding idle timer in another array. This way the level designers could have the AI idle at certain points for a more human like behaviour.

Tooltips & Subtitles

The button tooltip were controlled by a class that had a static instance. By doing this there was only need for one tooltip in the UI that would have its icon and text changed whenever the callToolTip function was called.

The subtitles have a base prefab that is copied whenever a new subtitle is to be added. Upon instantiation, the text is set, the timer is started and the subtitle is placed slightly above any visible subtitles to prevent overlapping. The update function keeps track of the timer for each subtitle and the removes each one after the time is up.

Trigger Subtitle

Show Subtitle

Trigger Tooltip

Show Tooltip

Post-mortem & Takeaways

My biggest learning from The Thief’s Trail is the complexity of implementing a proper AI. While it was a lot of fun and a great opportunity to further my knowledge in state machines, it was a feature that required a lot of planning, scripting, testing and debugging. The state machines proved to be of great help. Because of the state machines, I could easily keep track of occurring issues, even if the AI script was long.

The behaviour of the AI needed tweaking for different scenarios in the level. Therefore, making public variables for the Unity UI helped the level designers change and adapt it on demand. A similar concept was used for the tutorial tooltip scripts. The level designers would only need one script to set which button the collider would activate and what it would say, no more. I believe in making scripts that are accessible by other designers and tweaked whenever necessary. It makes the job of the designers easier, quicker and more intuitive.

The movement of the main character was also a great challenge, having it feel good to use and sync with the animations took a long time to achieve. A big lesson I took away from this after the project was to always design movement and animations after a grid.
Back to Top