Our process began with a discussion between myself and the creative members of my team about the needs of the movement system. At the end of the discussion, we settled on three main mechanics: dashing, floating down and flying. The major concern was about how to achieve the jumping, floating and flying mechanics without them competing for ownership over the spacebar.

Overarching movement structure.

Aside from the explicitly agreed upon mechanics, I had a lot of discretion to handle my own technical implementations in pursuit of our design goals. One of the first things I did was make the character capsule hover and smoothly bob up and down upon falling onto the ground. This greatly reinforced the fairy-like feel. I also incorporated important quality of life mechanics which I was already familiar with like coyote time for jumps. Additionally, I took it upon myself to research even more advanced quality of life mechanics such as directional momentum, ground-clamping and collision sliding. Directional momentum made the player feel less jittery when changing directions quickly, as if they had a small amount of real weight to them. Ground-clamping aligned the player’s horizontal movement direction parallel to the ground directly beneath them (except when in the air or on extremely steep terrain) in order to ensure they maintain normal hovering height while moving up or down inclines. Collision sliding worked in tandem with ground-clamping, ensuring that the player slid down against steep inclines instead of becoming inexplicably stuck to the ground. All three of these additions significantly enhanced game feel and removed friction from the overall experience.

Our design vision for the combat system evolved in small steps over the course of development. The initial plan for melee was that the player could combo up to three attacks before needing to wait for a small cooldown. This was scoped down to two attacks so our animator could focus on more essential work. However, this change of plans was not a problem for me since I designed the melee system with an emphasis on scalability so it could support any quantity of combo attacks if provided the animations for it.

Since I was given full implementation freedom over this system, I decided that real-time attacks which register damage along a weapon’s swing path would benefit game feel greatly by adding a spatial element to the melee combat. Fortunately, I was already familiar enough with melee combat design to know that volume casts must be performed between the previous and current locations of a weapon on every frame of an attack in order to ensure a hit always registers. The chance of a large frame rate drop causing a registration gap necessitates this. While writing the implementation, I realized I could make it accessible to our designers by performing the volume cast across two points on the weapon prefab. That way, they were able to simply move the two points around and balance the attack range with ease.

Airtight hit registration via capsule casting.

During playtests, I noticed that players struggled with aiming melee attacks because the swing path never traveled directly through the crosshair. This was due to the simple fact that the third-person camera was offset above the player, thereby elevating the crosshair above the swing path. I hatched an idea to fix this by continually raycasting through the crosshair for the duration of a swing, getting the point where the current raycast intersects anything in the world and then tilting the player toward the intersection point. This solution worked elegantly to resolve the issue by ensuring attacks always swing at whatever the player is trying to hit.

Overarching melee structure.

The next step was to add a shockwave ability. This was an explosive ability that the player could activate to damage and knock back all enemies in their immediate vicinity. At a later date, I took the extra step of turning shockwave into its own class and system so that it could be spawned by anything. Doing this expanded its use potential beyond just serving as an ability and gave designers more options for future gameplay mechanics.

Interface for the shockwave ability.

On top of the melee and shockwave systems, our initial plan included a secondary ranged attack for a more dynamic combat playstyle. At this point in development, I felt that the gameplay was still very limited and could benefit greatly from a balanced weapon variety. At my suggestion, we expanded our combat design to give players a choice between four different weapons. The weapons had identical melee functionality, but their ranged attacks featured different projectile behaviors each with their own benefits in practice. The variety I programmed was a throwable spear that travels straight, a throwable mace that arcs heavily with gravity and emits a shockwave upon impact, a magic staff that casts exploding fireballs which travel straight, and a throwable spinning axe that returns like a boomerang and bounces whenever it collides with the world.

Overarching structure of the boomerang axe.

My initial weapon-switching implementation involved items on the ground that could be picked up using the interact key, but this code was later repurposed into a more interesting weapon rune mechanic. Because my code was written modularly, it was already compatible and required no changes.

Weapon Variety

Since I was in charge of both movement and combat, the responsibility of learning how to fit the animations into these systems fell onto me. Figuring out how to structure the animation graphs and fit them into my code was actually an intuitive process. I utilized blend trees to make the moving and dashing animations blend with each other when using the intermediary WASD angles. By the end of it, the player’s animation graph was fully puppeted by their movement and combat scripts.

After setting up the animation graphs and walking blend trees for the golems, I worked with another engineer on integrating them into his state machine code. This process required a little more involvement, but we cooperated closely and were successful in bringing the golems to life.

Player Animation Graph

The deadline was approaching and the need for a system that could streamline the development of a tutorial level became critical. I began with the very basic concept that everything required to happen inside an FTUE could be achieved through the simple tasks of enabling, disabling, destroying and teleporting objects that were already pre-placed inside a level.

I split the overall design into two scripts: one for tutorial objects and one for the tutorial manager. Tutorial objects were separated into two types: touchable and destroyable. Touchable objects trigger their event when touched and destroyable ones trigger when destroyed. Additionally, I included options to make a touchable tutorial object single-activation or exclusive to a list of activation targets. I made these choices with the consideration that certain touchable triggers should not activate multiple times and should not be susceptible to unintended activation. For example, a touchable object intended for activation by the player being set off by contact with a projectile instead.

Event Querying

The tutorial manager script acts as the hub for storing a list of every allocated triggerable event by name. Each event itself contains a list of tasks. Every task has an assigned type (enable, disable, destroy, teleport) and target object. Through deeper consideration, I realized that an assignable “destruction group” was also necessary so that events utilizing it could only be triggered when all objects in the group are destroyed. This feature made it possible to restrict progression until common gameplay goals are achieved, such as killing all enemies or collecting all items in an area.

Event Management