MindsEye
While at studio GOBO I worked on a brand new AAA IP directly embedded within the client’s team.
During my time there our team was point leading the core combat experience. Everything from Enemy Design and AI behaviours to Weapons and Player Abilities.
My personal contributions and achievements in specific were to:
Help lead the design the various enemies in the game based on client direction and implement their various behaviours via behaviour trees and defining combat related systems, while closely working with other disciplines in support of the final goal.
Design the various player abilities and lead dedicated feature teams all the way from prototyping to finalised versions of the ability while coordinating with other feature adjacent teams.
Help Level Designers design encounters and advise on level layouts and general best practices in order to get the best results for the various enemy types and improve the overall combat experience.
Some more in-depth examples of the work undertaken are featured bellow.
Combat Ticket System
In order to ensure that combat was not overly chaotic and overwhelming a combat ticket system was used that allowed designers to define the max number of enemies attacking the player simultaneously.
This essentially can be summarised to an AI given a window of opportunity to attack the player based on priority.
In more detail:
The max number of attacking enemies could be defined per enemy type, per encounter and difficulty level.
Priorities will be determined by various parameterised values that add up to a score. Some of these were be static (e.g: enemy archetype) while others will be dynamic (e.g: proximity to player).
Attack tickets were be categorised in Simple (using their main weapon) and Special (AI offensive abilities) attacks. These were finite and their number could be defined per enemy type, per encounter and difficulty level.
By default the ticket duration usually equalled the duration of the attack the AI would perform, however, if desired, design was be able to tweak the duration of the ticket per enemy type, per encounter.
Additionally, enemies were able to steal tickets from other enemies in certain circumstances, such as been right in front of the player but a ticket not being available.
Once a ticket was been used then it is released and it had a short cooldown period before it can be claimed again.
The overall functionality could be boiled down as follows:
AI requests attack ticket
If the ticket request score of an AI is higher than others they receive the ticket
The attack is performed and the ticket is considered used once the attack sequence is complete.
The ticket is then released and enters a short cool down before it becomes available again.
Enemy Destructible Parts System
Robot enemies had specific parts that could be destroyed independently from the main health of the robot to add more depth to target prioritisation but also enemy behaviours as destroying parts was intended to have a meaningful an impact on how the enemy reacted dynamically.
The main Goals of the system were to:
Provide the player tactical viable choices on how to best defeat a robot.
Gradually reduce the capabilities (but also potentially make them more aggressive) of an enemy.
Push the player to be resourceful with their skills and the given context (weapons, ammo, drone energy, position, aiming efficiency/ target prioritisation etc).
At a high level the system was as follows:
Every robot archetype had a predefined number of destructible parts, including limbs and robot specific attachments.
When destroying one of these parts, depending on the context and location of the part one or more of the following could happen:
Locomotion is impeded.
Attack & Movement behaviors are altered to some degree.
Any special abilities and attacks are disabled or impeded.
Damage received was usually multiplied.
Robots could be defeated even if not all of their parts have been destroyed.
Parts varied depending on the robot archetype but commonly included:
Arms - Limited some traversal types, made enemies more aggressive and caused held weapons to be dropped.
Legs - Would normally knocked down the enemy and would be unable to move but still attack with ranged weapons if available.
Head - Made enemies more aggressive and affected targeting behaviour.
Any attachments or particular areas linked to either abilities, weapons or archetype specific functionality
These were intended to have a visual design that is easily recognizable for the player
Additionally destructible parts had their own health values and their state was communicated with up to 4 damage states, form Undamaged → Damaged→ Very Damaged→ Destroyed.
The exact number of states can vary from part to part depending on the context of the archetype.
Every time a part is dealt damage then the base amount x the specified damage multiplier is detracted both from its HP and the main HP of the entity.
When the the HP of a part = 0 then the part was destroyed.
When a part was destroyed we would apply additional bonus damage to the main HP pool as a way to encourage taking the risk of aggravating the AI.
It was also important to balance the hp of each part so as to ensure the AI would be destroyed and wouldn’t become useless after having too many parts destroyed or losing all their attack abilities/weapons.