Game Design/Development
Overview: 1-2 spaceships fly around player-spawned planets
​
Context: This game was made in under 5 days. A group of 6 worked on this project (3 for coding, 2 for art, 1 for sound). The game had to appeal to patients at Holland Bloorview Kids Rehabilitation Hospital and was to be feautred on the hospital's ScreenPlay floor gird.
​
Role: Bridging information from the floor's input manager to the game's requirements, tile management in the game, planet selection/spawning/manipulation. I also facilitated the discussion that led to this idea.
Design Decisions I was responsible for:
-
Tile input vs planet management. I organized the tile grid from a 10x10 grid into a 5x5 grid for planets. Each piece of the 5x5 controlled one planet. Stepping on one tile from the 5x5 grid would spawn a small planet. Stepping on an adjacent square would make the planet grow. If 4 tiles are pressed, the planet grows to its largest possible size. With size comes influence over the spaceship's flight path. It is my hope that it would allow wheelchair users greater influence in the virtual world.
-
Planets would be randomly selected when a tile is pressed.
Adrift
Overview: In a world where tradional death penalty methods are falling out of favor, one executioner attempts to defend his occupation by showing off how much more entertaining his method is. A puzzle game.
​
Context: had to made for a tablet
Role: all of the programming, imported art/sound assets, implemented them, wrote any text.
​
Design decisions:
-
Originally the axe was launched via flick. Playtests revealed that an Angry Birds style launch was more appropriate/accurate/fulfilling.
-
One 3 finger tap will reset the game.
-
Every object can be pressed to learn about its behavior and "hype" (points) value. Tap to see this description.
-
Each level has a straightforward way and at least one fancy way. The straightforward way bypasses almost every object that rewards points (except the final guillotine). The fancy way generally involves hitting every destroyable object with one throw.
-
There is a large axe that may hit the guillotine for points, but is not required to avoid wooden objects. The original design plan was to use multiple axes that were already in the environment to chain additional point chains. There was talk of being able to win back axes and have multiple in queue, but that was axed due to time constraints.
-
The arm rotates based on how far away the axe is. ++ animation.
Capital Punishment
Overview: internet gaming references are added to a basic breakout game to increase the amount of feedback it provides.
​
Context: The concept is titled "juiciness" by some game developers. The goal is to add animation to objects and increase how greatly user input affects the game world. The game started with basic tile generation, paddle movement, a ball.
​
Role: recoded ball so it bounced at a minimum angle and can't roll up the wall, added killstreaks, implemented art and sound effects, did all of the text, made the replay system, made the ball move faster if it is above a certain height, made time slow down for an epic last hit
​
Design decisions:
-
There is a special first hit sound, second last hit sound, last hit sound. Other than these, each successive hit plays a sound effect and increases the killstreak. The higher the killstreak, the more chaotic the noise and visual effects. If a player attains a thirteen killstreak or higher, the numbers disappear and an abstract visual reference is shown. This reference is supposed to emulate game replay videos from Youtube, but usually involves much flashier/more disruptive visuals.
-
The ball can't get stuck bouncing horizontally, as to avoid needing a reset button. More balls can be added (up to 5), but it is much easier to lose them. Upon dropping the ball, a replay will show that moment again and erase the killstreak.
-
When only one brick remains, time will slow whenever a ball approaches it.
MLG Breakout
Overview: Players protect a number of objects by deflecting falling UFO's away from them.
​
Context: The basic game was started in school, but was mostly developed outside of school
​
Role: I was the only person who worked on this
Takeaways:
-
Analyze bugs in terms of game design. In this case, missiles pushing UFO's instead of destroying them forces greater prediction from the player.
-
Allow players to do what they want and add appropriate consequences. Players can spam missiles, but that will put them in a less defensible position. UFO's receive greater downward force the longer players survive and aim toward wherever the player is. Missiles move players in the opposite direction, and spam can either aid dodging or deflection of UFO's later in the game.
-
Maintain what elements you find fun. I enjoyed filling the screen with missiles. Part of the charm came from shooting more missiles than necessary, and then having one of the extras bump a UFO toward the tanks. Before tanks rotated with the cannon, spammed missiles could make a defensive roof over the remaining tank. I tried creating a reserve missile system, where players could fire up to 5 at a time, and they would regenerate by one every second. This invoked frustration when UFO's attacked and players had no missiles to use. My intention was to create a light-hearted game and I decided against limiting missiles. Instead, the houses would be in a more dangerous position whenever the player attacked. In an earlier version, players could rotate so the UFO's bumped wayward houses back into position, allowing for some mastery of the game.
-
The ship gradually centers and the turret returns to face forward after a period of time without input. This added some realism, but also returned the player to a place where they could revaluate how well they are doing. With no UFO's on screen, the only difference between the start of the game and a minute in may be the number of fuel tanks.
-
There are only 4 fuel tanks instead of 5. The most easily defendable one (immediately below the turret) has been removed. The fifth tank didn't add much to the gameplay (the extra life was negligible, as having more tanks closer together makes losing more than one at a time much easier)
-
Fuel tanks slowly return to their starting positions. This removes the need to push tanks back into position via UFO’s. It takes away that control from the player. However, it now acts in the same way as regenerating health in an FPS. If a tank is “non-fatally” hit, the player holds their breath as to whether it will get hit again, or whether their reflexes can protect it. It adds tension and changes the pace in a normally predictable infinite survival game
UFO Repulsion REDUX
Private AI
Describe your image.
Describe your image.
Describe your image.
(click to expand)
Overview: A hard-boiled robot detective sneaks around cops as he travels from a crime scene to his office. A stealth platformer
​
Context: A group assignment to create a game in Processing.
​
Role: created object class to handle collision; set up a level editor script so teammates could move platforms, enemies, lampposts, doorways; created the darkness effect.
Design Decisions I was responsible for:
-
I really wanted to make a collision parent class so everything could be extended from it (to make collision testing easier). I then made a level set up page that allowed my teammates to position up to five police, lampposts platforms and a door wherever in the level they wanted. This meant I had to determine a logical number of enemies, lamposts and platforms to establish for the whole game before the levels were made.
-
The collision is still buggy, and it allows jumping through platforms. This was incorporated into every level.
-
I really wanted enemy detection to be based on light. Unfortunately, lampposts do not extend enemy line of sight. If the player touches the enemy flashlight beam, they lose.
-
The flash lights can actually split if the bots walk up to a box (the box will block the light). Players can crouch behind the box to avoid detection while the beam searches over their head. I believe we don't have boxes anywhere in the five levels because the police would get stuck in them if it interfered with their pacing.
-
The chasing police of level 4 (starts immediately behind the player) and the falling exit/cop of level 5 are my ideas. They are not particularly "fair" ideas, but they make the game more interesting and memorable. The cop on the 4th level makes use of the pause between when the game finishes loading and the first input of the player.
-
Fun fact, the lights can actually split if the bots walk up to a box. Players can crouch behind the box to avoid detection.
Standalone Games
Overview: A gamifified warehouse created to simulate how a warehouse manager's preference affects performance metrics
​
Context: created in 3 weeks for a summer job
Role: all of the programming, A.I., level design, UI
​
Design decisions:
-
White capsules represent workers. These may be assigned to specific departments and do work there.
-
Everything is color-coded. Boxes that are not received are orange, boxes that are received but not stored are light brown, boxes that are put away are dark brown. Boxes that have a varience are red (when scanned). These go to the red Receiving Clerk. Pallets are blue, pump trucks are yellow. Trucks that require proper scanning are white, whereas trucks that want to drop off their product without scanning are yellow.
-
Users may change how they want the workers to act in a seperate menu. They may also change their controls in a pause menu. The explanation of the numbers in the lower left corner are in a third menu. Help can be pulled up by pressing F1, which reveals the metric explanations can be accessed by pressing M.
-
Learned inheritance in C# so I could make a recursive container script. Boxes, pallets, pump trucks, shelves, trucks, and departments are based on one script that has a list of things inside it. These can be passed between objects so I rarely have to get the component new.
-
Decision making is only done at locations. This is to limit CPU load.
Warehouse Simulator
Overview: A mobile game based on this Source Filmmaker video.
​
Context: created in 2 weeks during school
Role: all of the programming, animation, special effects
​
Design decisions:
-
Went through multiple input systems and visual designs. I wanted users to slide their finger across the screen in some way, to make the input feel more dynamic. The first way was to connect the method of attack (e.g. shotgun) with the target area (e.g. zombie head). It was too easy for the input not to be counted, so I looked for other methods. I decided that I should make a system like Pillage the Village's spell system (4 quadrents, drag mouse from the top left to the bottom left for a low level spell, top left to lower right to lower left for a medium spell, etc. Much like tracing a circle) or like the Android lock screen. The sytem needed large buttons to maximize the likelihood of the game accepting input, but large buttons made looked too closely like telephone dial pads (which are pressed). That often had people poking the buttons. The Android lock screen has tiny dots and my playtesters naturally slide their finger along the demo layout. I combined the two styles to communicate how to use the UI.
-
I learned how to do inverse kinematics in Unity to do basic animations. The characters hands follow the weapon, which I animate to move where needed.
-
Killing zombies looks very convincing at the moment. The system allows decapitations and foot removals, with some really great blood effects.
Ethan vs the World
Overview: One player leads 3 hippies through a forest, while the other plants mushrooms to stop them. The hippies are hoping to see the pink elephants on the other side of the forest, but will totally eat any mushroom they come across.
​
Context: Had a week to make a proof-of-concept. 2 coders, 1 3D artist, 2 2D artists.
​
Role: Set up the game system to handle adding mushrooms, movement arrows, changing turns.
​
Design Decisions:
-
Turning off the camera, but only when switching from the attacking player to the defending player. The attacking player should not see what the defending player has set up, but the defending player already sees what the attacking player sees. The act of turning the camera off instead of covering it was the quickest way to set up turn switching.
-
The hippies don’t use tiles while the mushrooms do. Mushrooms cannot be placed on the 8 tiles surrounding each hippie, nor at the finish line. It takes 2 mushrooms to kill a hippie.
Not Mushroom
Overview: A 2.5D arcade platformer where miners try to avoid a lava wall. Players have a dig, jump, and a special attack. There are 4 different block types: dirt, stone, bedrock and gold. Dirt takes 1 hit to destroy, stone takes 3 hits, gold takes 5 hits and bedrock can't be mined. Each gold hit obtains 1 ore, which powers their special attack.
Context: This game was made in <4 days. 2 programmers, 1 level designer, 1 sound designer, 1 artist, and 1 other. We had to make a game for an arcade cabinet.
​
Role: coded UI, player handling, game over, random level generation, block type randomization, lava movement; designed special attack
​
Design Decisions
-
Terrain is randomly generated. Large chunks are grabbed from pre-existing room prefabs, and then each tile has a chance of switching types on creation. This nigh-guarantees the player will not notice which tiles they have seen before. Additionally, it is impossible to mine out of the map and fall forever. After a certain distance, tiles will be spawned under the player and then around them.
-
The lava originally rose upward. Players cannot mine upward. This forced lateral movement to escape the lava. Not only did this make level design slightly more challenging (given the random generation), playtesters did not understand the concept as quickly. Sidescrolling was adopted to work with player expectations, and also because we were already intending for lateral movement to begin with. The bedrock floor reinforces the lateral movement
-
The lava’s speed is changes based on whether it is on screen or not. It basically matches the player when off screen, and the particle effects are the only hint that it is still following. When on screen it travels at a much slower rate that gets faster as the player gets further.
-
Because this game can be played infinitely, there is a rising banner that notes how many meters the player has made it past. Playtesters felt there was no sense of accomplishment or progressing, as the game doesn’t change over time. The banner was a last minute addition to combat this.
-
The continuation and special attacks are based on the same system. In each case, a wave of energy flies to the right and destroys all blocks. This guarantees movement for that length of time. However, the cost of the player’s special attack increases every time they use it. This increases the likelihood of death and usage of the larger attack.
-
The game can handle up to 2 players. Both players share the screen. If one falls off screen, they die. This prevents both people from dying if they separate too far. If both are dead, the other player may jump in and “steal” the loaded quarter (not shown in the gif).
-
The game will revert to the start screen if there is no input for a number of seconds. This is to invoke the feeling of other arcade games.
Mined the Gap
