ZOË PILGRIM
ZOË PILGRIM
Game Designer, Programmer & Level Designer
Hello! I'm Zoë Pilgrim, a recent graduate of Sheridan's Honours Bachelor of Game Design. I have a background in programming, with three languages under my belt (C#, Java, and Python). I'm super passionate about usability and learnability of game mechanics and UI as well as a big fan of creating meaning through games and their mechanics.
CORPOBOTS
SOL'US
A LION'S LIFE
WIZZARD ESCAPE
BELONGING
MARIO KART 8 LEVEL DESIGN
THAT FLOATY FEELING
LENA THE LEAOPARD
BARREL EXPLOSION
UNITY FPS LEVEL REDESIGN
HAUNTED BOARDWALK (COMMING SOON!)
ZOË PILGRIM
Game Designer, Programmer & Level Designer
Hello! I'm Zoë Pilgrim, a recent graduate of Sheridan's Honours Bachelor of Game Design. I have a background in programming, with three languages under my belt (C#, Java, and Python). I'm super passionate about usability and learnability of game mechanics and UI as well as a big fan of creating meaning through games and their mechanics.
CORPOBOTS
SOL'US
A LION'S LIFE
WIZZARD ESCAPE
BELONGING
ZOË PILGRIM
Game Designer, Programmer & Level Designer
Hello! I'm Zoë Pilgrim, a recent graduate of Sheridan's Honours Bachelor of Game Design. I have a background in programming, with three languages under my belt (C#, Java, and Python). I'm super passionate about usability and learnability of game mechanics and UI as well as a big fan of creating meaning through games and their mechanics.
CORPOBOTS
SOL'US
A LION'S LIFE
WIZZARD ESCAPE
BELONGING
THAT FLOATY FEELING
LENA THE LEAOPARD
ZOË PILGRIM
Game Designer, Programmer & Level Designer
Hello! I'm Zoë Pilgrim, a recent graduate of Sheridan's Honours Bachelor of Game Design. I have a background in programming, with three languages under my belt (C#, Java, and Python). I'm super passionate about usability and learnability of game mechanics and UI as well as a big fan of creating meaning through games and their mechanics.
A LION'S LIFE
MARIO KART 8 LEVEL DESIGN
UNITY FPS LEVEL REDESIGN
ZOË PILGRIM
Game Designer, Programmer & Level Designer
JUST A FAN
Building Just Dance From Scratch
[PH].
WARFRAME DESIGN CONCEPTS
Teaching New Players Modding
A quest concept to aid new players in learning one of the more complex systems in Warframe. Additionally introducing Teshin earlier to help establish his importance to players.
Narmer Plains Restoration
Miss how the Plains of Eidolon looked before the New War? This is a concept for a series of bounties to restore it to it's former glory.
Narmer Vallis Restoration
Miss how the Orb Vallis looked before the New War? This is a concept for a series of bounties to restore it to it's former glory.
[UNNAMMED GAME]
About the game
----
My role
----
Devlogs
A series of development logs summarizing my experience of creating this game from beginning to end.
DEVLOGS
Devlog 01:
Starting Pre-Production
Brainstorming, Team Charter and Pitch Night!
DEVLOG 02:
CONSOLIDATING PITCHES
---------
DEVLOG 03:
COMBAT AND PERSPECTIVE
------------------
DEVLOG 01:
STARTING PRE-PRODUCTION
Introduction
A group of friends from Sheridan and I decided to start a new long-term game project to keep up our skills and put on our portfolios. Our approach was to cater to what skills each individual wanted to work on / show off and look for gaps in the PC market to help our game succeed.
Brainstorming
Our team began this project with a brainstorm. This was set up on Miro asymmetrically over text due to everyone's busy schedule. Before we even had a meeting, the board was full of ideas, our goals, notes on software/tools, what roles each of us were interested in, and what ideas other members liked. The ideation phase was complete very efficiently due to this workflow.
When we did have a meeting, we each presented our ideas and evaluated them as a group, distilling them down into a handful if features we wanted our game to include. We also reviewed our desired roles, goals, and software/tools.
Team Charter
The following meeting, the team set up and discussed our team charter. We pulled some old templates from our time at Sheridan and began filling in sections we thought would be useful to us. Before this meeting occurred, one team member, an avid Dungeons and Dragons player, presented us with an RPG Consent Checklist we thought would be useful for discussing triggers and boundaries. That way everyone is aware and can be mindful of one another.
We made some points on decision making and resolving conflict as well. This was really important to nail down as we would be needing to use the process soon on pitch night. We chose a more inclusive approach (as opposed to voting) to ensure everyone on the team is happy with the decisions we make. Bringing in third parties to help make an unbiased decision if we are in a deadlock.
Pitch Night
Each team member created a pitch based on the conclusions of our brainstorming. Pitches were posted to our Miro board so they could be reviewed before pitch night presentations and notes and questions could be generated. This asymmetrical way of working was beneficial due to the team's busy schedule. After each presentation, the team discussed their notes and questions. Once all presentations were done, we picked out what we liked most about each pitch to give us our game pillars.
One team member volunteered to draft up what they think our game would look like based on the results of our pillars and pitches. This is great because there is no need for us to all make new pitches again. This will help with the decision making and allow us to move forward quicker. In general the way we went about deciding on a game did take longer than just choosing one pitch and moving on from there. However, this method was more inclusive to every group member, and because of the way we did a brainstorm first, our pitches ended up being very similar and could work well together.
Next Steps
At the end of pitch night, we outlined what our next meeting would tackle and when it would be. At this next meeting we will be:
Deciding what we want in our Minimum Viable Product (MVP),
Deciding what documentation, out of the templates we have from our time at Sheridan, will be useful to us,
Picking an art style so the artists can start concepting,
Get started on our Game Design Document (GDD), which will be in a wiki style format, and,
Continue working on the Team Charter.
The team decided that until the next meeting, everyone would add to the Team Charter when they had time, that way we can discuss / modify what was added. This is a more efficient method then waiting until the meeting to fill it in. A lot of information that goes on the Team charter has already been discussed and notes we're made on our Miro board. These just need to be put in the charter and formatted nicely for easy referencing.
DEVLOG 02:
CONSOLIDATING PITCHES
Breaking Down the Core
The following meeting after finding our pillars, the team broke down the core of our game ("You make your own cozy place in a harsh world"). Both to see what ideas could be generated and to see if we were all on the same page or not. The results generated some more details and gave us a better look at how each of us understood what the core of the game meant. This information would help us with the next step.
Elevator Pitches
The next step was to each write an elevator pitch for what we thought the game looked like based on what we pulled from each persons pitch (our pillars). This was to keep things quick and simple rather than making whole new pitches again. When everyone was finished writing we reviewed and discussed what we liked about each, asked each other any questions we had, and marked up the Miro board with notes.
My pitch (see the above screenshot) was kept short but used wordplay. "Explore inside and outside a diverse world..." means exploring the open world in-game and outside the game sifting through its files. "...make friends..." implies not only inviting villagers to your town but building relationships with them. "...and work together to save the game." referring to working with your villagers to save the game from the corruption with a nod to saving being used as a resource or a feature that players don't initially have access to.
The Combined Elevator Pitch
It was finally time to unify our pitches into one clear elevator pitch. We decided to use one member's pitch as a base and modify from there, since it was was really well written, and inject parts of the others. The team discussed each detail of the pitch to ensure we were all on the same page and that everything we want to have in the game was covered by the pitch. See the image to the left for the combined pitch.
During this process, I noticed a gap regarding how the game restoration feature would work. It could be interpreted in several ways: 1) Player is rebuilding the broken game from scratch. 2) Player is using parts of what already exists to restore the broken game. 3) Player is recovering lost parts of the broken game. I stopped us and made sure we answered the question: How does the player restore the broken game?After some discussion, we decided that the player will 2) use parts of what already exists to restore the game. This connects well with a coding feature we want to have. The player will uncover code blocks and use them to reprogram missing features. The phrasing we used to describe this in the pitch was "...discover the remnents to create something new."It was crucial that we consolidate the pitches before continuing to avoid going in circles. We were about to start talking about each feature in more detail, so we wanted to ensure we all had a better idea of what the game looked like, what features we were having and which ones we were not.
Additional Ideas
As we were going about this process, the team added any additional ideas, connections and notes below the combined pitch so we didn't forget them. After the meeting was over, I continued to expand upon some of my originally pitched systems (spells and potions) with reference material and how it connects with some of the other features we decided to keep (from other team member's pitches).
DEVLOG 03:
COMBAT AND PERSPECTIVE
What Makes Good Fast Paced Combat?
----------
Perspective
----------
The team decided that before continuing the discussion on combat, we needed to decide on what perspective the game would be in. Different perspectives give us different constraints, so knowing what those constraints are help us to make more informed decisions and avoid backtracking. The two perspectives the team was deliberating on was 3rd Person and Top Down.
Perspective Pros and Cons
----------
HAUNTED BOARDWALK
About the game
A Halloween themed table top party game! Designed to be less stressful for those with anxiety and have variety when replaying. The objective is to collect the most candy by the end of the game! Inspired by Mario Party and Trick or Treat!
My role
----
The Process
From paper prototype to final print! A walkthrough of the process and different iterations of making the board game!
Downloadable Game PDF
----
Downloadable Rulebook PDF
----
Paper Prototype
----
Paper Prototype
----
Paper Prototype
----
Paper Prototype
----
Paper Prototype
----
Paper Prototype
----
CORPOBOTS
About the game
Build your own custom modular bot, complete with a body, two weapons and movement type. Battle your friends and compete in mini-challenges in an evolving arena. Become a boss and fight to stay on top while the competition teams up against you.
My role
Game Designer, Programmer & Sound Designer. Designed a character with abilties. Programmed audio implementation, and extra controller functions in C#. Coordinated and communicated with audio students and worked in FMOD.
Creating Vroomba
On Corpobots each teammember designed their own bot. This includes the body and weapons. While the end result was a combination of all our efforts, the initial designs came from each person.
Beginners Guide To FMOD
This project was my first time using the program FMOD. I wanted to make sure I knew what I was doing, so I gathered some resources and created a guide to help myself and others!
Using FMOD With Inheritance
I understood and had used inheritance in the past, but this was my first time using it with Unity and C#. This devlog goes through my thought process in developing a pipline with FMOD.
What Makes A Great Game Character
To help aid in the character design of my bot Vroomba, I dove into what it is that makes a game character great.
Programming Features
A gallery of the features I programmed!
The Pipeline
My method of getting audio prepared for hookup. From FMOD to C# code to Unity prefabs.
Sound Library
A page with a collection of all the sounds I assembled for Corpobots and my thoughts behind them.
CREATING VROOMBA
Figure 1: Vroomba, art by Stevie Dong.
Team Values
On Corpobots, each teammember designed their own bot. This includes the body and two weapons. While the end result was a combination of all our efforts, the initial designs came from each person. It was important to the team that everyone had ownership in the project, and this was out way of upholding that value.
Figure 2: Early bot idea sketches.
Brainstorming
We began brainstorming ideas for bots by writing down and/or sketching anything home applicance related. We wanted to get as many ideas as possible on the table. One member of the team may have come up with an idea that another member may want to use and wouldn't have thought of themselves. In the sketches to the right, I drew a series of different bot ideas. While I chose to further the design of the vacuum bot, another member of the team chose to do the blender.
Figure 3: A snapshot of the inital design ideas for the Vroomba bot.
The following meeting, the team set up and discussed our team charter. We pulled some old templates from our time at Sheridan and began filling in sections we thought would be useful to us. Before this meeting occurred, one team member, an avid Dungeons and Dragons player, presented us with an RPG Consent Checklist we thought would be useful for discussing triggers and boundaries. That way everyone is aware and can be mindful of each other.
Furthering The Design
The team decided to use Confluence to create a wiki for Corpobots. While I've had experience making Game Design Documents (GDDs) on previous projects, this was my first time using a wiki. I found this method to be the most organized. It allowed us to keep everything in one place without too much information being displayed at once. To help further our bot designs, our project manager, Joseph Ryder, set up a template for us to use. It included space for reference images, sketches, and ability descriptions. We used language like "Ability Ideas" to keep in the mindset that everything was still open to change and iteration.
Creating Vroomba
On Corpobots each teammember designed their own bot. This includes the body and weapons. While the end result was a combination of all our efforts, the initial designs came from each person.
Vroomba, Dirtestator & Air Blade: Intentions Behind The Design
For the Vroomba bot, the aesthetic was virtual pet. They would emote on a screen with eyes and a mouth. They are very emotive and cute, but that doesn't mean they can't destory the competition in the Corpobots arena. Since the body piece of this bot was a Roomba-style vacuum. It felt natural that the weapons be vacuum related as well. My mind quickly turned to the different nossles that vacuums come with. And so I chose two to start with. I called these the soft nozzle and the long nozzle based on their appearance.
Figure 4: Reference images for the soft nozzle, later known as the Dirtestator.
Figure 5: Reference images for the long nozzle, later known as the Air Blade.
I wanted these two weapons to compliement eachother well. The soft nozzle was to be long range and the long nozzle short range. To prevent the soft nozzle from being too strong, it was to do less damage in exchange for its range. To make up for the loss of range on the long nozzle, it was to do more damage. To really make these two weapons synergize, I gave the soft nozzle a utility ability that would suck in nearby players so they could be in range for the long nozzle.
Figure 6: Sketches and ability ideas for the soft nozzle, later known as the Dirtestator.
Figure 7: Sketches and ability ideas for the long nozzle, later known as the Air Blade.
Figure 8: Vroomba icon, art by Stevie Dong.
The Sounds of Vroomba
My biggest role in this project was managing audio. This included working in FMOD to shape the sounds I collected from libraries and the audio that was provided by audio students we were collaborating with. It was my responsibility to corrdinate with them and provide direction and feedback. Vroomba's voice sound effects came from me collecting clips and editing them in FMOD. I kept to the theme of virtual pet and gave them happy digital booting up sounds. I gathered others including a digitized voice for some negative emotions, like getting hit by other players. When editing any sounds in FMOD, I aimed to keep things short and snappy. This is important because of sound's role in providing player feedback. If a player has hit their opponent, they need to know right away.
Figure 9: Vroomba concept sketches, art by Stevie Dong.
Iteration
At this point in developement, we were using generic character controllers and our main programmer, Joseph Ballantyne, was getting the groundwork in place for our bots and weapons to go into the game. In the meantime we iterated on what the bots would look like. Our 2D and concept artist, Stevie Dong, would send sketches for the team to give feedback on. This included different designs to choose from and selecting the best one to move forward with. When a design a chosen, it went to our 3D artist, Misty C., to create the models.
Figure 10: A snapshot of the balance sheet for the Direstator, created by Joseph Ballantyne.
Figure 11: A snapshot of the balance sheet for the Air Blade, created by Joseph Ballantyne.
More Iteration
As the groundwork was moving along, the team revisted the weapon abilities and went into more detail. These details included what elemental damage was each weapon going to do, how much damage, and revising how the abilities finction if needed. How the revising process worked was we had one teammember responsible for balance (Joseph Ballantyne) make a spreadsheet based on the original designs, then review it with each of the origial designers. For our elemental damage, we had established it early on as Glacial (cold), Plasma (heat), Voltiac (electric), and Physical. For the Vroomba kit, Glacial was chosen. Since Vroomba is vacuum based, the justification is them blowing cool air. Joseph and I worked through the rest of the sheet for Vroomba and came up with the following changes.
The Dirtestator was going to function more like a shotgun, firing multiple bullets and doing more damage the closer you are to your opponent. This was to keep the weapon distinct from other ranged weapons in the game. The suck ability would now do small amounts of damage, but would serve more for utility. If this ability didn't deal any damage, it would be the only ability in the game where this was the case. So we gave it some damage to keep it standard. The Air Blade cleave would now do increasing damage the more targets hit with the blade. This kept to this weapon being the heavy hitter of the pair and also increased the skill ceiling. One of our goals for Corpobots was to have a low skill floor and high skill ceiling. We wanted the game to be easy to get into and hard to master.
Figure 12: Vroomba concept art by Stevie Dong.
The Final Product
The final product for Vroomba was a collective effort amognst every team member. The initial concept came from myself and eventually their emotive sound effects. Joseph Ryder provided structure and organization to make sure developement went smoothly. Stevie Dong furthered the visual design and the whole team provided feedback. Misty C. created the models that would be controlled in-game, and Joseph Ballantyne ironed out the specifics and brought the funcionality to life. Creating a successful game character takes a team.
PROGRAMMING FEATURES
Figure 1: Gear Icon, art by Stevie Dong.
Audio
In conjunction with FMOD, I was responsible for creating audio controllers. Inheritance was used to keep things efficient, legible, and tidy.
Figure 1: Gear Icon, art by Stevie Dong.
Controller Lights
If you bring a PlayStation 4 controller to battle with, you may notice the light will match your player colour!
Figure 1: Gear Icon, art by Stevie Dong.
Victory Aminations
[Coming soon!]
In conjunction with Unity's animation timeline, code was required to add empty pivots. This was done to find the points on the winning player that needed to be highlighted by the camera. Since each bot combo is going to be slightly different, this kept everything consistent!
I also created a tool for testing these animations out. Allowing for the bot selection of player one and randomizing the rest!
Figure 1: Gear Icon, art by Stevie Dong.
Catalogue
[Coming soon!]
SOL'US
About the game
A serious game that serves as a warning about where climate change could leave us. The player is tasked with gathering resources to restore funtions of a damaged bunker so humanity can live on. Manage food, water and oxygen to go as far as you can before someone new has to take over.
My role
Game Designer, Programmer & Sound Designer. Involved in the team effort of taking the inital concept and iterating upon it until it became final product. Recorded sound and folley, edited it and implented it in the game. My biggest task was audio programming and designing the controllers to make it functional.
Week By Week
Weekly devlogs were written during the developement of Sol'Us. Check out my development journey!
More Coming Soon!
A LION'S LIFE
About the game
Play as a lioness exiled from the kingdom and forced to roam the world untouched by humans. Or at least it was. Now the kingdom itself has fallen and the player must survive against the elements while hunting for food, tracking down water, destroying the hunters camps and uniting the fallen kingdom.
My role
Game Designer, Programmer & Level Designer. Everything programming wise was done by myself on this project. I experiemented with AI and our Lioness's abilities. Sketched concepts of the open world map and plotted where important resources, enemies, and landmarks would be.
AI Sound & Stealth System
A series of devlogs on how I concepted and coded AI prey for the Lioness protagonist to hunt.
Map Concept Sketches
A series of sketches detailing the level design for an open world map.
More Coming Soon!
MAP CONCEPT SKETCHES
Below are sketched maps based on previous concept art by Tyler Geraldes, group discussions, and our original playtesting map.
Original Playtesting Map
This was our original playtest map idea that was put together in a gorup meeting. It was intended to be a smaller version of the full map and allow us to get something together for playtesting. We wanted to have a couple of our major landmarks and biomes, as well as food and water sources the player could interact with.
Initial Map Sketch
This initial sketch defines the major physical features of the world. There are four different regions: jungle, beach, mountains, and desert. I took inpiration from the concept art Tyler had done and the original playtesting map to come up with a new more detailed version.
Food Sources
I added a layer that includes where herds of prey are located. Distance between food sources were kept in mind. As this is a survival game, the player needs to be able to find food within a reasonable amount of time but it needs to be scarce enough that hunger can be an issue.
Water Sources
This map shows where there are water sources. The same principals that were applied to the food sources were applied here. The large stream running from the top right to the bottom center is also designed to be a barrier for the player. They will not be able to cross it until they have visited a certain area we want them to go to first.
Enemy Camps
Enemies in this game take the form of poachers, hunting the Lioness protagonist. The poacher camps are located mostly in craters, however each region has an area where they can be encountered. There is an intentional poacher camp near the player start (the cliff at the bottom right of the map). This is indented to introduce the poachers as the player has to pass by them. They will be unable to fight them at this time and will have to make a run for it.
Player Pathways
This map includes all the different main paths the player could walk down. It outlines the flow of the map or where the player will most likely be guided based on landmarks and obstacles.
Regions and Landmarks
Here I gave the regions and landmarks codenames to give each importance and help communicate what each form was representing.
All Together Now
The map with all details listed above.
Inital Oasis Map
A map of the Oasis (floating islands). They reflect the craters in the ground on the main map. This series of islands are intended to be there own compact experience. The hight difference is intended to be a barrier for the player and they won't be able to access it until they visit certain locations.
Oasis Food Sources
The Oasis map with food sources marked. Here they are plentiful to show that this place is as the name describes. Traversing the terrain is the focus of this location, rather than than difficulties of finding food.
Oasis Water Sources
The Oasis map with water sources highlighted. Water is plentiful as traversing the terrain of the floating islands is meant to be the focus.
Oasis Landmarks
The Watering Hole is meant to be the goal to reach in this series of floating islands.
All Together Now
The Oasis map with food, water and landmarks labeled.
ORIGINAL PLAYTESTING MAP
This was our original playtest map idea that was put together in a gorup meeting. It was intended to be a smaller version of the full map and allow us to get something together for playtesting. We wanted to have a couple of our major landmarks and biomes, as well as food and water sources the player could interact with.
INTIAL MAP SKETCH
This initial sketch defines the major physical features of the world. There are four different regions: jungle, beach, mountains, and desert. I took inpiration from the concept art Tyler had done and the original playtesting map to come up with a new more detailed version.
FOOD SOURCES
I added a layer that includes where herds of prey are located. Distance between food sources were kept in mind. As this is a survival game, the player needs to be able to find food within a reasonable amount of time but it needs to be scarce enough that hunger can be an issue.
WATER SOURCES
This map shows where there are water sources. The same principals that were applied to the food sources were applied here. The large stream running from the top right to the bottom center is also designed to be a barrier for the player. They will not be able to cross it until they have visited a certain area we want them to go to first.
ENEMY CAMPS
Enemies in this game take the form of poachers, hunting the Lioness protagonist. The poacher camps are located mostly in craters, however each region has an area where they can be encountered. There is an intentional poacher camp near the player start (the cliff at the bottom right of the map). This is indented to introduce the poachers as the player has to pass by them. They will be unable to fight them at this time and will have to make a run for it.
PLAYER PATHWAYS
This map includes all the different main paths the player could walk down. It outlines the flow of the map or where the player will most likely be guided based on landmarks and obstacles.
REGIONS AND LANDMARKS
Here I gave the regions and landmarks codenames to give each importance and help communicate what each form was representing.
ALL TOGETHER NOW
The map with all details highlighted.
INITAL OASIS MAP
A map of the Oasis (floating islands). They reflect the craters in the ground on the main map. This series of islands are intended to be there own compact experience. The hight difference is intended to be a barrier for the player and they won't be able to access it until they visit certain locations.
OASIS FOOD SOURCES
The Oasis map with food sources marked. Here they are plentiful to show that this place is as the name describes. Traversing the terrain is the focus of this location, rather than than difficulties of finding food.
OASIS FOOD SOURCES
The Oasis map with water sources highlighted. Water is plentiful as traversing the terrain of the floating islands is meant to be the focus.
OASIS LANDMARKS
The Watering Hole is meant to be the goal to reach in this series of floating islands.
ALL TOGETHER NOW
The Oasis map with food, water and landmarks labeled.
WIZZARD ESCAPE
About the game
A point and click escape room. Made in a week long game jam. One mechanic became our centerpeice and the team designed puzzles around it. Magic has been outlawed and you, a wizzard, have been caught using it! Click on sparkling objects to transform them into something else. Utilize your transmutation abilities to solve various puzzles and escape the dungeon!
My role
Game Designer, Programmer & Co-Project Manager. Programmed picking up items and creating an inventory system. Helping less expereinced team members (particularly with programming), puzzle deisgn and co-managing the project. This included setting up meeting times and making sure the Trello was up to date and being used.
Potion Puzzle
Each member of the team designed one puzzle for the escape room. My puzzle included gathering a series of materials to create a potion.
Process Work
A walkthrough of how the game went from brainstroming to the final product.
More Coming Soon!
POTION PUZZLE
The team came up with our central mechanic: transmutation. Objects in the scene can change into different things that assist the player in their escape. Each team member was to then design a puzzle that we would then collectivley put toghether to create the escape room. It was very interesting to see all the different ways we could use one mechanic.
Figure 1: A sketch of my ideas for what my puzzle could be.
My idea was to have a series of items that the player would gather to create a potion that would mind control a guard preventing escape. I thought it would fit well into the end of the room, where the player could gather these ingredients by completing the other puzzles. In addition, there would be instructions on a painting that would be seen hanging in the same room as where the potion would be essembled (a cauldron).
Figure 2: The room in the final product. The cauldron is the room and the player has collected all the objects to make the potion. Instead of a painting on the wall, the player can find a recepie book.
The team decided they liked the idea of using this to unify the puzzles together. The biggest change from the original design was changing the instructions from being a painting to a recepie book the player can find by transmutating a candlestick next to the cauldron.
I feel as though this puzzle was very successful in giving the player a major goal to reach. In the escape rooms I've experienced, I have often come across puzzles like these. What I believe makes these kinds of puzzles successful is their clarity. If it is unclear that the player needs something more to complete it, they could spend a long time on it and get frustrated and confused. Here, there is a need for exploration established at the beginning of the room, where the player is encouraged to click on different obects to see what they change into. When exploring the room with the cauldron, all the player needs to do is come across the book to get the hint. There are two other ingredients located in the same room, so if they continue to search, they will locate them.
BELONGING
About the game
A point and click visual novel. Made in a week long game jam with a group of eight. Visit different families in this fantasy town to solve the mystery of where everyone's prized belongings have gone to.
My role
Game Designer & Programmer. Designed and programmed journal system to keep track of clues. Worked alongside a more advanced student to learn new programming tips and tricks.
Retrospective Design Patterns
I went back to the project a year later to reflect upon the main feature I was responsible for designing.
More Coming Soon!
MARIO KART 8 LEVEL DESIGN
About the game
Created with Ishaan Patel's Unity3D Mario Kart as the base project. This is a race track level for designed Mario Kart 8 Delux.
My role
Level Designer. Inspiration was taken from the Kokiri Forest from The Legend of Zelda: Ocarina of Time and designed with Mario Kart 8's Hyrule Circuit in mind as well as constraints like having at least one gimmick feature per race track. Programmed controller support into the base project to better test the level (as Mario Kart 8 was designed to be played with a controller). Otherwise, the focus was solely on designing the course itself.
The Course
A series of screenshots showing the completed course. Different features are detailed like where shortcuts are and when they are meant to be used, as well as where different gimmicks can be found.
Level Design Document
The final iteration of LDD. Created to help me design and plan, as well as a place where I could keep track of references and what assets I was using.
Planning Beatmap
I created a beatmap to help me plan for building the level. Here I plotted where I wanted certain features to be, how difficult each part was and whether I was teaching, testing or challenging the player.
Case Study
In order to determine what made a successful Mario Kart 8 level, I dove into a particular course that intregued me.
THE COURSE
Figure 1: Birds eye view of the course.
Figure 2: The starting line of the course. To the left there is a shortcut that is meant to be taken on the second and third laps.
Figure 3: The player has three different options to clear this part of the course. In laps two and three, they can take the ramp to the left for a shortcut (fastest). They can otherwise go straight and use the orange boost pads, or drive under the water (slowest).
Figure 4: Inside the Deku Tree. There is a long turn spiraling up the trunk. It is divided by ramps to add more opportunity for player input. At the end of the spiral there is a glider ramp where you decend into a cave.
Figure 5: The cave features turns that are sharp enough for drifting but can still be made using automatic turning.
Figure 6: The ramp acts as a transition out of the cave. Players can land in the water and reemerge up onto the land.
Figure 7: The entrance to the Lost Woods section. It features sharp turns that resemble the Lost Woods from Ocarina of Time, but are spaced out enough that the player has enough time to start their drift.
Figure 8: The bridge at the end of the course is meant to resemble the exit bridge (from the Kokiri Forest) in Ocarina of Time.
THAT FLOATY FEELING
Programmer
----
More Coming Soon!
LENA THE LEOPARD
Game Designer & Programmer
----
More Coming Soon!
BARREL EXPLOSION
Programmer & VFX Artist
----
More Coming Soon!
UNITY FPS LEVEL REDEESIGN
Level Designer
----
More Coming Soon!
