Small Team Project - P1 Games Covenant

Floof

Floof

A 3D treasure hunting game that players vacuum up chunks to find treasure and face off monsters. I joined in the late development phase, yet improved various fundamental gameplay elements.

Play on Itch.io
(Uses Keyboard and Mouse)

Play on Itch.io
(Uses Keyboard and Mouse)

Play on Itch.io
(Uses Keyboard and Mouse)

Overview

Overview

Overview

During my time at the Covenant program, I helped out in a 3D game project that involves treasure hunting action under procedurally generated rooms. I helped out in the 3D pathfinding system for enemy AI to travel anywhere in the open air and then fixed the movement controls to allow jumping. Despite joining in late in the project's development phase, my contributions helped make the game as good as it can be.

Contents Table

Contents Table

Contents Table

Programming

Programming

Programming

3D Pathfinding for Enemy AI

Pathfinding is a fundamental aspect of navigation and used in video games, both in 2D and 3D. From my previous experience with 2D game projects with pathfinding, doing that in 3D is a step up and requires more nuance in neighbor checking to not cut corners. With AI movement in 3D space, they are adaptive to changing space, such as the floof blocks being vaccumed away.

2D pathfinding have at most 8 neighbors to check, with X and Y axes, orthogonal and diagonal. With 3D pathfinding, the number of neighbors count up to 26, and all directions of X, Y, and Z axes, alone and combination, must be checked. Additionally, 3D pathfinding requires more checks, especially with single and two axes repeated three times, to to ensure proper pathfinding and to avoid cutting corners.

I begun the 3D pathfinding process by adding checks to all 26 possible nodes, with two axes being done first, and then three axes. I thought that alone would solve the problem of complete pathfinding coverage. I even created a visualizer tool that draws lines across the grid for valid AI moves, including potential issues.

Get Neighbor Nodes - Function

Get Neighbor Nodes - Two axes check

Get Neighbor Nodes - Three axes check simple

However, there is one flaw from the simple approach: the enemy AI unit cuts corners at diagonals, which makes the enemy simply move through solids. Therefore, the 3D pathfinding algorithm had to be improved.


Looking closer and discussing with a colleague about the pathfinding, I did succeed with two axes check, but having three axes check alone was not enough, as there must be three pairs of two axes check.

Improved Get Neighbor Nodes - Function

Improved Get Neighbor Nodes - Two axes check

Improved Get Neighbor Nodes - Three axes check with double axes pairs

When the pathfinding code has improved, the enemy AI will always move around solid obstacles, and no longer cuts corners. I enjoyed the process of implementing 3D pathfinding to better understand the difference between 2D and 3D.

Fixing Player Movement

After implementing the 3D pathfinding, the team wanted a programmer to fix up the movement controls since the player cannot jump, which was not implemented within the existing movement coroutine. When I accepted the task, I picked up the movement code improvement where the other programmer left off.

Player Movement - Before Revision

When refactoring begun, I looked into SimpleMove through Unity documentation, as it is part of the character controller, and learned that SimpleMove ignores changes in Y movement from the program except for height slope. Meanwhile, Move does allow changes in the Y value, which is required to allow the jumping to work. After jumping worked, I added in other variables to ensure a proper jumping in 3D such as gravity to make the character fall as the player object has no dynamic rigidbody and runs entirely on collisions. With a tight deadline for release, I did not have much time to do any other polishing for the jump, especially with the collision from above to make the player stop gaining height to then fall down.

Player Movement - After Revision

Additionally, changing from SimpleMove to Move resulted in the player character moving faster when using integer numbers. Additionally, the movement update needs to have the Time.deltaTime since the movement needs to get away from framerate dependency, which was a big problem until I addressed the movement system. The only way to truly adjust the speed to match the one form SimpleMove with the Move is through play testing. I adjusted the numbers from high digits to lower number values at floating point, but kept the gravity and jump power at reasonable integer values to give illusion of a good jump that makes the player go up two blocks. I felt content with what I have made in spite of the sudden changes to the release date being pushed back.