You Are The Hunted

You Are The Hunted is the capstone project from my senior year at SUNY Canton (2021-2022). The game is based around the concept of The Seven Deadly Sins. The setting is a hotel and each floor represents a different sin. The footage in this video is from the Envy level, where the boss is a large robot V-Tuber. One of the main concepts of the game is that, unlike most other Rogue-likes, the boss is actively hunting the player. There was a lot of hard work and tough decisions made in the process, but I am happy with what we were able to accomplish. 

My main roles on this project were that of a game designer and scripter. I pitched game systems to the team, then worked on their implementation and owned them until they were polished. I collaborated with artists, programmers, and other designers to clarify concepts and ensure deadlines were met.

I participated in keeping documentation up to date using Microsoft Office Suite, as well as task and bug tracking with Trello boards. Our team also participated in weekly scrums both in person and online to provide progress reports and set deadlines.

Overview

  • The player should be able to encounter the boss at any moment in the level

  • Feature systems + mechanics that encourage fast-paced gameplay

  • A loot system that encourages fun builds and experimentation

Goals

Action Rogue-like

Genre:

Engine:

Godot

Dev Time:

~10 Months

Team Size:

Select an option below to view greater details regarding my process and the work that went into certain aspects of the project.

10

Scripting (Python)

Collaborated with other teammates to create and improve upon:

  • Player movement including a short range dash.

  • Player combat mechanics.

  • Storing and updating info regarding the player’s inventory and stats.

  • Player states and damage.

  • Scripted base system used to create weapons and items.

  • Scripted loot pop-ups that can be used to quickly compare stats between weapons and items.

  • Scripted loot sources and RNG drops.

  • Loot drops that randomly determined stats within a preset range.

  • Tiered loot system that scaled stats based on rarity.

  • Designed systems used in the creation of weapons and items.

  • Designed loot sources and drop RNG.

  • Designed and implemented system for comparing two pieces of gear.

  • Collaborated to design player combat mechanics and inventory system.

  • Participated in brainstorming sessions and discussions regarding overarching game systems.

  • Pitched ideas for boss mechanics to the rest of the team.

Game Design

  • Participated in weekly scrums

  • Helped find issues and evaluate aspects of the game that required attention

Playtesting

Implementation of Art

Implemented the art teams icons and sprites

  • HUD, weapon stats, item stats, and Player Inventory screen

  • Player movement and attacking sprites

Challenges & Solutions

We decided that we wanted the player to be able to attack while moving, however, the way the player was animated they would perform an in place attack animation while moving, causing the player to appear like they are sliding along the floor when attacking.

Challenge 1:

After a conversation with the art team, we determined that we could separate the sprite for the players arms from the rest of their body. This allowed for the player sprite to still play the walking/running animations while the arms simultaneously played the attacking animations.

Solution 1:

Part of our goals for the gameplay was to encourage the player to move fast. That was partially accomplished by having the boss hunt the player throughout the level, but we found that could lead to the player just choosing to run away from the boss for extended periods of time. And while we wanted to encourage fast gameplay and coax the player into fighting the boss, we didn’t want to do anything like locking the player in a room with the boss to force combat.

Challenge 2:

We decided on a simple solution: a timer that would count up the longer the player was in the level. We brainstormed a few ideas for its implementation, but settled on it being a source of positive reinforcement for the player. The quicker the player completed the level, the better rewards they would receive upon completion. Unfortunately, this was never fully implemented into the game as we ran out of time, but I am pretty confident it would have at least aided in solving the challenge we were facing.

Solution 2:

Detailed Info

Weapon & Item System

I was primarily responsible for the weapon and item system that we used in this game. I first discussed with the team how we wanted the weapons and items to function, and upon pitching some ideas we decided on a few things:

  • Weapons and items should have unique effects that change the way the player plays the game.

  • Rarity that boosts weapon/item stats.

  • Semi-random stats for each weapon/item.

  • Player can hold one weapon at a time.

  • The player can hold one item of each class for a total of four items.

When creating the framework for the weapon system I added exposed variables to hold basic weapon information. This includes things such as weapon name, weapon type, and description, among other things.

I chose to do this as I knew other designers would also be using this system. This framework made it easy for the other designers to create unique weapons by simply inputting basic information in the game editor.

This also allowed us to input a minimum and maximum value for certain stats like damage and attack speed. When the weapon was spawned into the game world these stats were taken into account. This helped prevent large disparities in stats for weapons of the same class, while still keeping a bit of an RNG element.

Weapon Framework Variables

Combat Design & Scripting

I collaborated with team members to design, pitch, and script several aspects of how the combat plays out on the player character end.

One of these things was the player attack indicator. This was a curved line that orbited around the player and showed them which direction they would swing there sword when attacking. This was accomplished by using the mouse cursor’s relative location to the player character and rotating the indicator to face that direction.

As this game relied on sprite work we couldn’t really rotate the player in every direction that the indicator could face. We were limited to four basic directions (up, down, left, right), and also didn’t want to also limit the player’s ability to attack in a precise direction. What I did to solve this was when the player pressed the attack button it would get the attack indicator’s location and use that to approximate which directional animation to play. This helped the animations match up better with the direction the attack was facing.

Attack Indicator as seen in game

Attack Indicator in action

RNG & Loot Sources

I designed and scripted how the chests in the game functioned. These could be found throughout the level and were the primary source of loot for the player.

The chest object contained two arrays: one for weapons and one for items. Upon the player opening the chest it would run code to first determine how many drops there would be. Then for each drop it would determine if the drop was going to be a weapon or an item. There were two arrays containing references to every weapon and item that would then be randomly selected and spawned. Upon spawning the weapon/item would generate it’s stats.

The chest object had exposed variables. These were minimum and maximum values that the RNG system would use to determine the number of loot drops to spawn. I added functionality that could be used to toggle on/off the chests ability to give the player weapons or items. This was in case we ever wanted have a chest that could only spawn weapons OR items for the player.

Chest as found in level (Sprite done by art team)

Chest variables

Art Implementation + UI Elements

I implemented various UI elements across the game. Below is some of my work on this project.

I worked to create damage numbers that pop up upon damaging an enemy. Taking into account if the attack was a critical hit and and changing the text color and size.

These were able to be instanced for any entity that could received damage.

Normal Damage Numbers

Critical Damage Numbers

The player’s inventory screen holds all of the important information.

Here the player can check their weapon, items, and current stats such as Attack damage and attack speed. These also have an indicator next to them that shows if the stat has been modified positively or negatively from the default value.

The game does not pause when opening the inventory so the background is mostly transparent with a little bit of shading.

Player Inventory Screen

Negative stat change

In this example, the Attack stat is by default 10. Here it shows the current Attack stat: 7, and the amount it has been modified: -3. The numbers are red to indicate to the player that this is negative change.

Positive stat change

The default crit chance is 10%. As shown here it is now 24% meaning that it is modified by +14%. And green text is used to indicate a positive change.

I coded the health bars for the game and implemented the work the art team created for it. All of the health bars in the game are one Godot scene that gets instanced into every entity that needs it.

Health bars on enemies

Another thing I did was I worked on how the loot appears when on the ground. I used linear interpolation code to make the items bob up and down.

When the player got close enough a pop-up would fade in showing a condensed version of the stats. Pressing TAB would expand this pop-up to show more stats as well as the special effect the piece of loot has.

Loot on the ground + Stats pop-up

As the player could only hold one weapon at a time I wanted the player to be able to easily compare their current weapon with any new ones they find. When close enough to the weapon they can press a button to show the ground weapon’s stats, and next to it shows their current weapon’s stats.

Weapon comparison