Our Passing Thoughts

Role: Developer

Team Size: 4

Players: 2

Engine: Unity

Tools

Overview

Our Passing Thoughts is a cooperative-first adventure game revolving around two players ability to communicate, coordinate and trust each other and learn how to work togther to overcome seemingly impossible challenges.

It’s a game where you have to pass abilities back and forth between one another like a game of catch. These abilities allow you to interact with the world, taking the form of essential actions like jumping, climbing and attacking.

This is a pure cooperative game that tests connection between you and your partner. It allows you to express the different ways and action we use to support one another. You are not the Hero of this game. You are something more. You are your partner’s hero.

Project Design Goals

Pure Cooperative Gameplay: Everything ties back to working together. Challenges are difficult because of how they require you to work together, not because of artificial induced difficulty that can be solved by something such as Screen Peeking or Controller Swapping.
Implicit Cooperation: Both players have access to the same things. It’s up to them to explore how they need to cooperate. The game is a medium for them to express that. There is no explicit roles, responsibilities shift as you play in the moment.
It’s A Relationship: Everything is rooted in how players express coordination, communication and trust with one another to overcome challenges.
You Are Their Guardian Angel: You are not the hero. You are your partner’s hero. You’re support is what makes it possible for them to survive.
Cooperative Chaos: Players should not be silent for more then 20 seconds, they game should support teams constantly be engaging with one another in different ways.
There is No Player 2: Both players are important, being player 1 does not matter. You can both make decisions. The team’s success is your success. What matters is the dynamic between players and how they work together.
We Support Each Other: Core mechanics exist as a way to express different ways of cooperation and say this is how I can help you.
Together As One: Mastery looks like the players are playing without any limitations.
It Happens In Game: Diegetic and organic delivery of information keeping text as a supporting feature.
Teamwork: The individual has downtime, but not the team.
Permanent Upgrades: Takeaway things temporarily. Don’t give and then take it away.
It’s an Adventure: Players are travelling through one big living world.
That Makes Sense: Things make sense when you interact with them. Systems are simple to the player, but dynamic and flexible. They need to allow players to explore their interactions wtih each other in a consistent way offering obvious and creative uses.
Abilities Are Special: Each mechanic exists for a reason and does not overshadow another mechanic. The mechanic should be meaningful, and feel valuable to use and hold.
We Did It: Success is earned, you don’t pass a challenge because of a fluke. Failing is not a bad thing. You have the tools and abilities to succeed.

Responsibilities

DIRECTION: Work with the team to create a central vision and develop rules to maintain clarity on game direction to ensure consistency of quality and content.
GAME DESIGN: Create and build systems, mechanics and features to support an implicit cooperative driven driven by flexible, evolving and dynamic interactions and experiences.
GAME DESIGN: Develop frameworks, systems and features involving Traversal, Combat, Camera, Characters, Enemies, and Controls
GAME DESIGN: Create documentation, shareable mockups, wireframes and more to ensure team members had a shared understanding of various features and systems to make informed decisions.
DESIGN: Craft the Progression structure with respect to elements such as; player experience, difficulty, unlockables, rewards, evolving mechanics, interconnected systems, play patterns and player behaviours.
DESIGN: Draft, concept, test, iterate, build and finalize all gameplay related features, working from high level concept to tuning low level details to finalize shippable results.
LEVEL DESIGN: Create interconnected levels that lived in the world that players explored as part of the narrative journey. Levels featured challenges for players to overcome, and focused on certain mechanics, interactions and narrative theming.
LEVEL DESIGN: Concept, build, and finalize challenges that focus on certain features and behaviours to be explored in a level. Adjust them primarily based on factors such as difficulty curve, pacing, plot, general pain points, and relevance.
USER EXPERIENCE: Tailoring low level details involving balance, game flow, rhythm, cameras, feedback, gamefeel, timing and more to create responsive and desirable interactions that delivers a valuable experience that players want to engage with.
PLAYTESTING: Develop playtesting metrics to evaluate and identify outcomes from tests.
PLAYTESTING: Review over 50 hours of playtesting datapoints examing player and partner behaviours and drove the development of systems based on emergent player behaviours and changes based on undesirable pain points and reinfocing positive areas.
PLAYTESTING: Build multiple public ready levels which were used to show the game at various conventions such as PAX or PHL which were designed to validate various features, and gather actionable playtest data for improvements.
QUALITY ASSURANCE: Identifying, investigating and implementing solutions for player pain points as well as creating bug reports, and priority lists for our engineer.
ANIMATION: Creating high quality, high resolution 2D game ready animations for our two main characters, while adhering to gameplay requirements.
AUDIO DESIGN: Locating, sourcing, editing or creating sounds to add life to the world, provide feedback on an interaction or generally improve the player experinence.
LEADERSHIP: Communicating between various disciplines to ensure relevant information was being shared and consistency was maintained from concept to final implementation.
PRODUCER: Assisted in handling agreements between publishers, studio owner and team members. Created marketing and publisher materials and assited in negotiating contracts.

Additional Details

Genre: Cooperative Adventure
Duration: May 2021 – May 2025 (4 Years)
Cancelled: May 2025
Language: C# / C++
Platform: PC
Controls: Keyboard / Gamepad

Detailed Design Work: Thoughts and Breakdown

Where Did The Game Come From? (Gameplay Videos)

Proof of Concept Build – Developer Playthrough
(Player Playtests indicate roughly 3 hours)

Level Design Concept Sketches for Proof of Concept Demo

Our passing thoughts began as an idea during an online gamejam hosted by Google to build a cooperative game for their Goodle Stadia platform. There I acted as the Game Director and we managed to take 2nd place in the compeition. Afterwards the team decided to continue working on the game to create a fully feature complete product. And so we took some time to make a proof of concept demo which is featured above.

Gameplay Videos

Our Passing Thoughts is a cooperative-first adventure game revolving around two players ability to communicate, coordinate and trust each other and learn how to work togther to overcome seemingly impossible challenges.

It’s a game that explores the relationship between two players, as they learn how to work together. We want to take full advantage of the evolving dynamic between two players leveraging both in game and out of game skills, as they share in this pure and gruelling cooperative experience that encompasses the many ways we express supporting one another.

In OPT (Our Passing Thoughts), players are limited in their ability to interact with the world. They use fragments which are crystal-like objects of power that enables them to interact with the world. By possessing fragments, they gain access to essential abilities such as jumping and attacking. However, these fragments are limited and players must share access to these abilities by passing them back and forth between one like they are passing a ball in a game of catch.

Abilities are granted on a tier-based system. A player with one fragment can jump. A player with two fragments can attack. As they play through the game, they start with one fragment and have to share the ability to jump. This can make relatively simple challenges tricky as both players try to figure out to share. As they make progress, they gain more fragments, which leads to more abilities, more interactions, more compleixty and more of that signature cooperative chaotic joy.

OPT is a game where we wanted to ensure that both players felt important, and were capable of making meaningful contributions through a team’s ability to express their way of cooperation in the way they play.

The game is designed around intrisinic play patterns and behaviour dynamics to support a teams ability to discover and develop their own way of play. Both characters have access to the same tools, as we leverage dynamic roles that shift depending on the situations players encounter.

This is a game designed around supporting one another and being there for each other. The spotlight is on them, but you are the reason they and your team succeed. OPT is a game where both players will always feel responsible for the success they achieved no matter the challenges that they face.

2.0 The Core Mechanic

Our core mechanic that every feature is built on is called “Sharing” and typically involves a three step process involving communication, trading, and action between both players. This mechanic is rooted in players passing abilities between one another, sharing their ability to interact in various ways.

Players pass fragments or “orbs” that act as batteries. The system works on a tier based system, the more orbs you have, the more ways you can interact with the world. With one orb you can jump. You can pass that orb to your partner, giving away your access to jumping so that they can jump instead. As you get more orbs you can do more things. For example, if both of you have one orb, you both can jump. If one person has two orbs, then they gain access to the attack ability.

The abilities or interactions players have related to the orbs are split into three types;

Active
Passive
Passing

Active abilities are physical abilties a player has to activate. Jumping, attacking, pushing, climbing are all active abilities.

Passive abilites are abilites that always happen as long as a character has the minimum number of orbs to “activate” the passive feature. For example, a player with an orb always emitted light around them.

Passing abilties are abilities that trigger when the ball is passed through an on object such as a switch that can open doors, or turn things on and off.

The design of this mechanic forces both players to always be involved as it is used. Players drive the way the mechanic is used and work with the dynamics the game creates to engage with one another as they play. This is built into the foundation of the game which ensures that players are cooperating in some capacity no matter what situations might happen.

The great thing about this mechanic is that it is flexible and has both simplistic and complex ways it can be used. This means that we can start players off as if they are playing a simple game of catch, and overtime they’ll discover that they’ve ended up playing baseball without even knowing how it happened.

A prime example of this mechanic in action is in what we call the Hot Potato challenge. This challenge requires players to quickly pass the jump ability between one another while performing a series of jumps.

It’s a simple and straightforward challenge that showcases how the game works at fundamental state, and showcases how this mechanic can make something so simple feel difficult.

Players have to pass the ball at the right time to complete this challenge. Experienced players make it seem like this limitation does not exist. But if you delay, or mistime it then you see the hiccups.

For newcomers this challenge can feel difficult, but it has also produced high satisfaction responses from players as they complete it.

3.0 Player abilities

I approached designing abilities as something that needed to feel valuable. These are the rewards you get, they are essential and players need to desire them. This gives meaning to the dynamic of having to give up access to these abilities, and what it means to get it back.

Each ability and game mechanic has a purpose so that it does not overshadow any other mechanic that exists. They have a simple premise which makes them easy to grasp. However, each one has a variety of ways they can be used offering a large amount of depth as you explore their functionality.

The Pushing mechanic for example isn’t just used to push objects. It can stop them from sliding down a hill. You can push blocks to stop doors from opening and closing. You can push a block to break through an obstacle, deal with an enemy or block wind from pushing you.

Each mechanic is designed to work together with the other mechanics from the ground up so that it creates both simple and complex interactions that emerge over the course of the game. They need to invite curiousity as you and your partner explore new ways to interact with them. And most importantly, solving challenges with them needed to invoke positive emotions.

I’d always ask a series of question to make sure that a mechanic fit with the current direction;

What is this trying to do?
As a player, why would I like this and what use would it be for me?
How do players use this to help each other?
Is this allowing me to express or feel something that is missing?
Does this overshadow an ability or is it being overshadowed by something else?
How does this play into coordinating, communicating and trusting one another.
Is this easy to understand? Does it make sense? Will players accept its use cases.
What can you do with this that would make players excited? or catch them offguard.
How does this work with other things and enable you to do even more cooler things?
What does a hot potato (rapidly passing) challenge of this mechanic look like?
How many buttons do I have to press?
What do example scenarios looks like and is it more then just a 1D experience.
Is it easy to understand, but still have provide a variety of use cases in different situations
Does this mechanic say only one person can do this. Is it available to both players?

Each mechanic is stress tested in both theory and practical use to push the systems as far as a possible and create the best version that can exist. This typically involves designing a few challenges that showcase the mechanic as a focus and as part of an ensemble at various scales.

Once the mechanic is approved, I would go ahead and design wireframes and design slides for the team that went into detail on how the mechanic functioned at various levels. This ensured that everyone had access to any important information that they would need and served as an important part of the development pipeline to ensure consistency.

From there we had a number of test areas in engine to ensure that a mechanic worked as intended, before moving onto intergrating it into our levels where additional updates would happen as part of the iterative process.

4.0 Level Design

The game features levels designed to feel like you are travelling through one big interconnected world. Below is a mockup of the the world map of act 1 using the level designs to show the journey players take.

It features challenges that start off being contrained to linear spaces with limited mechanics and clear objectives. This later evolves until the last few levels where the spaces are open ended and require players to explore and experiment to find ways to overcome obstacles.

There were a few significant challenges that had to be considered when I approach designing a level.

Where does this level take place and what interactions are available to them at this time?
What are the abilities players have, and how are they limited?
How does this space exist and connect with the rest of the area in a way that feels organic.
What do players need to know before they take on this challenge?

For the early levels, OPT pushed me to design areas to accomodate for the lack of interactions and abilities that players would have later on. This was even more challenging because this is early on in the game where players aren’t expected to have much experience if any at this time.

However, what it did allow is for me to showcase why the mechanic was special because this lack of complexity creates a simplified experience where we can focus on how compelling the mechanic is without distractions. It’s not difficult to make something compelling when you have all the tools at your disposal, however our game is platformerer where you do not get the ability to jump until level 2.

It was an interesting challenge to tackle that took many iterations but ultimately lead to creating a much more interesting design system that helped bring more depth to the way challenges were designed and overcome.

Every level started with a concept, where I would sketch out a rough idea of what the level would entail. This process involved asking a few questions;

What abilities do players have at this point?
What interactions are players familiar with?
What is the new core ability and new interactables they will unlock during this level?
What are the next features that I want to build interest towards?
What are some new ways we can give players to use the things they already have?
What can’t we do once players have completed this area?

These questions help form the template of what requirements a level needs, and what direction it will take as it is being developed. For example a level where players get access to the climbing ability will feature lots of vertical space and interactions that showcase that feature. Or, I may need to foreshadow a certain interaction, or reinforce certain skills so that players are prepared for certain challenges that are going to encounter. A level can only take up so much space in a game, so we have to prioritze features to ensure that we are hitting our goals.

Every level contains a variety of different experiences, both familiar and new with different avenues in the way they are presented. While new features are exciting, many of our abilites have multiple interactions that are not explorable in a single level for various reasons ranging from complexity, difficulty, space and opportunity. And so I make it a point to give players brand new features, and new ways to use familiar features which helps keep the game fresh and exciting while not overloading the player and maintaining the identity of each level.

My inital process is more like a sketch, with loose areas to start. I’ll block out different segments, concept challenges, look at traversal sequences or player behaviours that I want to see. I like to use the environment as a means to inspire the way the areas work, especially in the transitional spaces to give it life and substance.

I’ll start with the critical path, imagining how players will move through an area. What is the flow of movement, what actions are being taken as they move through the space. What is the rhythm of the buttons? How are they talking to each other? What is the order that they need to know things in?

This rough concept goes through a number of iterations as I check for potential problem points such as information overload, difficulty curve, flow, clarity and more. Its’ the first level of validation of what the experience is like, and something to point to say and say this is what is correct and what we need to work to. It acts as a guide for when I build the level in engine.

Over the course of making these levels or mechanics, I have an abundance of challenges or concepts in a backlog that I’m always checking to see if they are appropriate to use. I’d take a look at my list of features that players are going to be using, and start breaking down what they need to know.

Once I’m confident in the concept, I’ll head in and build the entire level, working with our engineer to create or adjust any features that are needed. Here we test the UX. Things such as how long players take to travel through an area, sequencing of challenges, rhythm, fall heights, implicit jump points, camera movements, framing, and more.

Many times things need to be adjusted because we might discover a way to improve the area, or have to fix a problem point. However the strength of this approach allows us to focus on important problems when they are relevant. This allows you to make adjustments without having to invest a large amount of time to do so, and importantly provides something everyone can look at as a reference to make informed decisions.

When I approach designing a challenge, it stems from two factors. First, what purpose does it serve? and Secondly, how does it adhere to the design pillars of communication, coordination and trust. Challenges are designed around supporting one another, and succeeding as a team. Each challenge has at least one tag associated with it, and those are;

General
Traversal
Boss
Priming
Teaching

General challenges are high impact scenarios that require players to problem solve and execute a series of actions with their partner to make their way past an area. They may need multiple attempts as these challenges encompass a variety of mechanics that are used in a way to ensure that players have reached a certain capability. These challenges are designed early, and often inform the direction of the other types of challenges that appear in the same level.

Teaching challenges focus on ensuring players are introduced and understand a specific mechanic or interaction. They are short, simple and direct to ensure that players know what something does before they have to use those features in a complex or long sequence. These are crucial for reducing the learning curve of many general challenges and the time it takes complete them.

Traversal challenges occur as players move point a to point b, or between notable challenges. They are often used as teaching or reinforcement challenges to build muscle memory and skills by breaking up mundane tasks and adding micro points of engagement to keep players engaged. They are a great way for players to become experts at the targeted skills in an organic way.

Priming challenges function as a means to prepare players for upcoming difficult challenges by reminding them to be aware of certain mechanics, or act as an escalation of difficulty to bridge between a simple and a “Boss” challenge to create a cresendo of success.

Boss Challenges appear at the end of a level. They are the culmination of everything players have learned up till this point and are designed to be a final exam that players have to pass to move on to the next level. These are emotionally intensive, adrenaline inducing gruelling experiences, focused on pure cooperative play and are the longest and most difficult challenges in the game. Likewise, they also invoke the most “fun” and engagement from our players due to the demand they place on the teams ability.

All of these challenges are balanced around simple to complex, where the difficult is tuned along two factors. Planning (figuring out what to do) and execution (pulling off the actions) allowing us to a large amount of flexiblity in the way players are challenged.

5.0 Playtesting

OPT’s major challenge regarding playtesting was that it required two people to test. I had designed the game to require two people to play, which meant I had to be very good at controlling both players during my inital tests.

For public playtests, we created custom built levels designed to test, validate and review various features we had been working on. Playtesters included various pairings ranging from friends, siblings, strangers, casual gamers and more to ensure we were hitting the right experience.

All playtests, including when we performed open playtests (conventions, expos) and private playtests (friends, volunteers) featured video, audio and game capture so that I was able to review as much data points as possible. The main points I looked at were;

Player body language
What players talked about
What they tried and how long they tried it for.
How often players engaged with each other
Which players spoke the most, and if shy partners were communicating.
How long it took for challenges to be completed.
The approach players took to exploring and solving challenges.
Speech patterns and language.
Expressions and Displays of Emotion

One key adjustment we made from this feedback was in the way we designed challenges, and is why the “Teaching” category is its own tag. We found early on that players can solve these gruelling boss challenges, but it in this case it took an hour and a half. It was an engaging expereince, but I could see points that could be improved, and we did want more complicated challenges later on. So this was a problem that needed to be addressed.

We introduced teaching challenges that took unnecessary pain points and turned them into their own areas that players can learn without the pressure of an intense challenge happening at the time. Secondly we made priming challenges which got our players into the right headspace of what to expect and prepared them for what was expected.

In our test level, this added 10 – 20 minutes to the level playthrough, but reduced the test challenge time down to 30 – 45minutes to complete, creating a smoother difficulty curve that made for a stronger experience. There are many other changes that were done, but that was the biggest contributor.