Sayo Oladoyin
Game and Level Designer
Sneak & Snack
Sneak & Snack
Capstone project
the design challenge:
Make a co-op, physics game that encourages exploration and collaboration.
Project details:
Project Duration: 8 months
Team Size: 6 people
Platform: PC
My Roles: Level Designer, Game Designer, 2D Artist, Programmer
My responsibilities
-
Planned and greyboxed multiple level iterations for different iterations of the game.
-
After establishing the verbs and mechanics with the team, designed moment to moment encounters using said verbs and mechanics.
-
Designed and illustrated the team's logo.
-
Programmed interactions in the game.
-
Planned and facilitated playtests.
-
Iterated levels and systems based off of feedback from playtest, peers and industry veterans.
-
Participated in planning the game's design, from early concepting till late stage polish.
Project Description
Sneak & Snack is a 2-player co-op game where you escape the school as two class pets, with expressive facial features, eyes that look where you look, and a mouth that moves when you talk. The physics based environment makes mundane human tasks, such as opening a drawer, become "mouse puzzles", granting you new ways to create messy paths out. Challenge yourself by escaping the classroom in as few days as possible! There are many ways to escape and each route will have its own unique obstacles. Stay motivated by picking up cheese crumbs scattered throughout the level!
If you'd like to play the build,
Check out the project's itch page!
Design Process Summary
For this game, we went through a major pivot in design direction midway through the design journey. As a result, my design process as outlined here revolves around the pivot, as our approach to the design had to change once we pivoted due to the newly limited time, and different end goal.
pre-pivot
During the first four months of the project, I:
-
Went through pre-production with the initial design idea
-
Brainstormed ideas and made concepts with the rest of the team
-
Made in-person prototypes to validate our core gameplay loop
-
Made a Proof of Concept to validate our idea, then a Minimum viable game
-
Designed and greyboxed early levels
-
Scripted actors to be used within the level, as required by gameplay
Pivoting the design
During the design pivot, I:
-
Collaborated with my team to decide what aspects of the design to change, and what to keep
-
Was part of the decision making process for our new design direction, after we decided what we wanted to keep and what we wanted to shift away from. Collaborated with my team to nail down the overarching narrative, the moment to moment gameplay, and the verbs we wanted to have in this new design.
-
Collaborated with my team to decide, then adhere to, changes in our design process to enable us to still complete our game in time for our deadline.
post-pivot
During the last four months of the project, I:
-
Along with the team, circled back to the pre-production phase to re-define our design direction based off feedback received from our MVP build
-
Iterated on level design, building the level using a modular greybox kit, and later condensed the level down to a smaller space for a showcase-friendly build
-
Performed regular playtests, and iterated based off feedback
-
Facilitated the production of assets and scripted objects based on level design and gameplay requirements
lessons learned
Over the duration of the project, I learned:
-
To always test as regularly as possible, as early as possible. Fail fast
-
To explore positive feedback, rather than just running with it
-
That guiding the player clearly and properly is very important, regardless of the type of game that's being made.
Click on the boxes to learn more, or
scroll for more details
To start off the design process, we decided to brainstorm as a team, and narrow down on an idea. At the start of the project, we weren't sure what kind of game we wanted to make, so we looked at many different game references together as a team, before having a design session.
During the design session, we all rapidly came up with game concepts individually, then shared them with the team. After sharing the concepts, we voted on our favourites, and expanded on them. By the end of the design session, we cam up with two ideas that both look very different from our final game: Miss Understood and Top.
Our initial concept for Miss Understood, which, after a lot of iteration, became Sneak & Snack.
Our concept for top, which, at the time, we were considering in addition to Miss Understood.
After narrowing down to these two ideas, we eventually chose to move forward with Miss Understood. Through the process of design exploration and development, we eventually decided on moving forward with the concept of rats trapped in a classroom, trying to escape without being able to communicate.
Once deciding on our concept, we moved into the prototype and playtest phase. During this phase, we bought children's toys to test out the concept of communicating without voice, using the objects. We got positive feedback from these playtests, which led us to test the concept out in a digital prototype: our Proof of Concept.
Toys purchased from a second-hand store, so we could design puzzles around them, and playtest those puzzles. Although we ultimately didn't end up moving forward with these puzzles, it was helpful to find out how much can be learned before doing anything in engine.
At this point in development, our proof of concept seemed successful - but we didn't yet know what it was that players liked about our game, and what they didn't. So we fleshed out the game further, putting players in an explorable environment (a classroom) with a puzzle and a goal, which was to escape the classroom. This was our Minimum Viable Game (MVG). We designed, in a document, additional puzzles we would add if this puzzle was validated, and were able to watch several pairs of people play our game during a showcase.
A map of the level layout, including the puzzles we designed.
A snapshot from one of the puzzle design documents we made, when we started exploring and expanding on our puzzles. We wanted to make sure the puzzles were well explained and documented, so we could easily implement them.
Our puzzles at this phase of development were a lot more deduction and communication based - not bad on their own, but we found that these weren't the styles of puzzles players wanted to complete in our environment.
From the showcase, simply by observing so many players play through our game, we were able to identify a lot of problems with our design. The following issues were the biggest problems we found:
Players got extremely lost in the environment. Once they left the cage (the tutorial), they had no clue what to do, so this would either lead them to just play with the objects in the physics environment, or wander around aimlessly before quitting the game
Players who did try to escape rarely ever interacted with the puzzle we had set up. They often tried their own unique ways to leave the classroom (like building a way out with blocks), or they would complete half of the puzzle, and would feel inclined to break it
Players rarely felt motivated to escape the classroom. Even though they were told at the beginning of the game, they often forgot, or ignored the goal.
Looking at these very big design problems, and the amount of time left, we made the decision to pivot the game and follow the fun. We chose, instead of forcing the players to do what we wanted to do, to look at the desire paths that players were making when they played our game, and follow them.
After identifying the current problems with our game, as a team we tried to decipher what players liked about our game, so we could keep it when we pivoted, while shifting away from the aspects of our game players weren't as fond of. We came to the conclusion that players liked:
The physics based character controller, and being able to manipulate the environment and the objects around them in such a direct way
Tossing objects around the level
The art style and colour scheme of the game
The scale of the game (getting to be small creatures in a big world)
Getting to be rats
Once we had figured out what players liked and what we didn't, we were able to plan out the direction we wanted to move in for the next 4 months.
For our new design direction, we chose to:
-
Move away from the open world layout, and provide the players with paths they can take, and clear puzzles to solve to prevent them from feeling lost and confused within the level
-
Give players proper tutorialization, as well as testing and challenging mechanics to ensure that players fully understand mechanics they have to use during gameplay
-
Target gameplay more around the physics based mechanics, as players made it clear that they enjoyed the idea of physics-based puzzles
-
Shrink the gameplay space, to prevent players from feeling lost
-
Add a day/night cycle that keeps track of the number of in-game days players spend trying to escape, to give players more of an incentive to escape faster, and also to encourage replayability
After we figured out what worked and what didn't for our game, we made an affinity diagram to figure out what verbs we wanted to have in the game, and which ones would be part of the core gameplay loop.
We decided from this point forward to work linearly; we focused on implementing and testing the most core features first, and only after we validated those did we move on to other features of the game.
When re-designing the level, I documented some of the different encounters players would run into throughout the level, and how we expected them to play through. This allowed us to see when the level wasn't quite being played as we expected, so we could investigate and find solutions.
These were changes we made to our design and development process to accommodate this pivot, especially since we were going to be working on a much tighter schedule:
-
Greyboxing the level using a modular kit, so that metrics were decided early and set in stone, and so that getting final assets into the level was quicker and easier for the 3D artist
-
Performing more frequent playtests (at least once a week) so we could be sure that players had the experience we were aiming for every step of the way, and if they weren't providing us with the opportunity to rapidly iterate.
-
Building outwards (so starting small, and expanding), by establishing first our core gameplay loop (the smallest, enjoyable gameplay loop), before adding other features
Alpha level greybox, done with the modular set. The alpha level had more content than the MVG level, but was completed in much less time.
After deciding how we wanted to move forward for the next half of development, we chose to nail down the moment-to-moment gameplay. This meant that as a team, we decided what kinds of interactions or verbs we wanted the players to be able to have in the game, then as the gameplay and level designer, I brought those verbs into the gameplay space, testing them and iterating on them until they felt natural, enjoyable and engaging for players.
When we decided to re-validate our moment to moment gameplay, I chose to make small versions of the level, isolating and testing just the core mechanics so we could ensure our core gameplay loop was engaging. The first level I made was simply a linear test of the grabbing and stacking mechanic.
Once we had validated the core mechanics, I introduced a couple more mechanics in a branching environment, to validate those as well. This helped ensure that everything that was being added to the game was adding to the gameplay experience.
When designing these prototype levels, I opted to use a beat diagram rather than a visual map, as the focus here was more on the mechanics, and the pacing of those mechanics, than on how those mechanics mapped out visually. I found that drawing out a map didn't work as well for this style of level.
Sticking to the spirit of the double diamond framework for design thinking, we first diverged after discovering the problem, to figure out possible causes and solutions. That led us to converge on the specific issue of our gameplay loop being unengaging. We then chose to diverge again when we had validated the core gameplay loop, and the idea of having a branching level as opposed to a linear one.
We created a bigger level with multiple paths and puzzles, that allowed us to perform playtests, and through observing playtests and telemetry data, see what puzzles and paths were the most popular with players, and engaged them the most.
Once we had gotten that information, we were able to converge again into a smaller space using the best puzzles.
A diagram illustrating how our design process aligned with the double diamond framework. The dots represent the three main phases in the process, while the four sections show what actions our team did that were associated with each section.
Post-pivot, I also opted to focus a lot on tutorialization, not only for mechanics, but also for teaching players how to think when navigating the level. We had decided as a team not to have a HUD, as the nature of our game seemed to much better suit diegetic UI. This meant I had to be a lot more creative than usual when designing the tutorialization for the game, as having text pop-up on the screen would clash with our game's style.
As a result, I opted to use small chalkboards laid out around the level to guide the player, giving them hints for puzzles, and teaching them how to use important mechanics, like movement, sprint-jumping or tossing.
I also used cheese crumbs placed throughout the level to help guide the player in the right direction, to help prevent players from feeling lost.
An example of a chalkboard being used for tutorialization in the game. We wanted the chalkboards to be noticeable enough to draw players' attention, without affecting their immersion.
An example of cheese crumbs being used to guide the players down the right path. Even though players here have gone down an optional path and found a large piece of cheese behind some books, the crumbs always direct them back on the right path.
Challenge: We struggled to identify what was working and what wasn't working in our game, until midway through development
Lesson Learned: Always test as many elements as possible, as early as possible. Establish and test the core gameplay loop, and only once that is validated, should you move on to adding more features and testing those. Focus on testing it in the fastest, cheapest way possible, then building in complexity gradually.
Challenge: We got positive feedback from our early in-person playtests, but we quickly assumed we knew where the positive reactions were coming from, and ran with them, rather than exploring further in that stage to figure out what exactly players liked and why
Lesson Learned: Positive feedback from playtests doesn't always mean it's a good idea to move in a certain design direction. It rather is an invitation to explore further, especially early in the design journey, as positive responses can be had for many reasons. It's difficult to narrow down those reasons accurately in the beginning without exploring the ideas further with several low fidelity prototypes. Make sure to test the core gameplay loop first, and once that is validated, build off that, testing each system and feature that is added.
Challenge: In early versions of the game, players often got lost and couldn't find the goal of the game. Even if they knew what the goal was, they found it hard to connect their actions with the overarching goal of the game.
Lesson Learned: Whether you're designing a sandbox, open-world, branching paths, or a linear game, player guidance is important. It may be done differently for different genres, but players who aren't guided in some way through their moment-to-moment gameplay tend to feel lost, even when there is an overarching goal. Ensure that level design, lighting and set dressing all lead the player the same way, as conflicting cues from different elements can make players confused.
If you'd like to play the build,
Check out the project's itch page!