FOGO Portfolio
Tristan Durocher - Tech and Level Design
In Fogo, play as a fireball trying to find your way home. Swim and launch through grass, trees, moss and mushrooms, burning it down as you go - but don't run out of fuel!
The Fogo trailer, created by Christopher Bradshaw.
Feel free to play the game on our itch.io page!
My contributions:
• Design documentation (pre-production documents, game design document, gameplay patterns breakdown, character movement troubleshooting)
• Character movement and controls (design and programming)
• Initial design and progression planning
• Level design
• Rational game design breakdown
• Mechanics prototyping
• Sound integration
I am looking for positions in tech and level design. You can view my LinkedIn here.
Movement and Controls
The core design pillar of Fogo is continuous movement. If the player sits still for too long, their fuel source will expire, and they will fail.
Fogo can safely bounce once; the second bounce returns the player to the last checkpoint.
Success in Fogo is about building momentum and achieving a smooth flow of movement. To create these sensations, the controls and movement design required many iterations.
For instance, in early development, we found a need to prevent players from accidentally exiting fuel sources while swimming, as this can break the flow of launching from one fuel source to another. It was not practical to surround our fuel sources with colliders to act as boundaries, so this required a specialized approach.
In alpha, several solutions for bounding players within different types of trigger zones were explored.
To this end, I developed a system that slows the player down as they approach the edge of a fuel source, stopping their movement entirely at the edge itself. What follows is a somewhat technical description of this system, along with an overview of the design decisions that followed.
The "edge check system" begins by casting a ray on a point in the player's trajectory. If a fuel source is not detected at that point, we have determined that the player will soon be exiting their fuel source. So, we cast a ray from that point back towards the player. Based on the magnitude of this ray, we can calculate the player's distance from the edge of their fuel source, and gradually reduce their speed based on that distance.
Raycasts created by the edge check system.
Technical details aside, we learned through playtesting that universally applying this system can be unsatisfying for the player. It slows the player down, which can hamper the gameplay loop of launching from one fuel source to another, and the core premise of continuous movement. So, for a time, we removed the edge check system, thus creating a new mechanic which we termed the "dolphin jump". This allows the player to swim directly outside their fuel source, using their existing momentum to reach the next fuel source.
The dolphin jump allows players to leap a short distance from fuel sources without bothering to aim and launch.
Players responded well to the freedom of movement provided by the dolphin jump.
However, with the restrictions of the edge check system removed, we observed that there were moments in gameplay where the player was especially prone to losing control of their character and accidentally exiting their fuel source; this called for further adjustments.
The most notable example of this issue is when the player enters a narrow fuel source, such as a hanging vine, very rapidly.
A very slippery vine.
In this situation, the player's airborne velocity is sometimes enough to send them straight through the fuel source, often against their will. So, I decided to have the edge check system briefly activate when the player enters a fuel source at a high speed. This helps them decelerate, so they can stay within the fuel source.
The edge check system helps the player stay within this vine.
However, this created a new problem: when entering fuel, players would sometimes want to dolphin jump right back out. When a player would enter fuel rapidly and attempt a dolphin jump, the edge check system would slow them down, staggering their movement and interfering with their intended trajectory.
A player's movement is halted in the first patch of grass due to the edge check system.
So, we decided to take player input into account in deciding what action we would take. Specifically, when the player's joystick input angle is relatively near the angle of Fogo's velocity, it is safe to assume that the player wishes to keep moving and dolphin jump. In contrast, when the input angle is relatively far from the angle of velocity, the player is likely trying to turn around and does not want to dolphin jump. So, the edge check system is only activated if the player inputs away from their velocity, or if there is no input.
In the final version, the player has control over whether they stay within a fuel source, or pass through it.
The movement scripts are my main contribution to Fogo's programming. You can view the source code here.
Initial Design and Progression Planning
Diagram of an early level (left), and gameplay patterns for an unused gameplay ingredient (right)
In early development, I was tasked with determining an appropriate scope of mechanics and ingredients and plotting the introduction of features across the vertical slice.
Level breakdowns and general progression, from the vertical slice blueprint.
The vertical slice blueprint outlined a desirable progression curve and created the skeleton for our level design. The associated spreadsheet can be viewed here.
Level blueprints that proved successful, along with their final iterations. The level blueprints were a collaboration with Jeremy Selwyn.
Level Design
Levels created during beta, to replace certain alpha levels.
I was responsible for creating and editing the cavern levels (first 1/3 of the game) during beta development.
Tutorial stages focused on teaching basic mechanics.
My first goal was to improve the introduction of mechanics and gameplay ingredients. At this stage, we had to account for several new mechanics, such as the "dolphin jump", and bouncing off walls as part of a launch (a mechanic developed during alpha).
After the tutorials, the player is challenged to put the mechanics together in a relatively safe environment.
A mountain level from alpha. Back then, the game was very pink.
In alpha, I worked on some endgame mastery challenges. These incorporate advanced precision challenges, narrow time frames, and frequent checkpoints.
Rational Game Design Breakdown
Gameplay loops and rational game design tables from the game design document, written to deepen our understanding of the types of challenges we can present to our players.
Analysis of gameplay patterns, looking at specific cases from the game, and extrapolating atomic parameters of difficulty.
Bio
I am an aspiring tech and level designer, with a strong understanding of game/level design principles, and capable of creating my own tools. Currently, I am working on small solo projects to deepen my design knowledge and broaden my technical skills. I am also studying procedural generation.
Index
