top of page
- Quarry Kickin' -
Tools:
Duration:
8 months
Team Size:
6
Party Game
Physics-Based
Pvp
Unity
C#
Project Description:
A 2v2 party game where teams compete to collect the most gems over three chaotic rounds of play. Players can place bombs and kick around a variety of objects in the quarry, all as a means to come out on top. Every moving part in the game interacts with the others, further driving the chaos, emergence, and replayability.
My Role:
I was one of the main programmers of the project while taking on game design with the rest of the team. I was responsible for implementing many of the game systems/mechanics. I prioritized prototyping quickly, creating an efficient structure in-engine for the team, game balancing, and pushing to create meaningful interactions.
Working in-Engine
Engine Workflow
Being responsible for the project's state in the engine, I shifted my focus based on the game's needs to ensure we prioritized the right elements, adapting between:
​
1. Quick prototyping:
To allow the team to validate any design concepts and test potential ideas
​
2. Iterating & Polishing:
To bring each element to a usable state that players can understand/engage with
​
3. Balancing:
Addressing any elements that needed tweaking & experimenting with different values to keep interactions meaningful
​
4. Optimizing:​
To ensure that while the project evolved, so did code, updating exisitng scripts and cutting obsolete processes to keep the project stable and without error.
Early Prototype of the Minecart & its interactions with the environment
Gameplay Balancing Document, to track and evaluate what has/could change and why
Early prototype of the Drill powerup & all of its possible interactions
Maximizing Discovery & Interaction Space
To maximize the possibilities within such a small scope, a big priority of mine was to find as many engaging interactions as I could. By using the existing elements of force-related physics and destruction from the core loop, I was able to get more out of those existing scripts in other areas. This allowed me to not only create more interactions that led to emergent scenarios, but also allowed for a very efficient development process.
​
Some Key Systems​
I was involved with the development of almost every system within this game, whether from scripting something initially, adding/changing logic, or assisting others on the team. A few of the major ones that I was heavily involved in included:
​
Bomb & Gem Interactions
The two most used objects in the game:
Bombs: Has a cook time and explosion radius, detecting what to destroy and what to push away.
Gems: Can be lodged and released from terrain, react to physics elements, can be picked up by players, and scatter when dropped.
Powerups
Powerful tools to get the upper hand, intentionally designed for offense as defending a repository is naturally easier to accomplish:
Jackhammer: Temporarily allows the player to traverse underground, exploding everything around it when emerging. Designed for mobility and combat.
​
Drill (seen further up): Increases in speed while decreasing in control and explodes on impact, designed for mobility and combat.
Repository
The sole way to obtain points towards the objective:
Nodes: Repository randomly emerges/leaves nodes within the level for a fixed duration.
​
States: Either empty, depositing for a team, contested, or inactive.
​
Progress: Standing within the radius fills the team's progress unless contested. Once progress is complete, the gems held within the radius are rewarded as points
Level Gimmicks
Hazardous elements that create unique environments & interactions within them:
Powered Cart: Follows a spline, kills players, destroys terrain/large gems.
Kickable Cart: Follows similar logic to the powered one, but moves by reacting to forces (kicks, bombs, etc.)
​
Pit: Bottomless holes that players can be kicked into and lose their gems.
In-Engine Structure / Tools
Level Generation, Creation, & Structure
I created the following systems to help both my team and I to create consistent and organized levels:
​
1. Tile Map System: A series of different tile types that follow rules based on their neighbouring tiles. It uses a Perlin Noise algorithm to create natural, flowing terrain with a threshold to automatically create cave pockets and void tiles to keep controlled spaces from being caved-in. ​​​​
Example of terrain generation using Perlin Noise
Grid view & all tile types
​​​2. Random Level Selection: A full round of play consists of 3 levels that get more complex as you go. To encourage replayability and give players more variety to explore, I created a system that randomizes which levels are chosen based on which stage the game is in. This creates anticipation for what levels appear next and allows for the expansion of more levels to be easily added.​​​​​​
Scriptable object holds a list of the possible levels for the current round
Then the chosen levels data is used accordigly
​
3. Intermission Sequence: I wanted to keep the continuity of the game flowing while still giving the players a moment to pause and converse between each round. To do this, I created the functionality of an intermission sequence that includes: gem piles counting up each team's score, skydiving functionality to bridge the gap between rounds without fully halting player input, and an upcoming level tracker to prepare players for what's to come. Also, it's a nice narrative touch conveying that players are going deeper into the quarry!
Personal Takeaways
-
Experience bringing a project from prototype to beta, adapting through our pipeline, and handling a project of this size
​
-
Furthering my experience in game design, focusing heavily on systems and player interactions. ​​​​
​
-
Furthered my capabilities and confidence in handling responsibilities in the engine, scripting knowledge, and collaboration with other disciplines.
​
-
Gained experience in collaborating with a team for a longer-term development of 8 months.
Team Picture at Toronto's
'Level Up Showcase'
bottom of page