Games
Exodus
Exodus
About
Exodus is an upcoming epic new sci-fi action-adventure RPG game by the team at Archetype Entertainment that is currently in development.
My Work
I am working on Exodus as a Technical Combat Designer, primarily responsible for all things AI, including enemies, bosses, and (to a lesser extent) companions. During my time here, I have gotten to design entirely new enemy factions and bosses from scratch, and see their design through all the way to getting a fully-playable experience in-game. In my work, I am able to exercise both parts of the game development skillset I have built up over my career - coming up with designs and implementing them. No other job has allowed me to express myself quite like my role working on Exodus, and I am extremely grateful to be a part of our very talented team.
Crowfall
Crowfall
About
Crowfall is a player-versus-player sandbox MMORPG with a focus on territory acquisition and control. I always explain it to people who are unfamiliar with it as "it's like the board game Risk, but as an MMO". The game originally started as a Kickstarter back in 2015 and has operated as a live-service game since the beginning of development.
My Work
I worked on Crowfall for about a year before it went live, so my work primarily consisted of bug fixing and polishing in preparation for our launch date. However, I was given ownership of the audio system, the in-game map system, and varoius UI elements, so the majority of my work was involved in those systems.
My absolute favorite part of the job was collaborating with designers, artists, and other engineers to implement new game features from game design documents and technical design documents. I was heavily involved in the implementation of a few key game systems, as well as a major contributor to a new game mode that was implemented pre-launch.
HungerDome
My efforts for HungerDome primarily were directed towards creating a matchmaking screen where players could select their character for the match and team up with their friends or find random teams online. I was responsible for all of the client-side programming involved in getting the team roster screen to function, and I also worked very closely with our Platform team to architect a client-server messaging contract system so that the client could send up relevant information to the server, and the server could propagate information to all clients involved in the team.
HungerDome was implemented in order to host a pre-launch tournament that aimed to attract player attention for the game close to our launch date. Unfortunately, the player numbers we experienced pre and post-launch did not merit extending HungerDome to become a persistant stand-alone game mode, and was phased out until more development time could be put into it. All of the HungerDome tournament rounds can be found on Crowfall's Twitch channel.
For more information, a link to the game's website can be found below.
Frog and Croc
Frog and Croc
About
Frog and Croc is a 2000's-era-inspired third-person platformer that I made with a team for my Game Development class. The team consisted of three programmers, including myself, and one artist. I was in charge of gameplay programming, level design, UI design, audio programming, and voice acting.
This game was inspired by 3D platformers and collectathons from the late 1990's and the early 2000's, such as Super Mario 64 and Spongebob Squarepants: Battle for Bikini Bottom, while also taking on the design philosophies from newer entries in the genre. Since I grew up with these kinds of games, I knew what made them special. With this game, I wanted to replicate the feel of being a kid playing a game on your GameCube on a lazy Saturday morning.
You can watch a full playthrough of the finished game below.
Design Philosophies
-
At the beginning of development, I established a few core design philosophies that I wanted to
adhere to for the duration of the project:
- A "show, don't tell" approach to introducing new game mechanics. I knew that every introduction of a new gameplay mechanic needed a tutorial to properly teach the player, but I didn't want the player to feel like they were going through a tutorial. I'm a firm believer in never insulting the player's intelligence with a hand-holding approach for explaining exactly how to play the game.
- Every platform and prop should be realistic for our setting. In essence, that means no artificially floating platforms, or placing platforms simply for the sake of providing a platforming challenge - every object should be a believable piece of the environment. This philosophy takes a page directly from Donkey Kong Country: Tropical Freeze's level design approach.
- Movement shouldn't have to rely on the environment in order to be fun. We wanted our character movement to be fun even if the player was stuck in an empty room. I believed that if we could make the very act of moving enjoyable, then we would have a promising 3D platformer on our hands. To accomplish this, I took inspiration from Mario Odyssey's movement system - Mario has such a diverse set of movement options with controls that naturally form logical combinations of moves when combined together.
Level Design
This game has the player swap between two characters, creatively named Frog and Croc.
Both Frog and Croc each have unique and complex movesets that can be used to navigate the island's various areas. The island contains various doors that only open when the player has found a specified number of clams. There are a total of 20 clams in the game.
The first area of the game is Frog and Croc's home, which is right next to an obstacle course and playground that the player can use to learn the mechanics in a safe environment. All mechanics are available to the player at the start of the game, so I had to design the levels so that the player wouldn't feel overwhelmed with the number of options they had at their disposal. This meant that I had to use a limited number of mechanics in the beginning levels and build up the player's knowledge over the course of the game until I can design a more complex challenge for the player, and be confident that they can overcome it.
The second area of the game is the Tiki Forest. This area introduces the player to enemies as well as combat. This area has a large tree in the middle of a forest clearing that the player must swing around as Frog in order to collect a golden clam that is up too high to jump to.
The third area of the game is the Shoreline. This area is much larger and more spread out than the forest. Here, 2 new enemy types are introduced and the player must utilize their learned abilities to gather all of the clams in this area. For instance, an exploding enemy must be picked up and thrown and some oddly-colored rocks with a yellow glow. These rocks will crumble when the exploding enemy blows up near them, which reveals a golden clam.
The fourth area of the game is the most complex - the Volcano. The player must ascend a large volcano using every mechanic they have learned up to this point. I wanted to have multiple paths up the mountain for observant players. In fact, there are a total of three paths that the player can traverse! Once the player has gathered all of the golden clams in this area, they can destroy the cork that is plugging up the entrance to the volcano, which allows them to go inside.
The final area of the game is a boss battle against a giant version of a previously seen enemy. In classic 3D platformer fashion, the enemy can be destroyed in 3 hits. Destroying the boss Tiki grants the player a Giant Golden Clam, which is worth four golden clams. This brings the player's total clam count to 20, and they can now traverse the entire island however they please!
A link to the Itch.io page can be found below, where the game is available for download.
Dungeon in the Dark
Dungeon in the Dark
About
Dungeon in the Dark is a first-person horror game that I developed for my Intro to Video Game Level Design class. I was the only developer on this project. Other than a few code snippets from the Unity Asset Store, I was responsible for all of the programming as well as the level design, set dressing, and lighting. Sound effects and art assets all came from the Unity Asset Store and the YouTube audio library.
I wanted to make a first-person horror game where the primary source of horror comes from the environment, rather than from some kind of monster. By having the environment as a looming threat to the player, the majority of the scares happen in the player's mind rather than in the game. This is the design philosophy present in several popular horror games like P.T. and Amnesia, which were big influences on this game.
You can watch a full playthrough of the finished game below.
Playing with Emotions
-
I did a lot of research on modern horror games in order figure out how developers are able to make
players feel a sense of dread. Going into this project, I wanted to accomplish the following design goals:
-
Use the feeling of suspense, rather than going for constant scares. Fear of the unknown is often so much scarier than fearing something
that you can visualize. Imagination is a powerful tool that can be exploited to make a situation seem far scarier than it actually is.
As soon as the player has something concrete to place their fear in, they will develop ways to
cope with the horror and lessen its impact. It's kind of like giving a birthday present - when it's inside the box, the gift recipient is filled with excitement
as they speculate what could be inside. When they open the present, all of those possibilities vanish, and the reality of the present is revealed. And while it
might still be a good present, the gift recipient's mind doesn't dwell on it like it would if it were unopened. In this sense, a wrapped gift is better than an opened gift.
A few ways this was used in practice was through the use of scripted sound-cues at various points in the level, the use of amorphous shadows moving across walls, making the level dimly lit, adding a dark fog to prevent the player from being able to see too far in front of them, and ensuring that all hallways have sharp turns so as to force the player to make blind turns at every corner. -
Use jumpscares sparingly. The way I think about it is that every player has a "Tension Meter". While playing a scary game, the Tension Meter continues to go up
while no scares are happening. This is because the player has the expectation that something scary will happen at some point during the game, and the longer they go without
getting scared, the more tense the player experience becomes. They adopt the mindset of "surely, a scare must be right around the corner".
The aim is to let this Tension Meter fill up to max capacity before actually scaring the player, as that will have the greatest effect.
When a scare finally does occur, the Tension Meter becomes nearly depleted, and must be built back up again. For this reason, games with constant
jumpscares are not as effective - they do not give the player time to fill up their Tension Meter for maximum impact.
There are a few jumpscares that I use in the level to capitalize on the Tension Meter - the first is an eerie sound cue that plays as a shadow darts across a wall, the second is a monster screech as the player crosses the bridge, and the third is a loud sound accompanied with VFX when part of the hallway collapses in front of the player. -
Player death, especially at the hands of something you want the player to fear, should be kept to an absolute minimum. When your character dies in a video game, it
breaks immersion and affords the player an opportunity to step back and ground themselves in reality again. This completely resets the Tension Meter, which is likely
at maximum capacity if the player is directly interacting with a fear inducing object, so the potential scare gets entirely thrown away.
Additionally, if the player repeatedly dies to the same fear-inducing object, all the fear that was once there may be directed to frustration. In this sense,
the most impactful horror game would be one where you can never die.
I attempted to manipulate the monster AI such that it would be hard, but not impossible, to be killed by it. Additionally, during the chase sequence, if the player manages to get very far away from the pursuing monster, I have the AI speed up so that they catch up to the player, but will not reach them unless they stand still.
Level Design
When the game starts, the player spawns facing a door with sunlight visible from the gaps between the door and the wall. Most players attempt to open the door only to find that it is locked. The goal of the game is to unlock this door and escape.
The first part of the game introduces the player to levers, which are used throughout the game to open the doors needed to progress. Later the player must explore the environment for bridge pieces that are needed to cross a gap. I added props to this area that contain some unnerving imagery, such as weapons and bones scattered about.
Later, the player will find a torture room with skeletons impaled by metal spikes and splayed across a table, as if in preparation for evisceration.
The final part of the game involves the player retrieving a key from a dark chamber inhabited by a monster. After the player secures the key, all torches in the level are extinguished, and a chase sequence is started. The player must quickly make their way back to the door at the beginning of the level in order to escape. I was so happy with how tense this section of the game was! The entire atmosphere of the game was building up to this moment, and I'm very pleased with how it turned out.
This game received an unexpected amount of online attention from content creators! I had a good number of people who downloaded and played my game upload YouTube videos of their reactions. Most of them provided links to their videos in the comments of my Itch.io page. Seeing people I've never met enjoy my game made me so happy! It was a really inspiring moment for me as a developer.
This level design document outlines the thought process behind how I developed this level. Additionally, a link to the Itch.io page can be found below, where the game is available for download.
Summon the Spellbook
Summon the Spellbook
About
I had been working on a game design document for a Zelda-inspired top-down dungeon-crawling adventure game on my own time, but this particular level of the game was made for my Level Design class. All of the programming, game design, and level design was done by me.
I have a vision for a much larger adventure for which this level is a small part of. However, in this version, you play as a knight that hails from the fire village and begins the adventure only knowing a single fire spell that they keep in their spellbook. The idea is that, throughout the game, the knight will travel to various locations and conquer dungeons and temples spread all over the region. In each dungeon, the knight will add a spell to their spell book. In addition to the fire spell, there are three missing spells - the wind spell, the ice spell, and the thunder spell. The goal of the game is to complete the spell book by conquering all of the dungeons.
You can watch a full playthrough of the finished game below.
Game Mechanics
The core mechanic in the game is combining different elemental spells in order to unleash new attacks. Up to this point, I have currently implemented the wind spell (which stuns enemies and knocks back both enemies and other objects), and the fire spell (which summons a sword made of fire which can be used to light torches and deal damage to enemies). If the player uses both spells at the same time, they throw a fire boomerang which will return after a short amount of time. The idea for the game is that every spell can be combined to unleash a new combination spell!
Level Design
In this dungeon, you begin with only the fire spell. The first few rooms teach the player how to use the fire spell and what kind of environmental effects it can have, such as lighting torches on fire and reflecting projectiles. At the midpoint of the dungeon, the player will find the wind spell and will be introduced to a type of enemy that is on fire and is invulnerable to the player's fire spell. Since the wind spell can put out fire, the player must put out the enemy's fire before being able to damage them with the fire spell.
The dungeon ends with a showdown against a large fire enemy with three phases.
This level design document outlines the thought process behind how I developed this level. Additionally, a link to the Itch.io page can be found below, where the game is available for download.
Honey Up!
Honey Up!
About
Honey Up! is a a real-time-strategy game that was developed in 48 hours as part of the Chillennium 2019 game jam. I worked on a four person team consisting of two artists and two programmers, including myself. I worked on gameplay programming, AI programming, and level design. The theme for this game jam was "all for one, and one for all".
This game is like a weird mashup of Plants Versus Zombies and Cookie Clicker. The player assumes charge of a colony of bees, and they must create enough honey to fill the honey bar. The hive starts off with only a single bee, but through hard work, you can increase your bee count all the way up to a maximum of 100 bees!
You can watch a full playthrough of the finished game below.
Game Mechanics
To make honey, the player needs to collect nectar, which is the main resource in this game. To get nectar, the player must dispatch bees from the hive to the surrounding flowers. Bees can only carry one nectar at a time, which they must then deposit in the hive in order for the player's total nectar count to increase. However, these bees are smart, and they will continue traveling from the hive to the selected flower until all of the nectar has been collected. The flowers will replenish their nectar over time.
The collected nectar can be used to create one of three different types of bees, each with different attributes. There are Normal Bees, which have average speed and average health. There are Beefy Bees, which have a lot of health, but travel slower. And lastly, there are Fast Bees, which travel at higher speeds and have less health. Each bee type is valuable for certain activities and each bee costs a different amount of nectar to produce.
Nectar can also be used to buy honey, or "Honey Up!", which is the main goal of the game. The total amount of honey that you can store in your hive depends on your hive size. Which brings us to the last item that you can buy with nectar.
Nectar can be used to upgrade the beehive, or "Hive Up!", which increases the range of flowers that the bees can fly to, increases the amount of honey that can be made and stored, and increases the total number of bees that the player can have. Upgrading the hive early is important because it allows you to make more bees! This creates an interesting gameplay loop of balancing short term versus long term goals.
I've participated in Chillennium every year for 4 years, and I'd always hoped that my team's game would win an award. I am incredibly happy to announce that this game won First Place Overall. There were more than 400 participants that came from other universities, states, and even other countries, and there were approximately 90 games that were submitted and judged. I feel incredibly honored to receive this award, and I am very thankful for my teammates participating in this game jam with me.
A link to the Itch.io page can be found below, where the game is available for download.
Block Builder: City Escape
Block Builder: City Escape
About
Block Builder: City Escape is a 2D puzzle-platformer that was developed in 48 hours as part of the Chillennium 2018 game jam. I worked in a group of three programmers, including myself. I worked on gameplay programming, level design, and animation programming. The theme for this game jam was "transformation".
I have always loved playing around with level editors in video games, and one of my favorite games at the time of creating Block Builder was Super Mario Maker. As such, I was inspired to adhere to the game jam's theme of "transformation" by having the player transform the level as they're playing through it - it's sort of like using a real-time level editor.
You can watch a full playthrough of the finished game below.
Level Design
There are a total of 5 levels in the game where the player must fill in enough platforms in order to reach the flagpole at the end of the stage. Each stage poses a limit on the number and types of blocks that a player can place to get to the end. Additionally, each different placeable block has its own properties, which are gradually introduced to the player as they progress.
You play as a construction worker who is trying to build up a skyscraper. Each level's background gets higher and higher off the ground as the levels progress.
The first level introduces the player to non-moving blocks and falling blocks. The player has a set number of falling blocks that they can place in order to reach the platform. As a failsafe, the game also has the option to delete the block that you just placed down as well as reset the current level back to its default state. We found that, during playtesting, some players got into a situation where they placed their blocks in such a way that it was impossible to reach the goal, so we implemented this feature to solve that issue.
The second level shows the player that falling blocks will stop when they come into contact with the cloud block, which is immoveable. The player now has access to both falling blocks and cloud blocks that they must use to reach the flag pole.
The third level teaches the plyer how to use the green bouncy platforms. The player has to control their momentum so that they do not fall to their doom. This level also gives the player a few safety cloud blocks (for those that like to take the easy way out).
The fourth level contains the last kind of block - the speedy block. This block increases the player's speed as they move across it. I set up a situation in this level where a speedy block is placed right next to a bouncy block. When the player goes across these two blocks in sequence, their momentum is conserved through the jump, and they are able to travel much further in order to cross the gap to the other side.
The last level provides the player with a playground to use every kind of block that they have been introduced to. This level is the most vertically oriented, so the player must come up with a way to rapidly gain height. There is no single correct way to complete this stage, which makes it really fun and unique!
During the judging process, this game made it to the final rounds! While this game did not ultimately win any awards, it did become a Chillennium Award Finalist.
A link to the Itch.io page can be found below, where the game is available for download.
Reflector VR
Reflector VR
About
Reflector VR is a first-person VR game that was made as a final project for my Interactive Virtual Environments class. I worked on a team consisting of four artists and two programmers, including myself. I worked on gameplay programming, level design, and AI programming.
There are a total of three levels in which the goal is to destroy all the turrets and escape from the testing facility!
You can watch a full playthrough of the finished game below.
Game Mechanics
At the start of the game, the player receives both a laser pistol and a transparent shield. The player can use the laser pistol to shoot enemy turrets to destroy them. Additionally, the player can also use their shield to reflect lasers back towards the turret that fired it. All of the UI is displayed on the player's shield, which is easy to see in the middle of combat!
Since this game was made using SteamVR's Unity API and an HTC Vive, the player has the option to physically dodge incoming lasers matrix-style, which feels really awesome while you're playing the game, but looks really silly to anyone who sees you in the real world.
One challenge we ran into while developing this game was that players would frequently drop their pistol and shield out of bounds, which made the rest of the game impossible to play. To fix this, I created a capsule hitbox around the player's platform that forced the pistol and shield to bounce back into bounds if they ever went outside of the reachable zone.
Level Design
The first level is located on the bottom floor of the testing facility. Stationary turrets will rise from the ground around the player in a circle. They will only begin firing once the player has turned towards them, which prevents the player from being shot by a turret that they didn't even know existed. When all turrets have been defeated, the platform that the player is standing on rises upwards like an elevator. We tested the rising speed for motion sickness, and the speed we used was found to be the least nauseating.
The second level puts the player in the center of 4 walkways. Crawling turrets spawn at the ends of the walkways and will slowly make their way towards the player's position. Unlike the turrets on the first floor, these turrets shoot streams of fire that can be blocked by the shield, or dissipated with a few laser shots. Since these turrets are so slow, their fire does a lot of damage over time, so don't let them get too close!
The third and final level pits the player against hordes of flying turrets that fire two lasers at a time. This is the the most hectic and intense level! Each flying turret takes only 1 shot to destroy, so these turrets drop like flies, which is incredibly satisfying. Once the player clears this stage, they ride the elevator up to the top floor where a surprise is waiting...
The whole testing facility is actually in space! I wanted to let the player have some fun once they got here, so I wrote a script that disabled the gravity on the barrels when the player shot them.
A link to the Itch.io page can be found below, where the game is available for download.