Gameplay / Postmortem commentary: https://youtu.be/1Gyva5ywGWY

Intro: This project had the aim of adapting F.E.A.R. mechanics into UE5 architecture in a prototype of SlowMo and the start to the Goal Oriented Action Planning of the enemy artificial intelligence. F.E.A.R., First Encounter Assault Recon, was a highly acclaimed first person shooter that focused on cinematic shooting experience in a game that built up suspense and horror as the player progressed through the game. The player had an arsenal of weaponry and abilities to choose from, but a unique and marketed feature was the ability for the player to slow down time on command. This allowed the player some breathing room from the frantic pacing of the enemy AI’s tactical abilities. The enemy AI was able to convincingly appear as if it were a highly tactical assault squad that could flush out the player from behind cover, flank the player, create their own cover, and hide when reinforcements dwindled and the player appeared to have the upper hand. Today, designers and developers look to the examples shown by the developers at Monolith Productions, and this project was my own attempt to recreate their incredible framework.

What went right:

SlowMo visual and audio feedback - I believe that the SlowMo visual and audio feedback were the best part of this project for me. There were multiple parts that went into getting the bullet trails just right, from ribbons to spheres being made. Tweaking the exact numbers to dial in a convincing trail behind the projectiles was satisfying and showed to me how easy it was to get the Niagara system in UE5 working.

Player Leaning mechanic - At first, the leaning mechanic was only rotating the camera, but that was not the intended motion. After carefully seeing which component of the character mesh needed to be rotated, I was able to get the camera and gun to translate to one side or the other. This gave the player the ability to stand behind cover to shoot at enemies.

Enemy AI

• Player Detection - The enemies successfully detect the player, visually, audibly, and when damaged. I didn’t have the chance to do this much in AI detection and behavior trees before this project, so this was a nice result given the timeframe. It was tedious to find all the ways the detection systems interacted with the blueprints and behavior tree, but worth the effort.

• Behavior Tree - The behavior tree itself was giving me a lot of issues at first. If I wasn’t able to get the majority of it working as intended, I probably would have written it off as a total loss for this project. Thankfully, my plan for how the enemies should interact with the player worked out better than I expected.

• Strafing - This was something that came as a stroke of luck for me. I was having issues making the EQS work for me with making the enemy feel more “alive” when they saw the player. My solution was to make the enemy simply strafe around the player instead of trying to find a new spot through the EQS.

What went wrong:

Enemy AI

• EQS frustrations - Probably the most frustrating part of my project was running into problems understanding EQS, or rather what I was doing wrong with it. I tried to find a way to keep the enemy within a goldilocks zone around the player, but it was making the enemy AI bug out and made it jittery. It looked totally unnatural and it was more frustrating to see the more I tried to find solutions to a specific problem that I thought I needed to solve.

• Didn’t account for player leaning - I didn’t factor in the scenario where the enemies were engaging the player, and the player was leaning to fire. I had assumed that the behavior tree was working fine, but found out in playtesting that they simply stop when they’re being fired at from behind cover and can’t “see” the player. This will be something I’ll have to figure out on the next iteration. I assume it has something to do with the behavior tree logic and I’ll probably have to make a new sequence that accounts for the enemy having “seen” the player, they’re being fired at, and then it must flank the player to get its line of sight back.

• Level lighting - Every one of the playtesters commented on how dark the level was. This was a total failing on my part in not making the play area bright enough to see what’s going on. The project was a practice in prototyping mechanics, but having a basic level is fundamental, no matter how complex the prototyping is that you’re doing.

Slow character speed - I was trying to capture the pacing of F.E.A.R. when I implemented the movement speeds for the characters. This was probably the second most talked about complaint of the playtests. Thankfully, seeing that feedback has given me inspiration for future iterations and where I can take the game next.

UI needed indicators for controls - One thing that I saw while watching the playtests was that people did read the controls before starting the session, but they quickly forgot about the controls once in a firefight. Cyberpunk 2077 and many other modern games have the controls for abilities and commands dynamically shown on the HUD so that the player doesn’t have to pause and look at the controls again. This is quickly becoming a standard that must be adhered to as more and more games come into the market. Players are looking to jump in and out of a few games, and we as designers cannot expect players to remember all the controls for our game once they’re through the tutorials or beginner levels.

Conclusion:

The playtesting showed me a lot about what people liked and didn’t like about my prototype project. The modern gaming market has affected our own playstyles so much that we can hardly go backwards to older games now, even for inspiration. There are features to all games now that are quality of life improvements that are just missing from past titles, or were very rare and probably helped set the tone for how we play today. Reflecting on this, whatever I may look to for inspiration from the last few decades of gaming, it has to be seen and filtered through the perspective of the modern gamer. The HUD control elements and movement speed for pacing being two prime examples of how I need to adapt old mechanics to today’s audience.