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

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 make split second decisions based on their color alone. This effect was achieved by each providing unique flaws in each design that the player could learn to manipulate. This much more life-like behavior

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.

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. I designed the player’s combo meter and the effects it had on the player, their speed exponentially increasing with the rise of a combo meter, making for a very quick and chaotic game loop.

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

Using a fireball as to propel yourself forwards — this is the Wizard Cube Tech Demo! It started out with designing some basic art assets and animations for a class in college, but I loved the idea of using an attack for movement, and decided to make a quick tech demo for what a full game might feel like.

Overview

The focus of this project was to create a movement system to moving around the environment using the repelling blast of a fireball the player is able to summon. I implemented an object pool for the many instances of the fireball in the scene to reduce the number of instances being created.

I also 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 frighteningly small amount of tutorials online compared to Unity, which made learning the new engine a trial by fire — especially since they had just updated to 4.0, making most of those tutorials obsolete.

• Play Here!

Demo of Movement

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.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

The Journeyman Engine

Lorem Ipsum

Overview

Lorem Ipsum

Since then, I have upgraded the engine to display....

Basement One

Lorem Ipsum

Overview

Lorem Ipsum

Lorem Ipsum

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 3 weeks. Since almost every game in the genre uses the standard WASD and JUMP style of movement, we thought about trying something different in this area. The game of golf came up, and thinking of the player launching themselves as though they had been hit by a club began to stick with us, and so we started to run with it!

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...
Reaction Speed: Keeping up with the golf ball is difficult at higher speeds. Slowing down time while you aim allows for precision, and makes you feel cool!
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

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

The last step of the project was to add tone reproduction to the scene.

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.

Theory and the Real World

What is next?

Current State of the Raytracer

Work Cited

Current State

Extra Additions to the Model

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.