Goblin Deep Dive

Ashes of Creation is an MMORPG made by Intrepid Studios.  During my time at Intrepid I contributed to many game systems but spent the most time creating combat NPCs for the world.  The team was design-driven so each designer was responsible for owning their respective work end to end.  With that directive I had to inject new or work with existing ideation to deliver a variety of gameplay experiences.

The Goblin family of NPCs is a great example of that process.  With over 14 distinct creatures in the family, each with a diverse set of behaviors and pacing, they engaged players in a unique way compared to other NPCs in the world.

Design Constraints

While NPC design was very open ended it came with a set of constraints.  Any NPC needed to limit the number of abilities it had based on scope and its use in the world.  This meant that something like a simple animal would not be reasonable to design with a large ability set but would be for a world boss since each part meant devoting downstream scope for supporting teams such as animation, VFX, and audio.  Each enemy NPC design needed a reasonable ranged attack if applicable, stat distribution, and had to include elite ranks which are scaling stats for difficulty separate from level based stat progression.  If there were existing character assets and animations then it was encouraged or required to use what was available if there were resource restrictions.

In addition to ability scope and stats there needed to be available design space for evolutions, demotion, or retirement options to live alongside world progression. Evolution as a system was a replacement of an NPC in the world with a more advanced version of itself based on the world progression.  An example of this would be a simple boar in an early game play space would not appear later in a different, more difficult space but instead there may be a more advanced dire boar there instead with a similar move set but would include new abilities or mechanics.  If evolutions or variants were not feasible then there needed to be identified points for demotion, lowering a creature’s elite rank in a new area but higher level, or retirement by no longer including that specific NPC design in the world beyond a certain level.

Goals

While the goblin family of NPCs evolved with the lifetime of the game it all started with an extensible set of goals:

  • Use the existing goblin character art and animations as much as possible

  • Each goblin shares a family trait or gameplay mechanic

  • Each goblin provides a different gameplay style if able

  • Each goblin functions as a standalone encounter or part of a group encounter

  • Across all goblins there is representation of different damage types or effects

  • Goblins should be funny and not so serious

The goblins came with a set of character art and animations from earlier in development so I earmarked anything viable for use after review of the assets with some leeway for any minor bugs that could be fixed in iterative passes.  With consideration for the economy and gear design the goblins as a family should have a mix of physical and magical damage output and defense and employ a variety of effects whether bespoke or shared with other designs.  After accounting for those factors I wanted to have each goblin’s ability set create a different gameplay scenario so that each goblin felt different in combat.

Design Documentation

Each NPC design starts with a game design document (GDD) that is used to flesh out the full design of a character and used as a guide by other team members to inform their downstream work.  The GDD covers all the relevant information for the NPC including their design goal, appearance, world placement and dynamic world considerations, idle behaviors, disposition, ability list, and spaces for lore and audio information.  I also include visual reference for the various ability, appearance, and behavior descriptions when I am able to find strong visuals to help convey the concepts more clearly for collaborators.

The first three goblin designs were the base goblin, goblin shaman, and goblin flayer.  The base goblin provided a straightforward, fodder enemy with some basic melee attacks.  The shaman provided high magical damage, area denial with a debuff, and a support buff.  The flayer fills the role of a heavy bruiser with high damage and sweeping melee attacks but with a slower than normal movement speed.  Individually, each goblin functions as a singular encounter.  Together in a group they create a complex encounter due to the different gameplay styles they promote.

Family Behavior - Rally

As I iterated on the initial goblin designs I leaned into the primitive, tribal style of the characters and made their shared family ability a warcry called Rally.  When used in combat, Rally causes the goblins to yell and chant aloud and any other goblin within range would be triggered to do their own Rally causing a chain reaction.  Any goblin triggered by another goblin’s Rally would enter the combat encounter of the initial goblin.

Rally by itself helped tie all of the different goblins together interactively but each goblin needed something more to help them stand out from each other.  In addition to Rally I gave each goblin design their own combat ability to use immediately following Rally.  Each ability added new gameplay mechanics to the encounter and are visually distinct.  This created a drastic change in the moment to moment gameplay for the goblins from a standard encounter in a chaotic battle that scaled with the number of goblins involved.  The Rally mechanic paired with unique abilities helped give the goblins the feeling of a frenzied tribe that was well received during playtesting feedback.  From then on, all goblin NPC variants received their own Rally ability as part of their core design so that they would all share in the family behavior.

In-Engine Workflow

After the GDD is approved work moves to in-engine.  This starts with creating the NPC character’s blueprint, ability montages, and behavior state trees.  Organization is important because moving or renaming files in Unreal under source control can be complex and have issues especially if someone forgets to fix up redirectors.  Creatures like the goblins get their own folder in the NPC hierarchy organized by type, the base folder for their character blueprints and subfolders for ability animation montages and state trees respectively.  Inside the character blueprint is character data that needs to be filled out such as the skeletal mesh, stats, nameplate, and targeting reticle scale.

Once the character blueprint is made and its data filled out correctly then the next thing to create are the ability montages.  Animation montages require a skeleton when created and this skeleton can not be changed.  When working ahead of character art or animation this means needing to coordinate with them for an existing skeleton or having a stubbed in skeleton file that those teams can later update.  Trying to use a different or placeholder skeleton may mean having to recreate any montages that were incorrectly started.  Each montage would then need to be filled in with the appropriate animation sequences with sections, timing, curves and root motion adjustments as needed.  To finish the ability montage correctly, animation notify event triggers need to be added in the timeline layers to activate functional and polish necessities like AnimBP or gameplay logic.

With the ability montages complete the next step is creating the ability data. In Ashes of Creation this was done with custom tooling and data files.  These files controlled the linking of ability data to a creature, its ability animations, ability costs and targeting, and event triggers when abilities hit a target and what gameplay effects occurred from those hits.

State Tree Behaviors

To finish making an NPC functional it needs to have a state tree and state tree behaviors.  The state tree is hooked into the state tree component on the character blueprint.  Inside an NPC state tree are hierarchical states with tasks, conditions and transitions used to drive the character’s behavior logic.  Parameters and evaluators are also added to help gather and evaluate data to inform runtime decisions in the state tree.  This process is sped up by the use of modular state trees and a template state tree that covers the implementation of NPC behavior that is shared across all NPCs and needs to be maintained identically.

A typical NPC state tree is broken up into 5 sections: Spawn, ambient, combat, leash, and death.  Spawn behaviors are unique to specific NPCs as not all characters need to trigger special logic on spawn.  

Ambient behaviors encapsulated all of the possible behaviors an NPC is capable of doing while alive but not in combat.  All of this logic can be genericized and encapsulated into multiple external state trees containing behavior logic for idle, patrolling, wandering, environment interaction, and NPC to NPC interaction.

Leashing behaviors can be mostly shared between all NPCs and can be templated into an external tree.  This includes resetting common combat related values such as stats, effects, and ability cooldowns back to their precombat state and movement tasks to return the NPC back to their originating location.  Custom movement and behaviors would need to be executed before the general reset as well as adjusting special values in an NPC’s animation blueprint that match their precombat state.

Death behaviors are also mostly shared and templatized into external state trees.  These states signal to other game systems that this NPC has finished dying and is available for loot or clean up.  Some NPCs may have predeath related behaviors like a self revive or explode on death that can run before the state tree is marked complete via a tree succeeded transition.

Combat abilities are mostly unique per NPC and they get their own behavior states or sequence of states with appropriate tasks, conditions, and transitions to meet the gameplay design.  For the goblins this means having some states for managing their basic attack spam and high frequency abilities, individual states for special abilities with longer cooldowns, and a state sequence for Rally and their unique Rally ability.

Feedback and Iteration

On Ashes of Creation the Enemies team would regularly playtest and review our work in compiled builds on test servers.  While not a replacement for individually testing your work it helped us gather feedback from other team members in a predictable environment and enabled everyone to see the product of their work, how it was implemented, and make calls on what needed iteration or bug fixing.  For the goblins that included a variety of small and large feedback items, some as small as minor polish to as large as an entire ability being replaced.

The base goblin’s original Rally ability got many iteration passes but was still found to be visually unclear and lacked readable impact feedback when attacking a player.  That ability was cut in favor of a more visually iconic Rolling Headbutt ability that performed better during playtesting.  Another general feedback point for goblins is that they felt too small and were hard to see. Player cameras were generally kept above and behind them which meant the player’s own character model would obstruct the smaller goblin meshes.  To address this all goblins were uniformly scaled up 50% and efforts were made to iterate on all current and future ability animations to have strong variations in their movement and silhouettes to increase visibility.

Conclusion

All in all there are 13 completed and shipped goblin designs, 6 in progress, and many more slated for initial design passes.  I took the goblin from humble beginnings as an early development character into a full-fledged faction that was used to define the starting experiences for the majority of players in Ashes of Creation.