Game & System Designer
Ghost Rush
A game of gold and goblins
Ghost Rush is a 4-player game where players play as ghosts and attempt to possess a goblin in an attempt to gather gold and return it to their respective portals.
My Role
With a small team of four, I helped design the game from a simple paper prototype, to a fully thought out game. I also helped shape the core design pillars for the three games we would design.
I worked in engine to build the game level, assemble most game components and work with the unity asset store to build the game.
I was one of two core programmers on the project. I worked on the player controls system and other core gameplay components
I sourced audio for the project.
The Challenge
In teams of 12, create 3 games (2 digital/1 physical) that all implement shared mechanics. All 3 games were to be made in the scope of 4 days in a Sheridan hosted game jam.
Project Breakdown
The Plan
Shared core mechanics:
-
Interception
-
Launching
-
Restricted Movement
Our Thinking
Even though we could have easily made a slow paced, casual physical game, we wanted to leverage what made physical games unique; the physical skill requirements of players.
​
This locked us in to create some fast paced games with player versus player competition, which would help guide our digital designs later on.
​
To the left, there are three mechanics that we settled on for the core pillars of our three games. I will go into them in more detail later.
Playtesting the physical game at the Sheridan sports center
Methodology
We started out by considering what tools were available for us, as we needed to create a physical game that followed the same restrictions, so as a team of twelve, we went to the Sheridan fitness center to assess what we had to work with.
​
We experimented with a number of pieces of equipment, and what sort of mechanics we could create with the simple tools available.
​
Once some possibilities had been explored, we continued back to the drawing board where we deconstructed the initial physical game prototype into its core mechanics, and defined three that we would want to work with.
​
We then broke into smaller teams of four to continue with three separate, but related prototypes.
Deconstruction of the physical game.
​
Click on image to zoom in
Launching Interception Movement
To launch something is to put it on a calculated/semi-guaranteed trajectory. Typically, when launching there is a specific target in mind.
​
Launching takes time, and tends to be inaccurate in inconsistent environments, such as a playing field. This means that on the playing field, much forethought is required. It also allows an opportunity for players to assess the situation and react accordingly.
​
This will often leave opportunities for imperfect play, leveling the playing field so to speak.
To Intercept something is to receive something before it has reached its intended target.
​
Interception requires something worth receiving that is at some point vulnerable. This mechanic goes hand in hand with launching. This means that in many cases, the launched object will have some value for the context of the game.
​
Launching and intercepting create the conflict that will be a core element in all three games.
Movement (or movement restrictions) is a key identifier for each of the games.
​
Movement restrictions are rules enforced by the engine (or a referee) that make it difficult for players to both intercept and launch things.
​
Movement is core to these games and it can completely change the gameplay experience.
The Prototype
The Design
After some brainstorming, looking at interpretations of our core design pillars, and considering what we were capable of executing, we came up with our design.
​
Players will compete in a free-for-all competition to collect gold in a dungeon that is protected by a single goblin. Players will be ghosts who desperately attempt to steal this gold by possessing the goblin and having him deliver the gold to each ghost's respective portal.
Ghosts can move freely through the brick walls of the dungeon, but they can only move in a straight line outside of the walls. Ghosts will move to the edge of a wall and launch themselves toward the goblin. If a ghost collides with the goblin, it then possesses the goblin and assumes control of the slow goblin. That player will then try to move toward their portal without getting hit by another ghost flying through the air, because if the goblin gets hit, the other ghost gets to take control of the goblin and the original ghost gets thrown all the way back to their starting point.
​
The game is based on a simple timed system where the ghost with the most gold at the end of the timer wins the game.
Paper Prototyping
With a small amount of time remaining, we needed to make sure that we addressed out problems early. We quickly drew up some simple symmetrical levels, then drew a large version of the one we wanted to implement in engine.
​
Next we simulated gameplay using dice to imitate players, a poker chip to represent the goblin, bingo tokens to represent portals and a pencil to move around the possessed goblin.
​
we would flick the "Ghosts" towards the "Goblin" in an attempt to possess it, them slowly moved it around to avoid getting hit by a "Ghost".
​
This gave us an opportunity to simulate what some of the gameplay moments may feel like in engine. The flicking was a good solution to simulate inaccurate wall launching, and then experiencing the consequences of missing the target.
We also realized how difficult some level ideas would be to keep balanced for all players, so that kept us set on our simple mostly balanced final level.
Audio
In-game Audio
Due to complications earlier on in development, audio was pushed to the end of the development, and unfortunately was not complete by the deadline for this specific game jam.
​
Press play below to get a sample of what the game would have sounded like, and follow along with the video below.
Battle of Pogs
by: Komiku
Audio profile
In this game, we were going for a fun retro theme. I knew that we wanted the game to feel fast and exciting at the same time as well so we decided to go with a faster bpm, chiptune track for the gameplay.
​
The "percussion" notes are very consistent and they act as a metronome to pace the gameplay while the bass line grounds the music and the players to the section that the music is playing. The melody is not very repetitive, so it is very easy for the players to understand how much time is left in the round without looking at the clock.
We were going for a cute/spooky aesthetic throughout the game, so this track worked for a number of reasons. The detuned pitch of the song help drive the haunted vibe in the level, especially when accompanied by some occasional dissonance between some of notes used. The track is also well balanced with harmonics, and harmonic arpeggios to keep it on the more positive/powerful side.
The track itself does little to promote the cutesie aesthetic of the game, but that was to be covered more by the in-game sound effects (that unfortunately didn't make it into the final build).
Take-aways
My Take-aways
Though this was just a game jam project, I still got a lot out of it.
​
We used a rapid prototyping method so we could fail faster and iterate sooner, which helped us stay on track.
​
Something that I don't often face is a team creating multiple games at once (as a studio might do). This was a great social development opportunity where I was able to leverage other's expertise when I needed it and could do the same in return. Though I only officially worked on the Ghost-Rush, I was very familiar with these other projects and was often able to quickly interpret their problems and help find solutions.
​
I did not act as a team manager on this project as I was the junior on my team, but I learned a lot about task and time management. I learned a lot about how long things take such as animations and system development.
​
We ran into a fair share of issues when it came to programming the game as a team. Coding standards were non-existent, and we two coders had very little idea on how to interface with the other coder's scripts. In this case, more problems were presented than were solved, but it gave me some perspective on how I would be able to improve on those skills later on in other projects. I now preach "An hour of planning can be saved by simply day of programming".
Team Trailer/ Instructional video