GADGETEER

A physics-based VR puzzle game in which the player builds chain reaction contraptions, also known as “Rube Goldberg Machines”, to solve 61 puzzles.

 

MY ROLE

Level Design, Blockout, Playtest Coordination

PLATFORM

Playstation VR, Oculus Rift, Oculus Quest, SteamVR

TOOLS

Unity, Photoshop, Figma, Google Sheets, Pencil + paper

 
 

Playstation launch trailer.

Gameplay trailer.

 

THE GOALS

As level designer, I was given a number of goals that the team wanted the levels to accomplish. I kept these goals in mind during the entire design process.

Create a challenge without causing frustration.

This was my first time designing a puzzle game, and I found early on that there was a fine line between challenging and frustrating. I was able to get an understanding of how the levels should work through rigorous playtesting and level design studies of similar experiences.

Connect sequentially throughout the environment.

The goal of each level is simple — build your machine to travel from point A to point B, occasionally with added mini-goals on the way there. Physical chain reactions, like dominoes falling, naturally follow a linear path so we wanted each level to connect to the next. The end of level 1 became the start of level 2, and so on. This holistic design choice gave players a moment of triumph as they look back at all the levels they’ve completed that have formed one massive chain reaction machine.

Empower the player to build whatever they can imagine.

We saw a huge amount of potential in Gadgeteer’s creative mode since there were endless possibilities in what could be built, so we wanted the levels to develop the player’s confidence and competence in building machines to ensure a smooth transition into sandbox mode.

 

BREAKING DOWN THE MECHANICS

 

The mechanics of Gadgeteer are primarily just simple physics, so I began by researching hours of footage of existing Rube Goldberg machines. I identified three core gadget types that allow the player’s machines to traverse almost any environmental challenge: dominoes, marble runs, and spinners.

 
tDaB6Cfspw.gif

DOMINOES

The player’s bread and butter! All they need is a flat surface, and dominoes can allow a machine to quickly transfer a reaction from one place to another. Taller dominoes are more powerful as they help players combat gravity by allowing them to ascend to greater heights.

nzTW8SLREU.gif

MARBLE RUNS

Requiring a little more work to build, marble runs allow players to transfer a reaction across uneven surfaces or gaps in the environment. Marble runs are only held back by gravity in that they can only travel downhill.

fHdOwSHOCU.gif

SPINNERS

Spinners are interesting in that they can transfer a reaction in a direct opposite direction, allowing the player to build machines in tighter spaces, or upwards if spinners are chained together vertically.

 

SKETCH UNTIL THINGS MAKE SENSE

Iteration is key in the level design process, I find pencil + paper sketching is the quickest way to explore various ideas and communicate them to the team. After getting feedback, I’m able to condense the copious amount of sketches into the ones that we’re most excited about. I can then expand on those ideas more thoroughly through higher fidelity digital sketches which is extremely helpful in getting the team on the same page before any implementation occurs.

A collection of early pencil + paper sketches exploring various ideas.

An early digital sketch of the first level in the game.

An early sketch exploring the level flow in the kitchen area.

The purpose of sketching is to explore a large quantity of ideas without getting attached, so most early sketches get scrapped. I got lucky with a few sketches making it through to the final game, sometimes being relatively unchanged! Here’s a level focusing on teach how spinners can be used with marble runs to scale vertical heights.

Sketch

Blockout

Live Game

Gadgeteer_StandardEdition_GameHub_Screenshot_R_[10].jpg

FINDING THE FUN

 

After building my own understanding of the game’s mechanics and what tools the player should have at their disposal, I was able to explore how best to create meaningful challenges.

BUILDING A SOLUTION, NOT FINDING THE SOLUTION

Early in my research, I was lucky to come across a video from Mark Brown’s Youtube channel, Game Maker’s Toolkit called, Puzzle Solving... or Problem Solving? In the video, he identifies the difference between problem-solving games, in which there are many possible solutions to a level (Infinifactory, Mini Metro, or World of Goo), and puzzle-solving games, in which there is only one intended solution (Portal, The Witness, Talos Principle). I found that problem-solving was a much stronger approach to the level design with our open-ended mechanics. This meant that for most of our levels, there were many different kinds of solutions that could be built, empowering players to be more creative with their building process.

Here are 4 possible solutions to complete level 43.

Here are 2 different solutions that can be built to complete level 3.

 

SIMPLE GOALS, COMPLEX MACHINES

Rube Goldberg machines are known for being needlessly complex in that a contraption of ridiculous scale is used to accomplish a very simple task (Turning on a light, passing the salt, or pouring lemonade). In our game, it was possible to build machines of similar ridiculous scales, but we knew most players would not have the knowledge or skills to undertake such a task. I found that the levels were a perfect tool for teaching the player how to build these machines by gradually introducing core gadgets in a holistic set of puzzles. By the time they finished all 61 levels, players have a much better understanding of the purpose of each gadget, giving them more confidence to accomplish goals they set for themselves.

A blockout of a simple early level, focusing on only dominoes.

A blockout of a simple early level, focusing on only dominoes.

A blockout of a mid game level, requiring the use of multiple gadget types.

A blockout of a mid game level, requiring the use of multiple gadget types.

A blockout of a late game level, requiring the creation of a more complex machine using the core gadget types.

 

Here is a showcase of incredibly complex player-made machines that were made in our sandbox mode.

BLOCKOUT, PLAYTEST, ITERATE

 

After establishing a clear direction for the level design, we began the iterative process of actually building out the levels in the Unity editor. This was my first time doing blockout work so it was here that I truly learned the importance of playtesting.

MAPPING OUT THE FLOW

The game’s environment (a studio apartment) was built before I joined the team. It was out of scope to make any major adjustments to the layout so I had the constraint of building the levels on top of the existing space. I did my sketching and research with this in mind, so I was able to map out the linear flow of the levels through the apartment. This made it easier to visualize what kinds of challenges could exist in the different rooms based on how far along the levels have progressed. After creating a plan for the level flow, I was able to create a rough timeline for when core gameplay features should be introduced and how the difficulty is affected. I also worked with our 3D artist to incorporate key environmental details and narrative beats into the timeline.

An early map showing the level flow through the various areas in the apartment.

A rough timeline outlining goals for gameplay difficulty + narrative progression.

 

IT’S BLOCKOUT TIME

I began the blockout process by using simple primitives to quickly build out the shapes and spaces required to create interesting challenges. I learned not to overthink the placement of shapes or their visual fidelity as it is more important to build something testable. Keeping things quick and dirty makes the iteration process much quicker and easier. This space acted as the foundation for our 3D artist to build out the final environment for the game.

Flythrough of the level blockout.

Flythrough of the full release level layout.

 

PLAYTEST, PLAYTEST, PLAYTEST

Playtesting was truly a magical process in that after each one, I was able to see clear, actionable improvements that could be made to the game. It was bittersweet though, as many of the changes were out of scope with our limited team size and roadmap timeline. We still tried to squeeze in as many playtests, both internal and external, as we could up until the end of development. I was in charge of playtest coordination which involved deciding when we should conduct a playtest, creating playtesting planning documents, as well as conducting the playtests themselves. It was the playtesting data that resulted in the greatest improvements to the level quality and player experience.

An early playtest conducted at a local university, UBC.

An early playtest conducted at a local university, UBC.

A private playtest conducted from home during COVID-19.

A private playtest conducted from home during COVID-19.

Helping a tester learn some of the controls at an indie developer meetup.

Helping a tester learn some of the controls at an indie developer meetup.

I was asked to give a brief talk on playtesting methods in VR.

I was asked to give a brief talk on playtesting methods in VR.

REFLECTION

This was the first game I had worked on professionally and I couldn’t have asked for a more supportive team. It was a tremendous learning experience to see a strong idea for a game realized from start to finish. I’m very proud of what Gadgeteer has become and it has been an immense pleasure seeing the game being enjoyed by all kinds of people. It has been picked up in schools to help teach physics and been played by children alongside their parents. Of course, there are some things I would have done differently.

Playtest early. Playtesting resulted in the greatest improvements in player experience. I would have liked to start integrating playtesting into my design process from the moment something is testable.

Start wide and shallow. We settled on a direction for the levels without exploring many crazy alternatives. Early on in a project is the best time to try the crazier ideas on a surface level to see if it leads to any insights that could significantly improve the experience.

Narrative and gameplay should support one another. Our narrative was established early without too much thought on how the story might be told during the game. It ended up being quite difficult to convey our narrative beats elegantly. We should have spent more time trying to come up with a narrative that might be better suited for our type of game.

COMMUNITY RESPONSES

 
Domino-animation.gif
 

THANKS FOR LOOKING!

Next
Next

UNANNOUNCED PROJECT