Mighty Mouth Quest

MMQ is a game designed to help psychologists build confidence in kids diagnosed with selective mutism. Accompanied by a real world mentor to proctor the experience, players can earn QuestCash by verbally responding to NPCs in the game. By providing a safe space with low stakes and lots of small incremental rewards, children can learn to find their voices through play!

Overview

I worked as a systems developer on the MMQ project towards the end of its second year. At that point it had been handled by five other teams, and the overall structure was a mess, dozens of unused scripts and scenes sat unused, and there was little reusability across each level of gameplay.

Personal Work

I started with organizing and taking stock of the state of the project for our team so that we could plan how to move forward. Once we had a better understanding of where the project was at, I worked on the following systems;

Problems and Solutions

It was part way through the first sprint that we had fully assessed the level of disorganization that the project was currently in. As a team, our mission became getting the project into a development ready state for the next team, so from the beginning they would be able to produce content at scale without constantly needing to fix core systems like we were now doing.

Standard Gameplay

• Dr Kurtz and Selective Mutism

Interaction System

I originally built this system during the first semester of my Master's degree program. I needed a unified system to identify objects in the scene that the player can interact with, but still keep each object's behavior to be undefined. It has proven a handy tool, so I have been continuing to improve it and use it again in my Unity projects!

Overview

A significant percentage of games allow players to interact with objects in a world; doors, buttons, items you pick up off the ground, NPCs - the list goes on! With my system in the Unity engine, you only need two scripts to add this to your game.

IInteractable.cs

Every interactable object must inherit from the IInteractable interface. This identifies the object as something we can interact with to the UserInteraction script, and allows us to customize that behavior to each unique object.

UserInteraction.cs

This script is usually attached directly to the player character or camera object, which has a large boundary collider. Objects that enter within this boundary are considered within range to be interacted with, and are highlighted. Each frame, we send out a raycast into the scene in the direction the player is looking, and if it finds an interactable object that is also within range, that object becomes our primary target.

We also handle the option to press-and-hold an interactable object to enable its behavior. If players hold down the button to interact, it will start a countdown for that behavior. If the player ever looks away or lets go, the behavior is dismissed.

Now, if the player presses a button to interact with an object in the scene, there is only ever one valid target. This unified process removes the possibility of multiple unintentional interactions, and the need for excessive distance checks.

Implmented in Games

Museum Demonstration

Interacting with Objects in the scene

Precision! Easy to select which object to interact with

Buttons can be pressed and held to interact!

The Eternal Crown

A top-down dungeon crawler pitting the player against randomly encountered monsters within a labyrinthine dark forest. Encountering one of these ghouls thrusts you into turn-based combat! The Eternal Crown lies at the center of the maze where it waits for its next champion to claim it!

Overview

The Eternal Crown was created during my first year at college, and was my first time working alongside a dedicated team on a video game. Much of our focus was spent on learning to work together over the course of a semester, and keeping our plans well documented for each other's use. For this reason development was made through a barebones easy to pick up game engine called Monogame.I designed the turn based combat encounters — a system that allows the player to choose between fleeing, fighting, or healing using potions. While part of this process was reigning back some of our over-scoped mechanics, it meant that I had designed the game to account for additional enemy types to be added at a future date. Consequently, it has become a good habit of mine to design new mechanics with the expectation that they will expanded upon for any of my projects, a trait that has avoided more than a few headaches on my part!

Standard Gameplay

PCG Forest

It will be easy, they said. We should add procedural generation to our game they said.

Overview

I had been hearing the siren song of procedural generation for a while when I decided to work on this project. It is a massive commitment to add to any game that balloons out the scope of every system it comes into contact with, but I still wanted the technical experience to be able to work on this type of system in the future. This tech demo explores the use of PCG graphs from Unreal Engine to make a custom forest environment.

The Work

A pattern to working with PCG graphs appeared almost immediately - after reading in the landscape data from a part of the world, you would place the scenery and then feed that position data into the next 'layer' of scenery.

Challenges

With so many meshes being spawned, my framerate began to drop quickly as I scaled up the usable area that could be randomly generated. The main cause seemed to be the level of detail not scaling well enough for the amount of objects in the scene. In order to continue testing larger environments going forward, I will need to optimize the scene to work with such high model counts.

Future Work

Taking these rules to the next level, the design of an open world game could have a different PCG graph for each biome or region of the world with its own set of rules. I would like to experiment with using ground textures to define these different regions, as well as taking into account local height values for differentiating valleys and mountains.

Generating around World Objects

• Stylized Nature Pack by Tiny Talisman Games
• Simple Farm House by RedHyacinth

SHMUP

Survive as many waves as possible against a variety of enemies, each with unique strategies in this Asteroids inspired SHMUP (Shoot-Em-Up)! From the far ranged artillery to swarms of flotilla ships, these BOIDS (bird-oid objects) utilize deterministic action based on the position of the player and other enemies in the scene.

Overview

My goal for this game was to create enemies that had notably distinct behaviors, so that the player could learn to react instantly based on visual response alone. This effect was achieved by providing building flaws in each of their strategies that the player could learn to manipulate.

Over the course of the semester, I created a spawning system to introduce progressively more and more enemies to be encountered in waves. With so many projectiles and enemies flying around on the screen, the collision manager takes advantage of the singleton pattern to significantly reduce the number of scattered references passed throughout the project.

Standard Gameplay

Some early errors with spawning enemies in waves...

• Foozle's Asteroid Assets
• Health Bars by adwitr
• Space Background by Pixel Carvel
• Ship Assets by Krasi Wasilev

Unititled Scout Game

In this stealth shooter set during the World War II era you must dodge and weave between guards patrolling the environment. You are an expendable scout during the war effort, and must hope that your skills are enough to go undetected.

Overview

My second year at college I joined the Hack-a-Jam club, where we spent an entire semester working on a game. With our focus on stealth, I was tasked with simulating passive patrols that could become active and chase the player. I implemented a state-machine that alternates between two different pathing systems:Passive State: An enemy will follow a string of waypoints, simulating a routine patrol.Active State: An enemy will seek out player using the A* (A-star) pathing system. They are able to navigate a world with unforeseen obstacles and attack, but after some time they will lose sight of the player and return to their origin.

Challenges

Implementing the A* library was a completely new experience for me, adding a wealth of systems of which I barely scratched the surface. I found myself facing logic problems where the enemy would rather go around a river they could shoot over, but not walk over. From this experience I'll be much better prepared to design enemies with the A* system in mind.

BOWNUS

You are a shooting comet fighting off a horde of eldritch creatures from beyond the veil of space! As your combo meter increases, it exponentially affects your movement speed and firing speed to nigh uncontrollable levels. Getting hit decreases your combo, so you'll need to practice controlling your ever increasing velocity!

Overview

Our inspiration came from games that have been unintentionally broken by players maximizing the benefits from perks and abilities, these effects make them uncontrollably fast to the point of being more difficult than they are worth. We leaned into this idea and twisted the game jam's theme of bonus to be a detriment to the player rather than... well a bonus. This made for a short but intensive chaotic game loop for our weekend game jam submission!

Personal Work

Challenges

Facing the limited amount of time we had to develop our game, our team took on the additional challenge of working with the mostly unfamiliar engine Godot. Our team lead was well experienced with the its tools that had a positive reputation for developing 2D games, so we all agreed that the added difficulty would be well-worth the experience. Despite facing a time crunch, we engaged with new systems and tools that I feel much more confident to use in the future.

• Play Here!

Standard Gameplay

Wizard Cube

This is the Wizard Cube Tech Demo! As the cube, you are able to summon balls of fire that blast any nearby objects away from the explosion, including you!

Overview

This project started out after I designed some basic animations for a 2D art course in college. While the idea of using your attack as a form of movement - your only form of movement - is not a new one, it stuck with me as a fun mechanical exercise that I wanted to implement! So, I decided to make a quick tech demo for what a full game with this ability might feel like.

The Work

Challenges

I wanted to test out a different engine instead of my usual set of tools, and at the time Godot was becoming very popular in the 2D space. Godot has a comparatively small amount of learning material online compared to other engines like Unreal and Unity, which made the experience a trial by fire — especially since the engine had just updated to 4.0, making many of the few tutorials online obsolete.

• Play Here!

Movement Demo

Connect'In

Connect'In is a satirical mad-libs text game about creating as many topical and popular posts as possible to gain connections on this career building website. The algorithm favors quantity over quality when awarding you with connections, as well as including certain buzzwords. If you fail to meet the connections quota three times — you lose!

Overview

I created the user interface for the project entirely within one scene. Once we realized that the tutorial and menu screen could be presented by the game's notepad and the post-generator, our single page was able to be reused throughout the entire game. I also added several accessories such as the like and comment values to give the app some more random behavior.

Most of our planning was made within an hour of the theme's release, and given the 26 hr scope we were able to put quite a lot into our game as a three person team. For such a short game, by dedicating a decent amount of our time to preplanning, we did not have to deal with bigger changes to the game eating up our time later in development. Every member had a clear set of tasks to complete from start to finish.

• Play Here!

Gameplay

Mech Attack

Lorem Ipsum

Overview

Lorem Ipsum

Lorem Ipsum

3D Modeling Work

Modeled and animated in the program Maya are two mining robots, APD-B317 and a M.U.L.E. unit, both from the hit co-op video game Deep Rock Galactic. However, I have chosen to refer to them here by some of their respective nicknames in-game — Bosco and MollyCreated for IGME 216.06 - Experience Design for Games & Media

Overview

As a game developer my work is multidisciplinary by nature — including production, design, development, narrative, and in this case sculpting and animating 3D models. Having an understanding of as many of these processes as possible gives me the perspective necessary to work and communicate across many different teams of expertise.These particular models are the end product of my fourth semester at RIT; modeled, UV unwrapped, and textured! For Molly's model, I created an additional walking animation to test the quality of my rigging.

What I Learned

This project gave me a better appreciation for time-prioritization and efficiency; creating a model with as few triangles as possible could still render a more complex texture on top of, as well as giving joints extra details that would deform properly during animation. On the other hand, I ended up spending far more time on UV unwrapping than was necessary because I wanted to make it just perfect - at the cost of my time being better spent on other work. In this case, the best unwrapping would have been 'good-enough' to start texturing rather than the 'perfect' touch ups that did not significantly affect the model's quality.

Molly's Walk Animation

Basement One

Question your obedience to an ever-changing set of rules, enduring fear, and uncertainty in each eerie, unsettling basement level as it twists your understanding of the truth!

Overview

Trapped underground in a series of seemingly identical levels, the player must work methodically up each floor to reach the ground level and escape this place. At each level the player will be introduced to new rules they must follow to progress – some of which are true, others are false. In order to test these boundaries, the player must interact with items and props in the environment. An anomalous creature is there to enforce the rules, and occasionally antagonize the player. Should any rules be broken, it will pursue them and send them back to the start of the level. Fail too often, and they will be trapped down there forever!

Work and Contributions

Problems and Solutions

One of the biggest issues I ran into over the course of this project was getting the navigation mesh to generate properly when using outside assets. While I was implementing the generation of the navmesh in my own scene, I had created a test scene using simple spheres and cubes provided by Unity. For whatever reason however, many of the free assets that were used to quickly furnish our levels simply would not allow the navigation mesh to generate at runtime.

This issue was discovered very close to one of our playtests, and I ended up having to create it manually for each level just to make the build stable. A lot of my recent work was being thrown out at the last second which was extremely frustrating, however - I should have been testing with the new assets sooner, and I should have known that my artist was adding a bunch of new assets. It was a clear issue with our process and communication on the team, and going forward our future meetings included time to discuss possible issue that might be caused by merging each sprint's projects.

Standard Gameplay

Dig Too Deep

You need better defenses — Dig new tunnels to supply the resources — Creatures use those tunnels to attack — You need better defenses

Overview

Our prompt was resource management! With four weeks to build a prototype, we decided to take the basic RTS (real-time-strategy) tower defense formula, and add grid-based digging to map exploration! Inspired by the Mines of Moria and the game Dwarf Fortress, players would be forced to expand their territory in order to gain resources from the stone and gold they mined. These new tunnels only let in more monsters, forcing the player to bulk up their defenses which needed more resources, adding more fuel and pressure back into our game loop.

Personal Work

Problems and Solutions

One of the issues we ran into almost immediately was balancing territory expansion with difficulty. We initially had no time-constraint for removing tiles and building towers, which made it too easy to clear out the entire map very quickly, making it difficult to ramp up the difficulty of the game.Miners dig Tunnels, not Caverns: To maintain the aesthetic of branching mineshafts, as well as to balance the pacing of the game, I added individual units that would need to move around the map to fulfill the player's commands. These workers would build and destroy the tiles for the player, but they would need to physically move to the task's destination, waiting a few moments to complete the action. This gave us the ability to slow down player expansion to a reasonable level, and encouraged players to choose which tiles to affect more carefully.

• Play Here!

Standard Gameplay

Golf Grubs

All the holes on the course of Golf Grubs have been picked up by a trio of bugs, and are on the move around the golf course! You need to land in each mobile-hole in as few strokes as possible and while avoiding other pests and dangers of the course. Time might slow down while you aim, but you will still be competing against other players for the best time overall, and keeping your name on the leaderboard!

Overview

In this prototype, we were tasked with creating a unique character for a simple 2D platformer in just three weeks. Since almost every game in the genre included walking, sprinting, and jumping by default —we wanted our player's moveset to be something new. The game of golf came up, and thinking of the player launching themselves as though they had been hit by a club seemed fun, so we decided to run with it!

Personal Work

Problems and Solutions

The biggest design issue we had to keep in mind was that our character would be able to travel a lot farther than other traditional platformers. To maintain the fantasy of a golf ball's freedom of movement with the traditional challenges found in platformers, we made two key decisions;
Everything Modifies Speed: The intelligent actors and environmental effects we proposed all dealt with slowing down or modifying the player's movement. Players instinctively wanted to go faster in playtests, so we built everything around that. If you engage with our mechanics, you can go as fast possible! Mess up, and you get slowed down...
Limits on Launching: The player could launch themselves constantly at first, almost like flying! Taking a note out of our golfing inspirations, we required players to hit solid ground again before launching. This meant players needed to launch at precise times at high speed, requiring skill while maintaining our focus on momentum.

• Play Here!

Gameplay Footage

Introduction

One of my projects in school was to create a raytracer model; building on top of this project, I chose to implement Rayleigh and Mie scattering to create a more realistic skybox, and improve the overall accuracy of the global illumination model. This page documents my journey for this project.

Architecture

My primary reference was Scratchapixel's "Simulating the Colors of the Sky" article. I have included a small slice of the architecture from my raytracer that calculates the color of the atmosphere here.

Systems

I had assumed that modifying my current raytracer to accommodate a realistic atmosphere would take more leg-work, however it really boiled down to replacing the basic background color to instead return the result of the atmospheric calculation. Nevertheless, there were of course several key issues I had to overcome along the way.

Results of the Realistic Atmospheric Simulation

I am really happy with how the final rendering turned out! Since we are trying to mimic reality, I had several physically based variables to tinker with and created a couple of alien skies that could exist with different atmospheres!

Future Work

For now my raytracer model is complete, but there are several other ideas I have for the project that I would like to try out;

Checkpoint 1: Setting the Scene

For the first checkpoint I recreated the locations of the objects in a basic Unity scene to get their relative measurements and positions.

Checkpoint 2: Raytracing Framework

A film plane was implemented from where rays are cast out into a 3D scene, returning the objects that they have hit. I opted to do my pixel calculations in the world coordinate space so that larger models do not have to translate hundreds of thousands of triangles into the camera space. While this made the initial calculation a bit more front heavy, it should save make rendering a the image a bit faster.

Current State

Extra Additions to the Model

Theory and the Real World

What is next?

Current State of the Raytracer

Work Cited

Checkpoint 4: Procedural Textures

Finally replacing our original matte color values with some actual textures, I implemented a material class that can be stored by the object class. Below are some example procedural textures I experimented with, but the next step will be to load in actual texture map files.

Checkpoint 5: Reflection

Nearing the finish line, we add reflections to our simulation. By recursively sending out rays, we can simulate reflective surfaces on one of the spheres. This recreates Whitted's original too perfect reflections. The change in the brightness of the scene in the second image is a tone reproduction issue, and will be fixed later on.

Checkpoint 6: Transmission

We finally have the last material for our recreation of Whitted's original raytraced model! Light rays can move be refracted through transmissive objects, and around the edges total internal reflection occurs.

Checkpoint 7: Tone Reproduction

Tone Reproduction! The finishing touches to our recreation of the Whitted scene scales the color values of the scene to something slightly more realistic.

Ward's TR Operator: This one came out really nice. As the lighting in the scene increases, the background skybox becomes less bright and puts more focus on the scene itself!

Reinhard TR Operator: I had more difficulty with Reinhard's implementation. I've included the same images using the same illuminance values as in the Ward images, however I was unable to get the background to distinguish itself as much from the foreground.

Advanced Tone Mapping

Going somewhat further with the Tone Reproduction from the last checkpoint, I implemented another tone operator called Adaptive Logarithmic Mapping. In these scenes the changes are slight, but it takes into account the luminance at each individual pixel, making for a more balanced scene.

Advanced Procedural Texture

Going a step further from my previous textures, I replicated a section of the tile pattern from my local cafeteria. The tiles themselves link in such a way that prevent a repeating section from forming, so I based the texture on one closed off section marked by the black square-space.

Possible Improvements to the Texture