Blue Ashes

Check out the new open source library I recently started for Unity animator helpers. It’s aimed at giving you best practice options Unity is generally missing when working with the Animator system.

https://github.com/ashblue/unity-animator-helpers

Good combos in video games are insanely difficult to architect. When people notice that something is wrong they’ll say things like “The combat is floaty”, “Controls are unresponsive”, or my least favorite “Combat is broken”. Here I’m going to cover our custom combo system in Unity and the core programming principles behind it.

The Node Graph Planner

To date we have around 23 unique combat nodes for Coal (as pictured above). The resulting graph for maintaining it is pretty easy to use and magically gets optimized when everything boots up. That said let’s talk about how I failed miserably trying to build this thing 3 times before I came up with the current solution.

Originally I tried to put all my graph information into an individual file. After just three attacks I had 700 lines that I couldn’t maintain. After that I tried finite state machines (FSMs), problem is they weren’t easily editable and lacked the hooks I needed for meta data. When that didn’t work I moved onto behavior trees (BTs), hoping I could make it work. What I ended up with was around 100 nodes for around 14 attacks. It was better than all previous solutions, but still not what we needed.

After that I came up with what I call a Node Graph Planner. It’s a combination of an FSM and BT that allows me to magically traverse my tree to create simple maintainable flowing combos.

Full screen print of the finalized node graph planner above.

Architecture of a Node Graph Planner

I broke up my Node Graph Planner into several different pieces for a data driven design. I’ll try to explain what each piece is and how it works.

Action Node - Each individual node on the graph. These are used to indicate a particular attack is ongoing.

Parent Container Node - These guys are used to group individual actions. They also allow attached transitions to automatically be passed to all children. This is how we pass uppercuts to all grounded combos and slams to all aerial combos.

Transitions - The little blocks you see at the bottom of each graph node. These determine if a new node should be triggered or not. Each one takes a customizable input monitor. See inputs for exactly how those work. Transitions also support a delay which is extremely important for timed attacks.

Actions - Each node has an action that is executed by it. These determine what actually happens to the player and how they go about attacking enemies. 

Action Sequencer - To rapidly prototype and create new simple attack animations / actions I rolled a custom sequencer. It supports some really cool functionality like physics overrides, camera shakes, and other nifty tools.

Inputs - It should be noted that for the transitions I create a custom input library that wraps Unity’s 3rd party plugin Rewired. This way I’m now able to rapidly prototype different kinds of input monitoring beyond basic button up and down commands.

Lifecycle of an Action

Each action follows a basic lifecycle similar to the following numbered list. In addition to the following I made receive damage and hit hooks available so I could adjust attacks according to collected combat information. Allows us to only shake the screen when hitting enemies, only float in the air if actually hitting an enemy, and many other interactive environment applications.

Reset

Attack Begins

Buffer Monitoring - Monitors and stores the next valid attack before it’s enabled

Update - Continue until buffer is enabled or attack is complete

Attack Ends (also triggers on cancel)

How Long Did It Take

The short answer is “TOO DAMN LONG!” We knew this combo editor had to be rapidly customizable for new attacks and able to handle any kind of special move we threw at it (uppercuts, slams, dash attacks, ect).

For a couple months now I’ve been working on re-architecting many of the combat systems in A Dragon Named Coal. One of the systems that had to essentially be re-written from scratch was the artificial intelligence (AI) for NPCs. To rewrite the AI I broke up what was a simple reaction based AI. Into a more complex 4 stage system. The resulting project headed the video result. Each color is a team, with healers marked by an arrow, and regular units displayed as normal. You’ll notice that healers are eventually hunted down and killed over time due to the extreme aggro they generate when healing a unit. As expected the team with the last healer survives the encounter.

Above GIF shows the basic result. To see the debug data and shared relationships watch the YouTube video below.

So how did I create the above AI? Well we ditched the old crummy reactionary AI we had. The old system was pretty shameful when I recently re-played our old pre-alpha. I pretty much felt like I had created this.

To fix our AI we broke it up into a complex 4 part system.

Alarm System

Pathfinding

Targeting Filters

Team Manager

The Alarm System is responsible for determining when an enemy is encountered and if it can be seen. The coolest part of the alarms is they can send summon commands to nearby allies in a certain radius. Resulting in alerting their allies of an intruder.

Pathfinding was pretty complex. We had to break everything up into 3 categories.

Seekers: Recurring command to find, flee, or strafe towards a target

Links: Logic used for complex movement like jumping

Movers: Override logic for knockback, teleporting, ect. Anything that overrides seekers and links.

Each unit has its own aggro score and filtering library from the Targeting Filters. These are managed by the Alarm System in the linked unit data. My favorite part about this library is it can easily target units based upon health, distance, aggro, and even find groupings of characters.

The Team Manager is pretty simple, but it gives us the ability to designate multiple factions. This will really make a big difference with factions in ADNC that you can ally with or last out against.

Ultimately all the logic we created is useless on its own. To tie it all together I used a simple Stats object with the amazing Behavior Designer library for Unity. I had to write a few custom behavior tree commands for it, but the APIs carry the heavy load so they were all just a few lines of code.