When we were designing the enemies for Recursion, there were a few key ideas we stood by. We wanted enemies to:

• Have a looping schedule the player could learn over multiple runs that didn't change

• Interact with the world around them (be able to open doors, notice distractions or things wrong around them)

• Be challenging in combat to discourage players from fighting every time it was possible.

With that in mind, I developed two enemy types: The basic Melee enemy and the tougher Ranged enemy. Both enemies use the same base class for player detection, alerting other enemies when the player is spotted, and base variables (like health, movement speed, etc).

Patrolling Behaviors:

• Enemies will follow a set path, repeating until they spot the player.

• Once spotted, a detection meter will increase, influenced by how close the player is (the closer, the faster the detection)

• Once detection meter is filled, enemies will alert other enemies in a short radius and enter combat.

Alert Behaviors:

• If enemies lose sight of the player during combat or after a certain detection, they will become alert

• Alert enemies will move to the player's last known position or a position of interest, then procedurally look around trying to find the player

• If player is not spotted, they will return to patrol behaviors. If spotted, the enemy will enter combat.

Combat Behaviors:

• During combat, melee enemies will try to reach the player and attack if their attack is off cooldown. Otherwise, they will slowly approach the player or circle slowly around them, depending on how fast the player is moving away). Ranged enemies will always attempt to maintain a certain distance from the player, and will similarly kite around the player or slowly approach them depending on distance and speed of the player.

• If the enemy loses sight of the player for enough time, or hasn't done damage for a set amount of time, they will exit combat and enter alert mode.

We wanted our player controller to be slow, grounded, and very realistic feeling with hints of Dishonored in the peeking.

We alternated a few times between a free camera or Rainbow Six Siege-esque, eventually settling on the latter for simplicity sake.

I programmed our original player controller and movement. As the project went on, this work was later passed onto our technical designer, who added more systems and juice.

For this project, our designers wanted one, modifiable gun with stats they could easily adjust. Our gun went through a variety of changes throughout the project (starting off as a heat based weapon, and moving to ammo-based), and having a jumping-off point no matter the change made the gun flexible to new changes.

The images on the left showcase the scrapped heat system (with a system to visually heat up the coils per shot) and the variable spread for the gun, allowing designers to tweak settings to the maximum.

For this project, I served as the manager / producer. One of my responsibilities included designating tasks weekly to all members of the team. I chose to use Jira to easily organize and categorize tasks by discipline and their current state. Each week, I would check in with team members for updates on their tasks and update the Jira board accordingly.

Each week, we met with Bungie mentors to discuss our work from the past week, playtest the game, and field feedback and critiques about the current version. I was in charge of scheduling these meetings (which were a mix of online or in-person), playtesting a version of the build before our meeting, and delivering the build to our mentors.