SQYD.studio

Hello anyone! I’m back. Bloggin’ fast and loose with another edition of Refactoring Gobland. This week I’m going to explain what a Goblin is. Not in an abstract way- we all know what a goblin is even if we can’t perfectly articulate it- but in a game dev way. I want to walk you through the major custom Unity components that power the Gob’s of WOFG! I’m going to present each one, try to explain how it works in the demo- and how I want it to work in the refactor. I’m not going to get super technical but you’ll probably get more out of this if you have an idea of how Unity GameObjects and components work. Let’s dive into it.

Goblin

The Goblin component sits at the top of the goblin’s hierarchy. In the demo the goblin is tracking a bunch of miscellaneous stuff that didn’t seem to fit elsewhere. The goblin’s appearance, stamina, team, KO state- just a messy grab bag of variables that the other parts of the goblin use to determine behavior. In the rework the high-level goblin will (hopefully) be a lot less complicated. I plan to use it to create a custom editor that can be used to setup all the other goblin components through the inspector. At runtime the goblin will be responsible for initializing all the other components and injecting them with their dependencies.

IInturpreter – i.e. GoblinController or GoblinBrain

I’m using an IInturpreter interface to get input data and pass it to the other parts of the goblin for processing. In the case of the GoblinController this is the player input from the gamepad (or keyboard- which I understand some people like to use for some reason). The GoblinBrain will also produce input for the other parts of the goblin- based on some NPCBehaviour scripts that I’m not going to get in to now. The idea is we want the NPC goblins to play by the same rules as the player goblins. This pattern is in the demo build now- but was based on abstract classes and inheritance. Using an interface has cleaned it up a lot in the refactor.

The GoblinController also connects to a GoblinCamera component that manages interactions with Cinemachine– I’ll leave it for another day as it’s not really part of the core goblin.

GoblinActor

This is the component that controls how the goblin behaves. Movement calculations, commands for jumping, dashing, attacks, and grabs are all held by the GoblinActor. We’ve setup the character controller using a Rigidbody rather than the Unity’s Character Controller component- though I imagine the character controller component would work just as well. The goblin actor is responsible for what the goblin does.

GoblinHand

Goblin hands are managed by the GoblinActor. Really they track the grab state of the hands and take care of attaching joints to the rigidbodies the goblin grabs. They also have functionality that lets them connect to the IK components (brought to you by FinalIK) so we can nudge them around towards nearby grabbable objects. I’m honestly pretty happy with how the goblin hands are working right now- probably won’t change to much in the rework.

Goblin Behaviour

The GoblinBehaviour is the main way we control our active ragdoll. We are using the fantastic Puppetmaster Unity asset by Rootmotion to blend our animations with the goblin ragdoll. Puppetmaster uses behaviors to control the forces that sync the ragdoll with an animated target. Our GoblinBehavior is a fully custom subclass of Puppetmaster’s BehaviourBase which we use to shape how the ragdoll interacts with other objects in the scene. The version in the demo is pretty messy, and leads to some weird “snapping” behavior- I want to rethink this component heavily during the refactor.

ProximityDetector

This is a component that tells the goblin what’s around it. It’s a combination of a trigger collider that can detect nearby rigidbodies, and a raycasting apparatus that sends raycasts out to check for the ground and other nearby objects. In the refactor I’ve already reworked this component to schedule RaycastCommands between FixedUpdate calls. I think I’ll probably continue extending it to provide raycast information to the GoblinBrain component when it comes time to dive back into the goblin NPCs.

GoblinAnimator

The GoblinAnimator does two things. First it tracks the current state of the Goblin’s animator and updates settings in the GoblinActor and GoblinBehaviour based on the current animation playing. Second, the GoblinAnimator is responsible for updating the animator parameters that determine what state the goblin is in. This is the main component that’s causing performance issues in the demo build. Currently, each and every animation parameter is being updated every frame. This is worse than it seems- there are more parameters than their needs to be and the Animator currently has references to both the GoblinActor and the GoblinBehaviour so it can ask them for how the animation parameters should be updated. I think this is the messiest of the prototype code in the project right now, and is a big target of my refactor. My solution is the GoblinState.

GoblinState

There is no GoblinState in the the demo build now. This is the main change to the whole of the how the goblin works in this refactor. Currently all the components mentioned above reference each other and rely on public properties to manage their internal state. It is a cesspool of code smell.

GoblinState is my fix. If I wanted to get all fancy computer science about it I’d call it an example of the mediator design pattern It’s not even a MonoBehaviour- just a normal old C# object. The Goblin creates it and passes the GoblinState to all components that require access on initialization. Each of the components can then read the information they need out of the GoblinState- and write the information they provide to the GoblinState as needed (usually in their FixedUpdate call). GoblinState tracks this information in private structs that can be accessed through public properties as needed. GoblinState also has a reference to the goblin’s Animator. When it’s variables are set by the other components the GoblinState checks if the variable has actually changed and sets a new animation parameter only when required.

Okay folks, there’s the a quick rundown of a goblin. Greatly simplified and a bit scattershot, but hopefully gives you an idea of what this refactor entails. I think it will make a big difference in terms performance. Progress is slower than I’d like- it always is- but I think we will be able to clean up some of the bugginess and add some new features to the goblins to boot. I think we are probably still a few months away from introducing our reworked goblin to the demo build- but I promise you it will be worth the wait.

Thanks for reading. Until next time- Watch Out for Goblins!