Systems and Technical

I am the main contact point for creatures and most team members that need information on any creature tend to come to me. I worked to make sure that members had as much information available from wiki resources and documentation as possible. I worked extremely closely with specifically the engineering, player package, animation, and progression teams (but also others)

Utility AI Overhaul

Over a couple of months, after working closely with our previous lead engineer to outline UtilityAI - I spent time dividing up the 100+ creatures on the project and working to port them over to the Utility AI system.

Leading up to launch we had an AI system that simply selected random abilities fired off of the main behavior tree branch, this was negatively impacting AI in several ways:

  • Behavior trees were always ticking

  • No control over ability weighting decisions for different AI outside of using tag restrictions in GAS

  • Very difficult to do scripted abilities where AI needs to pause

  • No way to have AI account for contextual clues when making decisions like deciding different attacks or movement patterns

  • No way of making group decisions and no way of injecting new behaviors at runtime.

UtilityAI selects one of a list of possible decisions based on the highest score calculated for each. Each score can be modified per decision via a designer-selected list of considerations per decision. The decision is then selected and an action is performed. This allowed us to leverage a couple of new systems:

  • Insights - similar to EQS it collects data on various contextual clues before an AI makes a decision each time.

  • Command Procedures - worked together with engineering to workshop a solution to having AI do things as a group - one AI starts the procedure and the receiving AI executes it.

  • Dynamic Behaviour Updates - while playing we can inject new behaviours into an AI to give a more dynamic cause-and-effect behavior to special actions players are taking

    • For example in Dread Legion when you hit an AI with one of the bombs it sticks to the AI and it is given a new package with a directive to chase after the player and attempt to give the bomb back.

Example of an early UtilityAI Package

I setup a baseline for the decision packages with the following best practices:

  • The baseline score for every decision pack is 2.0 the value for the turn-to-face decision in the package.

  • Attacks should never be completely random

    • Random attacks can make balancing creatures very difficult because they don’t have a predictable DPS.

    • Variety doesn’t necessarily mean random - creatures can have a spread of attacks that rotate on depending on context without feeling predictable.

  • Make sure you don’t have two different decisions tied for the same score value AND the same considerations or the first one will only ever get picked.

  • AI needs to have certain strafing behaviors if inactive in queue occasionally so they still look active

  • Phase abilities for bosses should be set using gameplay effects as a kind of ticket to run them, the decision should always exist in the package but only become available when the AI has a specific tag

Utility Packages are additive so later down the line we broke up movement and attack packages into separate packages so we could additively swap them in across variants more easily:

More modern combination of different base IP classes and attack classes across a faction

If any creatures needed a behavior tree that worked outside of these parameters I created it myself and created a unique controller for it. For example the loot goblin the project didn’t need to make any decisions - just run away, so we created a custom flee tree for it.

GAS, Tags, and Best Practices

The whole combat team uses GAS, which includes player packages, weapons, echos and creatures. Our abilities as a whole use tags in a variety of ways that make tags extremely difficult to query or garner useful information out of.

So close to launch I worked with the player team to closely re-evaluate the way we were using tags a whole across the combat team and come to a decision about using a single tag to convey a single piece of information so we are more easily able to query things across the project for mutators and echos or any other cases.

This involved adding more tags that were appropriate and restricting various tag categories in the project so only myself and a few other senior combat designers were able to add parent tags (leaf tags with unrestricted children were left open for others)

Left previous tag structure, right modern tag structure