Details

Overview

Codename: Pariah is an FPS game developed during the final assessment in my final year at AIE; where the core focus was collaborative design / pre-production, development and project iteration.

Contributions

AI

Though I spent a fair chunk of time fixing bugs, helping the other engineers in the team and profiling some performance issues ( spoiler alert, my bad ), most of my time spent on the project developing the ecosystem surrounding the AI; which consisted the following systems:

White Willow

At the core of my work was White Willow: a UI node based tool for authoring Behaviour Trees that I’d created weeks prior in preparation for the project. It featured various nodes for designing different enemy behaviours, blackboards for storing private and shared state and was easily extendable.

EQS ( Environment Query System )

This was system that all AI called upon to locate optimal positions to move to in the environment. This system gave us finer grain control over how close to objects we wanted AI to position themselves when navigating around the world, whether a position gives / breaks line of sight to the player, etc. It was a great idea at its core when we and the designer discussed it but honestly was too performance heavy / unoptimised and kinda sucked to use in the end which I still facepalm over to this day.

Token Combat System

A manager of sorts that provides tokens to AI for engaging the player. Only a certain number of tokens can be distributed and once an engagement ends ( typically firing a few times before repositioning ) the token is returned. A system somewhat obviously inspired by Id Software’s implementation in Doom; a game our designer and I very much love.

Other

Telemetry

During the early phases of development, I was given a request to implement a means of data collection to allow us some insight into what players were instinctively doing during the play-tests. We would then use that data and run it through a parser to overlay a 3D heatmap over the level in-editor, select each node in the inspector and view the data sets cached there.
In the end we didn’t end up using it, play-testers were requested to attach the files with the feedback form but only 1 regularly did which wasn’t enough info. That and I had more urgent things to work on than finishing the polished version if we had no use for it.

Retrospective

Everyone has a plan until they get punched in the mouth

Let me preface this by saying: no game devs were hurt in the making of this game, no hands were thrown, and no blood was spilled as a sacrifice to the Unity gods to not crash and get stuck in a 20 minute load cycle for the 28th time in the same day. But project management is… difficult, and can definitely feel like an unplanned tooth extraction.

A lot changed during the game’s development which was expected, given we had the game play tested quite frequently to maximize feedback. Regardless, the number of times we’d be in the process of adding a new feature, tools or QoLs only for them to be canned or not used for various ( valid ) reasons couldn’t have felt much better than playing rock-paper-face. That said, with a bit more foresight on my part and in-depth discussion with the team it may not have been as brutal.

The bigger the are, the harder they fall

Just like any team project with a collection of bright eyed creatives; we bit off more than we could chew. The initial scope seemed simple but we all know how that ol’ chestnut goes. What was really a kick in the shins is that even though we knew the scope was already at the limit of what was recommended, we didn’t actively address the problem until everyone’s favourite development goblin - Scope Creep - reared its ugly mug.
That little mouth breather costed us some crucial content that never made the final release but that came with a lesson I won’t forget, leading into the final note…

A closed mouth gathers no foot

Ultimately everything said so far has been about scope and this just covers another corner of it. At least once or twice each, we all underestimated how long a task would take to complete; or inversely, over promised what we’d have done within some time frame.
Be it the desire to be helpful to the team or a bout of optimism, it definitely become somewhat of a running joke at one point that we eventually acknowledged which is now branded on my ass:
Don’t underestimate the time something will take to complete, nor overestimate your own abilities. Take the initial estimated time for the task, double it, and double it again. That’s closer to how long it’ll actually take in reality.