PRE-ALPHA I

During my first sprint with WolverineSoft Studio, I was assigned the task of implementing the patrol movement scripts for our charger enemy. Patrolling enemies are meant to change their behavior based on the circumstances. In their default state, enemies move at a constant speed for a set distance. Once reaching their destination, a new direction to move is chosen at random within a set angle from their current direction. If a minimum distance cannot be moved in that direction, another direction is chosen. This process continues until a valid direction is found. When pursuing or searching for the player, they perform virtually the same, with a few modifications. Pursuing enemies have increased speed and their default direction (from which they choose a direction to move) begins at the player’s location. Finally, searching enemies perform the same as pursing enemies, except a timer now counts down to when the enemy returns to its default state.

When I initially considered how to approach this task, inheritance came to mind. Searching enemies inherit from pursuing enemies, which inherit from the peaceful base class. However, while this is the case, it also overcomplicated a relatively simple problem. After some consideration, I decided that separating each of these behaviors into states was a more effective and straightforward approach. The enemy begins in a default PEACEFUL state. If the player enters its aggro range, the PURSUING state is activated, and once the player has left this range, the SEARCHING state becomes active. In hindsight, a transition between SEARCHING and PURSUING should also have been added to account for when the player enters the enemy’s aggro range while searching. I also wasted a bit of time by attempting to use Quaternions to determine movement direction and to change the direction of an enemy. Vectors are more simple to use and easier to understand for any future contributors, so I lost some time by making this adjustment.

State update loop

In order to maintain the studio’s goal of creating modular code, determining which direction the enemy moves was separated into its own script. While PatrolBehavior.cs depends on GroundDirectionChooser.cs, this is not the case in reverse, allowing GroundDirectionChooser.cs to be utilized in any future circumstance that may require the script. Serialized fields were also used in PatrolBehavior.cs to both keep scripts independent, and to allow a user in the Unity editor to modify an enemy's movement speed, hostile speed factor, aggro range, travel distance per direction, and search time. I also spent some time making sure my code was easily readable, well-commented, and met the studio’s coding standards, which took a bit more time than anticipated. As a student who is consistently rushing to make deadlines, I may not have developed the best coding practices; something I aim to change as I contribute to this project.

Properly documenting scripts

While I believe my ultimate approach for this task was effective, I did make a few mistakes along the way. I began coding before completely thinking out my design. This caused me to lose a lot of time when I made the transition to using states rather than inheritance. I also did not understand my task as well as I should have going into it. My pod specifically had a meeting to address questions about our individual requirements, and I did not put enough thought into my task prior to this meeting. Due to this, I used the enemy’s Rigidbody for movement rather than the desired NavMesh, and questions arose as I worked late into the final night of my task, with no one available to answer them. I aim to improve communication and begin earlier to combat this going forward.

Time breakdown:

Weekly studio meetings – 2 hours
Additional enemy pod meetings – 1 hour
PatrolBehavior.cs – 4 hours
GroundDirectionChooser.cs – 1 hour
Total time spent: 8 hours