Game Design/Development
Proofs of Concept
Overview: This proof of concept combines a full Tower Defense game with an uncontrollable cat, by theming it as a tabletop game.
​
The capsules try to make it from the top left to the lower right. The player places walls to delay the capsules, and places towers to attack them. The player's cat causes chaos and adds unpredictability to the game.
​
Context: 1 week to make a Tower Defense game.. 2 programmers, 2 3D artists, 1 2D artist.
​
Role: coded the navigation for the minions and the cat, coded a destination selection script, coded the pick up system, coded the minions to die if they are beside a tower
​
Design Decisions:
-
How does one integrate a cat with a TD? Tower Defense games typically have a rigid structure that determines where the mobs are allowed to walk. If the ground isn't flat, would the cat get stuck in the trenches? Should the Tower Defense be completely 2D? If it is 2D, how to make the player care about it? How difficult can you make the tower defense game if the player also needs to worry about an uncontrollable giant? All of these questions were answered by theming the game as a tabletop game. The towers and wall pieces are basically wooden blocks that can be positioned freely. The minions take the path of least resistance. The cat picks a random object to head to, and knocks over everything in its way.
-
Dropping blocks onto minions kills them instantly. All the objects are physics based.
TD + cat
Overview: A tech demo of black hole physics in a randomly generated level. Players can click a nearby surface to generate a black hole, which in turn is used to collect all of the physics objects (like 40 of various sizes and frictions).
​
Context: Had to make a project the featured a variety of Unity physics interactions. I decided upon this system because it combined raycasts, gravity, physics materials and other elements into one cohesive design.
​
Role: FPS camera logic, black hole physics
​
Design Decisions:
-
Black holes only absorb objects that are directly "visible" by the black hole. It won't apply the physics if a wall is in the way.
-
The main characteristic of each object is color coded. Red means high friction, yellow means standard, green means no friction, blue means bouncy.
-
Created my own logic for handling the FPS camera, which is often rather imprecise.
Black hole based FPS
Overview: Solve puzzles by hopping dimensions through use of mirrors. In this basic puzzle, player's have to escape a room. They enter a mirror, remove the door from an alternate dimension, then return to escape.
​
Context: A prototype for a friend. They really wanted to prototype a game concept, so I offered to do it for them.
​
Role: single person project
​
Design Decisions:
-
I concidered having several characters moving through alternative dimensions simultaneously, but it made more sense to just move the main character from one space to another
Prototype: mirrorverse puzzle
Overview: I theorized how to recreate Dishonored's Blink ability it in Unity, and then I made it.
Context: In Dishonored, you receive a short range teleportation ability (called "blink"). The ability shows where you will teleport to and typically where you will land. However, if you aim just below the top of a building, the main character will climb on top of the roof upon teleporting.
​
Role: single person project
Prototype: Blink from Dishonored
Overview: I made a Slenderman/Weeping Angel based on Unity's Navemesh.
​
Context: Slenderman/a weeping angel will only move if no one is watching them. As such, the A.I. will move toward the player if they aren't looking at the enemy, or if there is something blocking the player's view of the enemy.
​
Role: single person project
Prototype: Weeping Angel
Overview: Instead of matching 3 titles in a row, the player must create crafting recipes. These crafting recipes are inspired by Minecraft's 3x3 crafting table. These recipes produce warriors to combat the A.I. attackers.
Context: 1 week to make a match 3 type game. 2 programmers, 1 2D artist, 2 others
​
Role: tile grid system, algorithm to check whether a recipe was matched, asset class so teammates could create recipes.
​
Design Decisions:
-
Players have to manually submit recipes to craft anything. To support this, switching two tiles is not required to instantly create a match.
​
Lessons Learned:
-
Even in some basic playtesting that I did using Minecraft inspired recipes (meaning I knew them relatively well), crafting in a match 3 game is quite difficult. Players in this prototype are required to recognize arbitrary patterns in the midst of a numerous unfinished patterns. Beyond the inherent difficult of using this system, enemies are being spawned every second. It's possible to develop the game further, but it's starting from a place of immense challenge. The first thing I would do to improve this game is to add another system that simplifies pattern identification. For example, maybe middle clicking would slight darken blocks around the area that don't fit into a pattern. That way, those getting stuck finding the pattern could at least check if there is one near completion.
Crafting match 3
Overview: A third-person shooter where taking damage or nearly taking damage (supression) changes the players Field of View so they can't see their surroundings as well.
​
Context: A prototype for a friend. They really wanted to prototype a game concept, so I offered to do it for them.
​
Role: single person project
​
Design Decisions:
-
Unity default character scripts were imported, but none of them allowed normal third person shooting. The normal first person script wouldn't allow third person mode, and the third person script kept rotating the camera. So the camera script used is custom.
-
The actual FOV does not change on hit, the camera zooms closer to the character - which is meant to feel disorienting and claustrophobic.
-
2 models were chopped in half to fake animation blending.
Prototype: Field-of-View-limiting supression
Overview: A piece of gum parkours its way through a busy city. The city features different regions and multiple AI types that each has a different favorite region. Cars and pedestrians are supposed to be much faster methods of getting through the city, but aren't perfectly predictable.
A racing game with time trials and multiplayer.
​
Context: Started as a one-week proof-of-concept. We then developed it over two additional months. 2 coders, 2 3D artists, 1 2D artists.
​
Role: Gum movement system, gum camera system, pedestrian/car spawning and AI, gum destination AI
​
Design Decisions:
-
You can always change camera angles (originally you had to be attached to something, and they alternative views were treated as contextual camera views). The pink line under the gum shows which way the camera is aiming.
-
You can glide slightly in midair. This allows more control when jumping, but the ability is unusable when stuck to something.
-
Cars and pedestrians mostly follow North American traffic laws. How I made realistic intersections/ navigation
-
Each car or pedestrian receives an A.I. type (and would change what they look like too) upon creation. Once they arrive at their destination, another is chose for them based on their prefered region(s) of the city. This destination selection system works for cars, pedestrians and the player's goal markers. How I handled destinations
-
Recently (as shown in the gif), I added an overhead camera to serve as a minimap. We had one before this, but using an actual camera rather than an image is much more scaleable.
-
It is still far to easy to hop to a destination without using people or vehicles. There is no real discouragement to this, and the objects that players can attach to move very slowly. More importantly, the city is very small in this example.
-
Because car navigation is imperfect, each car has a randomized level of patience. If stuck for a period of time, they reverse. This helps to alleviate traffic jams.
Gum Racer
Overview: Like a game of mad libs, but against another player and themed for greeting cards.
Context: Group of 2 programmers, 1 writer, 1 writer, 1 other. We had to use scriptable Unity assets.
​
Role: The system to write the cards, the system to play with the cards
​
Design Decisions:
-
The list of word types (nouns, verbs, etc) can be edited independently of the game scene. The coder and the writer could contribute to the game at the same time.
-
The card allowed a number of three part phrases – a beginning, a required word type, and an end. E.g. “I would like to give you a [hug] today.” This also allows for unpredictable sentences like “I [approve] of you… yelling at your neighbours.” The system provides freedom to the writer to create a variety of phrases from the same system. It is also reuseable in case we wanted to try a different theme. Once all the answers have been provided, players could finalize the card and all sentences would be compiled together. Two players can attempt to fill in answers, and a third will judge which result is better. I realize it would make more sense to make this a 4 player game because no one makes 3 player games.
Greeting Card Fighter
Overview: A third-person shooter where taking damage or nearly taking damage (supression) changes the players Field of View so they can't see their surroundings as well.
​
Context: A prototype for a friend. They really wanted to prototype a game concept, so I offered to do it for them.
​
Role: single person project
​
Design Decisions:
-
Unity default character scripts were imported, but none of them allowed normal third person shooting. The normal first person script wouldn't allow third person mode, and the third person script kept rotating the camera. So the camera script used is custom.
-
The actual FOV does not change on hit, the camera zooms closer to the character - which is meant to feel disorienting and claustrophobic.
-
2 models were chopped in half to fake animation blending.
Prototype: Field-of-View-limiting supression