ANDREW SIPES
GAME DEVELOPER

WaxHeart is a puzzle platformer where you play as Waxboy with a lantern for a heart. You'll journey through a dark in search of your lost memories encountering many monsters, mysteries and challenging puzzles.

Teaser Trailer

Platform: PC
Playtime: TBD

Engine: Unity

Role: Software Engineer (Unity)

Time On Project: Nov 2024 - Current

Team Size: 20-30

Website: waxheart.info

Steam (Free Demo!): Steam

MY ROLE

Contributed to code base by taking Trello cards on new Features, and Bugs
Participate in play tests and provide feedback to help improve gameplay and identify bugs
Participated in Git Workflows, and Code Reviews to ensure clean code was added to the game
Work with design team to bring new features and improvements into the game.
Attended Engineering Department meetings to discuss current progress, Sprint Planning, and discuss improvements / changes to the development team process

This task required me to take the FBX and split it by frames and blend it into the player's animation blend tree and move the capsule collider down during the blend.
When implementing the animation, I found the capsule was not moving with the player as expected.
Essentially the player would enter the animation leaving the capsule behind and ending up half way down the ladder before the capsule would lock into the correct location and then the next animation would play resetting the player

When implementing the animation, I found the capsule was not moving with the player as expected.

The player would enter the animation leaving the capsule behind and ending up half way down the ladder before the capsule would lock into the correct location and then the next animation would play resetting the player

There were steps needed to resolve this issue:

First I split the Clip into 2 pieces, the start transition, and the move down animation
The Start Transition was the first 28 frames, and the move down sequence was the last 8 frames
Next we updated the Transform positions for each clip, we needed the Y-Position baked into the Start Clip, but not the Move Down Clip since we were moving the capsule independently of the animation.
I also needed to update the XZ position to be based on the center of Mass to ensure the player was properly positioned on the ladder.

With 2 Separate Clips requires 2 separate States in the Animation Controller, with some changes to the Animation Controller, this is the updated logic:
- Start ENTER_LADDER_FROM_TOP state
- On Exit, Transition ENTER_LADDER_FROM_TOP_MOVEDOWN
- On Exit, If (isClimbing) Transition to CLIMBING_LOOP

The last piece was the Climbing code to support the player entering the transitions properly.
- Lines 15-20: When climbing is triggered (assuming player is above the ladder), we look direction and rotation based on the ladder, the target rotation (facing towards the ladder) and the starting position and rotation of the player
- Lines 22-26: We're using a tween here to smoothly transition the player to face the target rotation
- Lines 28-40: After the Tween completes, we're following up by having the player face the edge now, and play the ENTER_LADDER_FROM_TOP animation state, then start climbing

The Final Result is now the player seamlessly transitions onto the ladder and begins the climbing loop

In the dark forest level, the level design team is implementing pressure plates that are used for activating / deactivating doors, platforms, or columns as part of the puzzles in the game.
This task specifically was to update the system to check which object is on top of the pressure plate, then only activate if a proper object is on top. Before this change, a player could activate a pressure plate with physics if a object with enough mass was placed on top of the pressure plate.

BEFORE

AFTER

In the above example, you can see the platform turns Blue. This means the Pressure Plate has been successfully activated. The object on top is a standard Unity 3D Square, with a rigidbody.

For this to feel like a proper pressure plate, we should still see the pressure plate be pressed, but it should not activate with an invalid object. After the updated changes, the right reflects the correct behavior when an invalid object is on top.

To accomplish this, we needed a modified version of our compoundTriggerVolumes. CompoundTriggerVolumes in this project are designed work similar to normal Triggers, but with unique shapes such as if you needed an 'L' shape Trigger.

The below code is from the compoundTriggerVolumeClass, here we can do specific checks if the player is inside the volume, but no other objects such as a pushBlock or a monster.

To add functionality to this class, I created a child class that would inherit the compoundTriggerVolume logic, but add additional logic for other objects.

A hashset to contain unique objects in the TriggerVolume
CheckForObjectOverlap(), which can be used for a one time check for new objects or current objects, which will update the hashSet
IsValidObjectInVolume() as a public function to return if there are valid Objects in the volume
Updated OnTriggerEnter and OnTriggerExit methods to call the base class method, and add / remove valid objects from the hashSet when they enter the trigger volume.

Now that there is an updated TriggerVolume class that we can use to determine if valid Objects are within the volume, I needed to update the pressurePlate to use this new functionality.

Essentially, in FixedUpdate(), each frame we check to see if the plate's position is below it's original height (meaning physics has pressed the plate down).
lines 30-31 will now check if the plate is not pressed, and use our new method in the TriggerVolume to determine if a valid object is in the volume. If we pass these checks, then the original PressurePlate logic can proceed
Line 37 is checking the inverse, if the plate is pressed but there is no valid object in the volume, then we can unlock the plate and presume it should not be activated.

In the final level in WaxHeart, the level design team is planning some puzzles requiring moving platforms. Prior to this design change, boxes would move on the platform but they were not interactable with the player.

Objects the player can interact with all derive from a Base Interactable Object, allowing the logic to be similar between them except for special cases. With Boxes, we have the player attach to the box, and the box moves with the player's input. The interaction system does not take into account the platform velocity, and in it's current state would separate the player capsule from the box triggering our break distance (maximum distance allowed between the player and the box), forcing the player to revert to their normal non-interacting state.

Based on this behavior, I was able to infer the following:

The player was not moving with the box as the platform moved
The Box was not attaching to the player
The platform was moving too quickly for the interaction to occur.

To get a better understanding of how the system was working, I started to track velocity of the player at various points of the interaction process:

Any time velocity changed
When the box was "moving" with the player

I started noticing several points where I could see the velocity being set to zero, which indicated that either the velocity of the platform was not being applied to the player or it was being set to Zero explicitly.

Using Unity's Stacktrace from the Debug logs entries, I was able to locate where velocity was being applied to Zero.

My investigation led me to the CharacterMovement Script, where we update the the player's velocity using the UpdateMovingPlatform Method, here we're calculating from the RigidBody, assuming the player is on a Rigidbody based platform. Since the Platform system we're using is Rigidbody, I was able confirm in the code (and visually), that this code was applying velocity to the player.

This led me to think - "What if the player's velocity is being set to 0 during the time of interaction?"

I started to follow the interaction logic and found that the Player Interaction Logic is doing the following:

Using interaction states based on the time in the interaction process (Enter / Interacting / Exit)
- These states control animation and the location of the player during the interaction process
When Debugging I found the referenced velocity variable was being set to Zero during the first Entering state, this revealed why the player capsule was not following the interaction object

In order to resolve this, I made a few changes:

I updated the velocity calculation to use the currentInteractionObject's velocity.
Since the Base object does not have a velocity, and we do not always expect there to be a velocity I created a method called GetInteractionObjectVelocity
- This Method will return Vector3.Zero for objects with no rigidbody (on the base class) which could be overridden in the child classes to the return the rigidbody Velocity, if desired.

After this was resolved, I found another issue when the player would attach the box, they would appear out of place/ position, and their arms would warp

This was due to how the position of the player was being calculated when entering Interaction, before we would lerp to the target position which was set determined before the Interaction started (on the object).

With moving platforms, this location has to be updated on every update call to ensure lerp moves the player into the required position, a small change to consistently updating this value during each update call to the current interaction's objects transform resolved this.

BEFORE: AFTER:

ANDREW SIPES GAME DEVELOPER

Teaser Trailer

ANDREW SIPES
GAME DEVELOPER