Sayo Oladoyin
Game Designer, Level Designer and Artist
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.
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 my 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 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 over-arching narrative, the moment to moment gameplay, and the verbs we wanted to have in this new design.
-
Collaborated with my team to decide, and then adhered 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 players 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
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.
Sticking to the spirit of the double diamond framework for design thinking, after initially diverging during brainstorming and converging on this design, we chose to diverge again when putting the design into a gameplay space, first creating a bigger area with multiple paths and puzzles. This allowed us to playtest this area, 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 with the best puzzles.
Post-playtest, I 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 the style of our game.
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 when playing through the level.
Challenge: We struggled to identify what was working and what wasn't working in our game, till 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, while still testing the entire way there.
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 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, 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 over-arching 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!