Golden Loft

 

This slideshow requires JavaScript.

In Golden Loft, you will explore your grandfather’s attic and uncover his fascination with the Golden Ratio. Through this journey, you will learn about the Golden Ratio and Phi. Some of the greatest mathematical minds throughout the ages from the Ancient Greeks to modern day have been entranced by the Golden Ratio and its properties. But this is no boring lecture. Play with various contraptions and curios that your grandfather found in the world and brought back to his attic. Dive into the history of the Fibonacci Numbers and how they got their name, alongside where those numbers appear throughout the world. But most interestingly, you will discover how all of these elements are intertwined and have fascinating relationships with each other, and appear throughout nature, architecture, and art. Play, explore, and learn about the Golden Ratio and Phi in Golden Loft.

This game is available for free on Oculus Rift, Oculus Go, and Oculus GearVR.

This game was created over the course of 3 months with a team of two working full time. The game is designed to teach people about math, without requiring any math or calculations to progress through the experience.

My partner and I inherited this project from another team, furthering their initial concepts and making the game our own. We added more than five times as much content, as well as creating a narrative and tutorial for the game.

For this project, I was in charge of Design, Programming, Research, Writing, Usability, and Sound Design. I ideated and itterated upon every lesson and interactable within the game, as well as implemented and optimized every lesson and interactable. If you would like to see a code sample from this project, please click here.

I also researched Phi, the Golden Ratio, and Fibonacci Numbers extensively, and wrote the dialogue and voice over to condense what I had learned into easily understandable and interesting lines for the player to learn from as they play with various interactables.

Finally, I sourced most of the sounds in the game, as well as editing them to make them appropriate to the context of the game.

Tiny Trees

This slideshow requires JavaScript.

Tiny Trees is a competitive tree-building game for 2-4 players where you are a nature spirit trying to become the next Demigod of Trees!

Unlike most board games that lie flat on your table, the trees you grow branch out into the third dimension! Whether you want to relax and creatively grow a tree or focus on the deep-rooted strategy to win, you’ll be creating something you can be proud of from the moment you open the box.

Click here to view our presskit!

This slideshow requires JavaScript.

Tiny Trees has been showcased at 4 conventions including Minefaire Houston, Minefaire LA, USC Games Expo, and Indiecade 2018. Tiny Trees was selected as a Indiecade 2018 Finalist!

Tiny Trees also successfully funded on Kickstarter in July 2018, raising over $8.5K from a goal of $5.8K!

Tiny Trees was originally selected as a final project for USC’s cornerstone Game Design Class, where I spearheaded a three-person team in the creative direciton and iteration of mechanics and gameplay.

The game is designed to make players feel proud of what they have created in the process of the game, which led to the creation of a competitive but not adversarial game system.

I have proctored this game in over 70 playtests throughout development, with a focus on delivering upon our user experience goals and easy understanding of our rules. To see an example of the analysis I performed through playtesting, please click here.

Tiny Trees Website

Twitter, Instagram, Facebook

Non-Disclosed Government Contract

DoD Seal

I developed a Department of Defense virtual reality experience, experienced by over 230 people in a private setting, including high ranking executives, elected government officials and Air Force personnel.

The game experience was made using Unreal Engine 4 over the course of a week, and I was primarily in charge of programming, maintaining build stability, and usability.

For usability, I designed a method for the players to intuitively understand where they could and could not travel, as the percieved space was much larger than the walkable area.

The virtual reality experience “went beyond [the client’s] objectives… [and] raised the bar for all future design reviews…”

Additionally, the experience allowed the client to “get a meeting with an external organization that they have been trying to meet with for several months with no response.”

The Trinketeer – 5e Homebrew Class

The Trinketeer is a custom homebrew class for Dungeons & Dragons 5th edition, allowing the player to create custom modular trinkets for a large variety of effects. Currently there is only one subclass – the Specialty of Traps – but is formatted for the possibility of expansion. Although the Trinketeer is not a spellcasting class, many of the trinkets can feel like spells or function similarly.

The Specialty of Traps is designed for more cunning individuals who want to add an extra level of strategy and planning to their D&D combats. With the possibility for the player to make custom bear traps, timer traps, wire traps, proximity mines, and small dimensional portals, a clever trap maker will always have a tool at their arsenal.

Although the class is similar in nature to the official artificer, this class is unique enough to warrent it’s own classification, similar to the difference between a wizard and a sorcerer.

The module was created using Homebrewery, and sources for images are in the document, with additional watercolor effect made by myself.

If you would like to download this class and play with it for yourself, click here to view a pdf!

Trapped!

You all have been living together for at least several weeks. Recently, people started picketing outside your house. More keep coming. They’re all angry. A Mob is forming. Words on the wind. “Kill them.” “Burn the whole thing down.” Survive against The Mob.

Trapped is a one-page tabletop RPG where your primary goal is to survive the ever growing mob. Trapped is an incredibly flexible system that fits into any level of fantasy or time period that uses a unique mechanic to decide the outcome of uncertain events. Instead of rolling dice, you draw cards from a standard deck of playing cards.

Click here to see the RPG for yourself!

This one-page tabletop RPG was designed for a tabletop RPG class, where we had to design an RPG based on a Grimm’s fairy tale. I selected The Owl, which tells a tale of an owl who rested in a barn, but was mistaken for a monster by the farmers. Many try to rid the barn of the foul beast, but none are brave enough to do so. Ultimately the angry mob decides to burn the barn down with the animal inside.

Trapped! plays out from the owl’s perspective, where the angry mob gets ever closer and closer to killing everyone inside. In order to capture the feeling of an uncontrollable angry mob, I created the deck system instead of rolling dice, in order to phisically represent how much time the players have left. The additional element of randomness also adds to the feeling of the angry mob, as they become further enraged for no apparent reason.

I’m particularly proud of the relationship mechanic I created for character creation, where each player determines their relationship with the player on the right. This leads to emergent gameplay, and informs the player how they should be interacting with other person, which is useful when a game shouldn’t last more than an hour or two.

Going Up

 

This slideshow requires JavaScript.

Going Up is a single player puzzle platformer for the PC where you are a slime trying to escape a steampunk factory!

Gravity is all out of sorts in this factory though, so whenever you let go of a surface, you fall to what you concieve is “up”. However, there is no true up. Will you be able to escape the factory or will you get disoriented and never find your way out?

Click here to download the game to play it for yourself!

This game was selected to be developed as a final project in the University of Southern California’s Introduction to Game Development class.

I spearheaded a two-person team in the ideation and iteration of core mechanics and level design. The levels are designed to create interesting puzzles through a simple set of mechanics. As part of this level design, I also tested the levels to ensure functionality and that they were challanging the player.

I was responsible for over 80% of the programming within Unity, which you can see a code sample here. As part of the project, I designed the stages with usability tutorialization principles to make teaching learning the game’s mechanics fun and engaging while also being educational.

In addition, I created a press kit for this game, which you can see at goingupgame.github.io. The final level of the game has a large jump in difficulty, since it was intended to showcase the complexity possible with the game’s simple set of mechanics.

Masking the Murder

This slideshow requires JavaScript.

Masking the Murder is a third person rhythm action hybrid game for PC where you play as an assassin aiming to get revenge on one who betrayed you. Set in a grand dance hall, your target is hidden amongst the other dancers in the room. Remain hidden and blend in to close the distance to take them out. Will you mask the murder?

If you would like to try this game for yourself, click here to download a build for Windows and Mac!

Masking the Murder was developed over the course of 10 weeks with about 160 people hours worth of work. Except for a handful of assets, all content and assets were created during this time period. I programmed any system that interacted with the music and rhythm, as well as about half of the other code. For a code sample, please click here.

In addition to programming, I rigged and animated the characters, as well as modelled the trees and the chandeliers.

Masking the Murder was inspired by a scene from John Wick, where John was in a large dance hall, shooting on beat with the music in order to remain undetected.

This game also served as an experimental test to work with third person cameras, as well as creating a rhythm game, especially one mixed with a shooter.

Crystal Mutation

WalkCycleGif

Crystal Creature_Still

This model and animation was created as a final project for a technical rigging class at USC.

I created everything from scratch using Maya 2018. The spine is controlled by a spline IK, and each of the legs are IK with a Pole Vector. Each crystal is an individual object, but the body is a singular mesh.

I chose not not model hands or feet since the crystals grow out of the subject’s bones, and given the density of bones in the hands and feet, would quickly become overgrown with crystals.

Tiny Trees Post Mortem

An integral part of designing a game is following user-centric principles and iterating in order to provide the player with the best possible experience. However, some games have difficult components that are expensive in both money and time in order to iterate upon. This was the case with the game that I am the lead developer on that will be on Kickstarter later this year. Tiny Trees is a competitive Tree-building board game where unlike a large number of board games, it doesn’t lie flat on your table, but instead becomes a physical object in three dimensions. As you grow your tree, you have to try to earn the maximum number of points while also literally balancing your tree so it doesn’t collapse.

Building

The game consists of 42 hexagonal cards that you slot together in order to grow a physical three dimensional tree. It was extremely time consuming to iterate on these components since the prototype needed high quality cardstock and had to be cut out by hand and individually drawn on. As such, the design process had to be predicated more on math and statistics rather than continuous playtesting in order to not waste valuable resources.

We had to determine what arrangement of cuts in the cards we wanted. The very first prototype had cuts on all six sides of the hexagonal cards, but I found myself growing roughly the same tree every time since there was no restrictions on what I could grow. Additionally, if each side of the hexagon had only one slit to reduce complexity, each side would have only two states: cut and not cut, represented below with a six digit binary equivalent.

BinaryDiagram

When that six digit binary equivalent is converted to our standard ten digit unit of numbers, that gives a total of 63 possible arrangements of cuts on the hexagonal cards. However, this does not account for rotations or mirrored images. For instance, the leftmost hexagon shown above is still functionally identical when rotated 60 degrees. As such, when accounting for this repetition, there are in fact only 12 unique designs.

Although this number of unique designs seems innocuous, it was significant in my process since it established what could or could not be done with the cards. While we could create cuts that weren’t centered on each side of the hexagon or multiple cuts on one side, having knowledge of what options were available to us allowed for accurate design.

On a similar note, designer Mark Rosewater has repeatedly said that “restrictions breed creativity”, and I found that to be exceptionally true (Source). In the case of Tiny Trees, the very first paper prototype had cuts on all six sides. However, this did not lead to building any interesting trees since players would default to what they were familiar with rather than going out on a limb and trying a new structure. At the opposite end of the spectrum, if all of the cards had only two cuts, the players wouldn’t have enough choice in what they could grow. Having all of the cards with only two cuts didn’t provide enough options to the player, and six cuts provided too many, so the ideal must be somewhere in between. In the final version, there are five cards with two cuts, four cards with four cuts, and two cards with six cuts for each of three types of trees. We decided on this arrangement for three reasons: It gives an average of roughly 3.29 cuts per card, each number of cuts had a total roughly equal to 12 – the exception being the cards with two cuts – and the distribution of the values was appealing since each level has one fewer card. Additionally, by having more cards with only two cuts, it allowed the trees to become more interesting while the higher number of cuts allowed players to still have sufficient options in growing and balancing their tree.

MathDiagram

While this math for achieving the average number of cuts per card (in which you add the total and then divide by the number of cards) is very simple, it still influenced our design decisions. Since we were aware of the average number of cards as well as the specific distribution, it gave us a much clearer understanding of the system that was in place and how that affected the player’s perception of the game. This in turn allowed us to quickly fix and understand any underlying issues that arose in playtesting. For instance, we were able to identify that even though playtesters didn’t directly address an issue with the distribution of number of cuts, we were able to more accurately identify it as the underlying issue due to the knowledge of the distribution.

At the end of a game of Tiny Trees, players earn points based primarily on two factors: the hexagonal cards that they grew onto their tree, and lifeforms that are also found on the cards. We added the lifeforms to increase the strategic depth of the game, as well as make the decisions more interesting.

LifeformDiagram

The three types of lifeforms: Beetles, Mushrooms, and Birds

From the player’s perspective, without an additional incentive, there was little reason in selecting the cards with fewer cuts since it restricted their growth and made balancing their tree more difficult. By adding lifeforms as a mechanic, we had to balance three main factors: the number of lifeforms, the distribution of lifeforms, and the amount of points that the lifeforms were worth. In order to achieve this through math due to the limitations of our ability to iterate, we used a hypergeometric calculator liberally in determining these factors. Hypergeometric calculators are often used in card games where you draw some number of cards and then want to know the odds for drawing a certain card. In this context, we wanted to know and be able to control the odds more precisely rather than just intuition. An important design decision that we had made previous to adding lifeforms was that each option available to the player should be of equal value to a similar decision. This comes from the number of cards for each type of tree being completely equal, even to the distribution of number of cuts. Thus, we wanted to do the same for lifeforms, but be willing to alter that methodology given the numbers and math behind them. As such, we needed three types of lifeforms and more than one of each. We ended up settling on six of each type of life form, separated evenly between each type of tree. The advantage to this is that if a player wants to grow their tree with all of the birds available to them, then they aren’t shoehorned into one specific type of tree.

When it comes to the math, that means that roughly 43% of all of the cards have lifeforms, and that there is a 45% chance that exactly one of the top three cards that the players can choose from will have a lifeform, and a 25% chance that none will have a lifeform. Obviously that percentage changes as more cards are selected, but this knowledge helped us quickly refine the game – similar to the knowledge of the distribution of cuts. When it comes to what cards have the lifeforms, we focused on the cards with fewer cuts on them. Our reasoning was that if lifeforms are worth additional points, then the players should be incentivised for restricting their growth options, but not so much that it is obviously better than the ability for options and balancing your tree.

Then came the question of how many points should each lifeform be worth. Since the cards reward you for collecting more of the same type, so should the lifeforms. However, the scaling of points can be either linear or exponential. We decided on an exponential growth model, so that players are incentivised to collect the same type, but that collecting them incidentally doesn’t have that large of an impact on the overall point total. Specifically, the first two are worth one point each, the next two are worth two points each, and then the final two are worth three points each.

By designing our game while taking the numbers into consideration rather than just working off of intuition, we didn’t have to playtest or iterate on our designs as much as we would have to if we only gathered data from reactions from playtesting. While using this math obviously doesn’t eliminate the importance of playtesting and iteration, we were able to save a lot of time and resources from creating additional paper copies of the hexagonal cards and allowed each playtest to be more efficient since we were able to more accurately identify underlying issues and needed balance changes.