My Responsibilities:

For Parasite Zero, I took on two primary responsibilities. I was both the programming lead, and a programmer myself. Though I was wearing two hats, I found it fairly easy to swap between the two roles and do whatever was required of me at the time. I took these roles because I really wanted to hone my software development skills this semester. I consider myself more of a designer, but I never want technical ability to hold me back. So, I decided to focus on my programming skills this semester. This was advice given to me by a Technical Designer at Retro Studios, so I try to live by it every day.

As Programming Lead:

As programming lead I was largely in charge of handing out tasks, cross-communicating with the other teams, giving out technical advice and generally being an available asset to the code team.

I tried my best to hand out the appropriate tasks to the right coders. I’d worked with many of them before, and I felt like I had a good grasp of their strengths. I hope that everyone on the team was given enough to do without being over stressed/burdened with work. I never want to facilitate crunch. I feel like I was able to make a good balance. Sometimes a coder would ask for a task and I wouldn’t have anything to give them. When that happened, they did a great job playing through the game, finding a void, and filling it themselves, so thank you!

As for cross communicating with the other teams, this primarily means that I was speaking with the environment artists, and the design team. When working with design, I'd gather feature requests and bugs reports from their team, turning them into tasks, and assign it to a coder on the code team. As for environment art, it was mostly about checking in and making sure we were on the same page of the project. Especially for more technical aspects like UI and character models.

As for being a team asset, I try to make myself as frequently available to the code team as possible (read: being terminally online). So whenever someone would have a question, whether about how to code something or the project as a whole, I’d try to answer as soon as possible. I wanted to be someone the code team could rely on. I’d worked with a lot of them since Game 2 last semester, so I’ve really been able to see them grow as collaborators and developers. I hope they can say the same about me.

As A Programmer:

I noticed that I had a gap in my skill set when it came to enemy AI, so I decided to make that my personal contribution to the team. I focused on the AI behavior for small enemies, big enemies, and enemy Zubs that appear throughout the game. Speaking of Zub, I also set the initial base for our flying drone character for the player that the other programmers ran with. Overall, I figured it was for the best to take responsibility for one key mechanic and let the other programmers handle other aspects of the game which I’d keep an eye on. I decided to run with enemies as my key feature.

Enemies:

Since I took responsibility for the enemies as a whole, there was a lot of different behavior to cover. My primary responsibilities and technical utilities are laid out below: 

Reporting the player:

Our main goal with the enemies was to have the small ones report the location of the player to a large, intimidating enemy. Since this was one of the first tenants of the design it’s what I decided to approach first. I did it through implementing a “reported location” blackboard key. This value would be set when the small enemy finished a “reporting” animation, and the big enemy would drop everything and head to that spot. I had initially had it happen immediately but after feedback from the designers, who wanted a chance to strike and kill the enemy, we decided to only do it after the small enemy finishes the animation. This gave the player the time to react and either run or attack the enemy. It fed into the risk reward design of the mutation system of the game well, so I’m glad it was brought up by one of the designers.

Exposing variables:

Image of the exposed wait time variable

Other feedback from designers was that they wanted more variables exposed so that they could fine tune the enemy for the finished level. So I went through, explained how the enemies worked and exposed as many variables as I could so that they could be easily changed. This way, the enemies could fit the designer's intentions. This also made me make my code clean and readable. I did this through organization and clear commenting of the enemy states. That way, others could look in, see what the code did, and make the necessary changes to fit the design of the game.

Implementing States:

The enemies needed to have a lot of states for a stealth game. The biggest ones being patrolling, chasing, and attacking. Patrolling had to be consistent and reliable so that enemies could be read and avoided. So, I gave the designers the ability to hand craft their routes using spline points. These are easy to work with and edit inside the world so I ran with them. They could also aimlessly wander and be stationary for variety. If the enemies notice the player (after reporting them if they were a small enemy), they’d chase the player until they were close enough to attack. I tried to make the attacks have lots of cooldown so that the players could have time to run away and recuperate before delving further into the level.

Notice time:

One piece of feedback I’d received was that the enemies were too snappy. They’d immediately notice the player as soon as they were in view and gave the player little leeway. So, I implemented a system I call Notice Time. This system is similar to coyote time (the system where you have an extra fraction of a second to jump after running off a platform in a platformer, like Celeste). I essentially programmed a system where if an enemy sees you, they’d wait half a second, make the check again, and if they could still see the player then they would notice you and start chasing you. This gave the player a bit more flexibility and made the game feel more fair as a whole.

Working with Montages:

I had to work with montages a lot with these enemies. This gave me the chance to work with a couple specific things with montages. Primarily, Motion Warping and Anim Notifies. I used Motion warping to make attacks work. With these, I could give the enemy a target (i.e the player) and move to that target in time with the animation. Since I could dictate exactly when the enemies would move to their target, this gave me a lot of control with how the enemies are timed. I could tweak and balance the enemies to make their attacks threatening but not inescapable. As for Anim Notifies, I used these to trigger events. When to check for the player to do damage and when to report the location to the big enemy were the biggest implementations of Anim Notifies. These gave me lots of control when actions would fire. Allowing me or a designer to tweak events and perfectly time them with an animation. Animation montages (including motion warping and notifies) are one of Unreal’s best tools and I will absolutely keep working with them in the future.

Things I’ve Learned:

As with any process, I’ve learned a lot through making this game with the class. Some things, I was able to apply immediately. Others, I’ll have  with me in the future.

Mistakes I Made And How I Plan to Improve:

Image of the very large and convoluted parent player class

One big mistake I made as programming lead was that I could be too rigid and hold people back. I’d be stubborn on certain aspects of the game. For example, I was really worried about the parenting of the player. I knew that there was a parent player class due to a plug in we used and I really didn’t want people to edit it. This could have an effect on everybody else’s work on the child class of the player after all. However, my stubbornness in not letting people touch this class did more harm than good on multiple occasions. Sometimes, I’d have a programmer who needed to touch it to make their mechanics work, and I wouldn’t let them. I should have trusted my programmers more and let them edit the class when it was necessary. 

In the future, I plan on being more fluid in my approach and allowing more change to occur to parent classes when working with others. It’s a collaborative process and I needed to recognize it.  Especially when parenting is such a large part of software development.

Image of unnecessary enemy type checks I had to do due to parenting 

Speaking of mistakes and parenting (code-style parenting that is, love you mom) was some incorrect use of parenting. Especially with behavior trees. I made all enemies have the same AI Controller and follow the same behavior tree. This added complexity and reduced control the designers had on the individual enemies. While, yes, the big enemy and the small enemy had similar behavior, they were fundamentally different and should have been treated as such. 

In the future, I need to ask if my parent child relationships are really necessary when coding my work. While they could share some behavior, I need to think about what’s best in terms of the game design. I need to ask myself, “What gives us the most control in the future?“

Another mistake I made was not asking for specifications early on from the design team. When I started working on the enemies, I wasn’t given a lot of direction besides the reporting the player location aspect. I went full ego and assumed that I knew what the design team wanted for the enemies. I was wrong in a lot of cases, and a lot of pain could have been avoided if I had just asked for specifications early on.

In the future, I’m asking for specifics. I shouldn’t assume what other people want from a mechanic, and I’ll need to ask them to spell it out specifically. Yes, it’s more upfront work, but honestly, it’s necessary to do this so that we’re all on the same page down the line.

So, all in all, I guess I should watch my hubris?

Final Thoughts:

Lastly, I just want to thank the code team. It’s been an honor to work with you all and I can’t wait to see where you go. I know there were ups and downs in development, but I really respect what we were able to do as individuals.