Authors: Lour Drick Valsote, Elliott Rodgers, Amaru Ordóñez-Jacobson
Download on itch.io!
Artist’s Statement
This current version of Turnout is a slice of what could be a 2.5D narrative-driven action-adventure game. As the final deliverable for CS 247G’s P2, this slice of Turnout features a side scrolling platformer alongside some in-game dialogue that hints at the possibility of a greater overarching narrative that could be explored in a full version of the game. Here we have what could be considered the onboarding level of Turnout, in which players are introduced to the basic movement mechanics of the game and are tasked with reaching the end of the level and accomplishing the player’s character’s mission using the tools at their disposal.
Our intention for our game evolved many times throughout our iterative process. Our original idea was a metroidvania reminiscent of games like Blasphemous and Hollow Knight, featuring the unique twist of 2.5D platforming such as in the Paper Mario series. The goal was to create robust platforming, combat, and decision-making systems, each designed to make the game come alive within an engaging narrative with cohesive theming and extensive worldbuilding. Certainly, we had grand visions for what our first-ever video game would be. Unfortunately, given the size of our three-person team, it was difficult to accomplish everything we set out to do. After about a week of more effort than results, we decided we needed to scale back. Instead of working on all three systems, we focused on just one: the platforming. A core aspect of our original idea was the 2.5D, three-layer system, and we were determined to realize it. We wanted players to feel like messengers moving fluidly through puzzles and levels, feeling overall unrestricted within our game’s system.
This adjustment also represented a shift from our original narrative focus. Instead of attempting to tell a story through decisions and dialogue, we chose to do so primarily through movement. It is worth noting that we were able to implement a dialogue system towards the very (veeeeeery) end of development, which allows for some hints at a broader story and narrative that could be told in a complete version of this game. That being said, the core features of the current build of Turnout rely more heavily on movement mechanics, with this dialogue system sprinkled in throughout the level. As we will explain later in this post, this decision inevitably raised some questions about the lore reasons behind the mechanics, but we believed that it was a necessary sacrifice to ensure the gameplay experience was as seamless as possible.
System Models
Concept Map/Doc
Initial Decisions
As mentioned earlier in the write-up, our initial aims were extremely ambitious. As Christina so masterfully put it, we were a “three-person team with six-person dreams.” Our original game centered around an enacted narrative, with the player taking on the role of a chasqui, or messenger, in the Inca Empire. The player character would be in training in their local village as the Spanish invasion looms on the horizon. Through a series of unexpected events, our protagonist would be tasked with delivering a message to the frontlines, granting him a proximity to battle that he had always dreamed of. The game would follow the player character’s journey from an idealist who wants nothing more than to be a warrior to a naïve figure overwhelmed by the harsh realities of war.
Initially, the player’s agency is fairly limited, with most options involving movement of some kind, which aligns with the player character’s background as a courier. As the game progresses, players have two choices: on one hand, they can further embrace their role as a messenger, unlocking more advanced movement and routing options, albeit at the cost of making combat more challenging. On the other hand, they could explore the path of the warrior, leading to enhanced combat abilities but more restricted movement. Both the player and the player character would face turmoil with this decision. The character struggles with societal pressures and the conflict between their dreams and destiny. The player may share in this strife but also contends with gameplay optimization and self-expression.
The initial combat and platforming mechanics, along with the design, draw heavy inspiration from several prominent indie games. Notably, Blasphemous’ metroidvania and artistic elements appeared to be the ideal framework for the final product we aimed to create. By examining other metroidvanias, such as Hollow Knight, and some platformers like Celeste, we began to form a clearer vision of what our final product might entail.
In addition to the combat portion, which we ultimately cut from the final product, the initial design also emphasized choices, much like games such as Undertale or titles from Telltale Studios. Each choice felt significant, with major decisions carrying substantial repercussions. One example of a crucial decision we planned is whether to spare or kill a Spanish conquistador that the player encounters. We considered several ways to give this decision weight. One option was to have the conquistador as the first character the player can fully kill, thus crossing the point of no return, or at least forcing the protagonist to contemplate what it means to take a life. Another possibility is to have the conquistador serve as a recurring antagonist, perhaps devastating the protagonist’s home if spared.
Our original tone was definitely on the heavier side. Some of the major themes we wanted to explore included naivety, religion, and the glorification of violence, and the story would have been conveyed through the coming-of-age narrative of our young chasqui.
There are a few reasons why this original vision did not come to fruition. Starting with perhaps the most prominent cut, our story initially fell by the wayside due to practical reasons. As appealing as it would have been to have a fully developed plot, gameplay took priority because of the nature of the assignment, and we would add more story elements later if time permitted. Then, during one of Ellie’s sections, we learned about the story of a game designer’s trials and tribulations with the Pueblo Peoples’ Kachina figures. Though this designer was well-intentioned, they ended up flagrantly disregarding the storied history of the Pueblo people and disrespecting their religion in the process. Rather than consult the people they aimed to represent in the game, they instead tried to fix it on their own, which only made things worse in the end.
Our original concept similarly dealt with a historically oppressed group of people. While the concept might’ve been interesting, we were not confident that we could execute it respectfully, and certainly not with thorough collaboration with the Inca people given our timeline. Given this conundrum, we decided that the best course of action would be to sideline the story altogether, as doing a half-hearted effort would likely be even worse.
The next concept to leave our game was the combat. This decision came much later in the iteration process, after we had mostly implemented our platforming. By the time everything was cohesive and functioning consistently, it was already around week eight. From there, we had two options. The first was to continue to develop our platforming, adding more robust puzzle design and refining the movement. The second would be to incorporate the aforementioned combat system and hope that everything was polished by the time our final submission arrived. After some deliberation, we chose the first option. A focus on platforming would help the player “find the fun” consistently. In our playtesting, one of the most consistent positive pieces of feedback we received was that the platforming and movement felt good, albeit a bit short. Diverting development resources away from it would mean diluting both the action and the platforming.
Finally, the formal elements of our game developed from the bottom up, while the values came from the top down. For our players, their role is to enact the story, making decisions for and with the protagonist. They’re behind the wheel, but only have so much agency because our game isn’t, say, an open world. Among the given objectives, Turnout is somewhere between solution and race, though it isn’t really well defined by either. The player must solve the presented platforming puzzles, but movement plays an integral enough part that it can’t be just about solutions. Perhaps capture would be a better fit than race, as the player seeks to collect the coins scattered throughout the world while navigating through the level.
The procedures are all defined within our platforming system. To achieve their goals, the player must jump, drop, and most importantly, switch between layers. Some paths will initially be blocked and require backtracking, while other puzzles simply demand creative thinking. Yet despite the movement being designed to feel free, our rules are quite strict. There are only three layers in the z direction that the player can move between, and the transitions between each are heavily regulated by the system. Furthermore, the x and y bounds of the level are strictly enforced, either by walls or by our respawn system, which will send you back to your last checkpoint if you fall below a certain threshold.
The current most important resource in our game is jumps, as you only get one at a time before you need to touch the ground again. With our current setup, however, there is plenty of room for resource expansion. The focus on movement means that time could serve as an excellent motivator for the player. Similarly, because we’ve already implemented a death counter, lives would be another easy lever we could use to control the players.
The conflict in our game is primarily of the obstacle subtype. There are no enemies and no time constraints; the only barrier between you and your objective is your platforming skills. At the same time, the boundaries in Turnout are primarily physical. Much of what you “can’t do” stems from restrictions imposed by the developers. As a final note on formal elements, the outcome is uncertain since you don’t know how many attempts it will take to reach the goal or the necessary set of inputs when you initially begin. You can learn through intuition or repetition, but the game encourages you to use your past mistakes to learn and improve. Ultimately, we hope that all our players will reach the end and feel a sense of satisfaction for having done so.
Finally, the values of our game lie largely in accessibility and skill expression. In this context, we define accessibility as meaning that the game is easy for players, including non-gamers, to understand at a fundamental level. However, this does not imply that we want our game to be easy to master. If every player is breezing through all the levels, this could indicate one of two things. In the best-case scenario, we’ve helped them enter a flow state, and they’re using that state to conquer challenge after challenge. More likely, however, this means we’ve made the game too easy, causing our players to grow bored despite their success. With this mix of easy to pick up but hard to master, we hope that our values of inclusivity shine through, while also showing that we value a good challenge.
Scope
The scope of our final project falls somewhere between an MVP and a slice; however, if we had to choose, we would likely say it leans more towards the slice end of the spectrum. Our submission includes a complete level, featuring a title screen, intentional platform design, collectibles, and fully-developed movement mechanics. One area where our design remains incomplete is in the art and music department. Currently, our game utilizes assets from the internet (the attributions for which you can find at the end of this blog post). To truly convey our world’s theming and flavor, we need to find a permanent, consistent solution. This could involve commissioning an artist or even creating our own art to ensure alignment with our vision.
Due to our ambitious initial plans, we began the project aiming to create a slice. We recognized that capturing all the core elements in a bare-bones version of the full game would be extremely challenging. Instead, we considered developing a gameplay section leading up to the first checkpoint, fully equipped with everything we needed.
It is also worth noting that this is the first time anyone in our group had attempted to create a video game using Unity, and it was also the first time any of us had really used Github for version control and collaborative coding. As a result, a large portion of the first half of development was spent figuring out how to navigate the controls in Unity and how to push code to a shared repository such that everyone could access it. As a result, the time we initially had allotted towards development was cut significantly, which is part of the motivation for reducing the scope of our game.
While the original version of the game was significantly reduced, this part of the idea remained. Rather than attempting to create a complete game with placeholders, we aimed to make it as close as possible to how it would look on release day. This involved replacing our original playermodel (early playtesters may remember a certain fire-type Pokémon) and putting extra effort into level design, both platforming and otherwise. The final stages of our game’s development included adding collectibles, as we wanted to give players a sense of purpose as they progressed through the levels. Additionally, these collectibles would serve as methods to encourage players to backtrack through levels and explore paths that didn’t necessarily lead to the end of the level. This was in an effort to make the world feel more lived-in and in future updates we would like to include embedded narrative elements by hiding lore information about the game world in backtracking sections.
Iteration History
Playtest 1 (5/6/2025)
For our first playtest, rather than a gameplay portion, we brought ideas and sketches for our game. As mentioned, we had large ambitions for what we wanted this game to be, and we spent a lot of time fleshing out these ideas. We pitched to another group at our table, and answered any questions that they had about our concept. Some examples of questions were:
“Why are we in the forest?”
“What kind of story is this going to tell?”
“Are you sure this is culturally appropriate?”
“What kind of art will you use?”
“Is this sprite a placeholder or is this a Pokémon game?”
These kinds of questions were of particular importance specifically because we were in the initial phases of game development. As we hashed out the details for what our game would look like, at least in the context of this project, the questions and feedback from our peers served invaluable in guiding the direction of our work.
Playtest 2 (5/16/2025)
For our second playtest, during section, we were focusing on making sure the layer changing worked. Although buggy, the layer changing was getting positive feedback. Some feedback was:
“In and out being J and K isn’t very intuitive. Could we use some other button that is inside and outside instead? Like the arrow keys?”
“What kinds of platforming puzzles do you have in mind?”
“What are you thinking about for the music?”
“Movement is a little too floaty. Could you make the player faster or heavier?”
As our final product for this project leans heavily into movement mechanics, we wanted to ensure that the core mechanic of our game was fun to interact with while also being intuitive for even beginner gamers. As a 2.5D platformer that does use the z-axis to an extent, there would naturally be a lot of buttons that a player has to keep track of. And at this point of development, we still had hopes of implementing combat mechanics later on in development, which would require more mappings to different buttons. As a result, we spent a lot of time mulling over which key bindings would make the most sense for players to use that would allow for a smooth gaming experience.
Playtest 3 (5/20/2025)
Our third playtest was during class, and we again received positive feedback. During this playtest, we wanted to completely solidify the speed, weight, and flow of the player character. Again, as our game focused on movement, both from a gameplay perspective as well as in what would have been the overarching narrative, it was critical to have fluid movement that felt fun to play. Some feedback was:
“I really enjoy the speed and flow of movement!”
“The layer change is really snappy and feels natural.”
“The control placement on the keyboard is a little awkward to get used to at first but becomes natural after a while.”
“Is this sprite still a placeholder?”
“Is this the only person in this world that has the lane changing power?”
Playtest 4 (5/22/2025)
The fourth playtest during class didn’t have very many changes from the previous version, we mostly expanded the platforming to give a better idea of the kinds of challenges we’d be giving players. Additionally, we began implementing scripts to allow player characters to fall through platforms and jump through the bottom of a platform. Some feedback we received from these changes was:
“I’m falling randomly through platforms! What’s happening?”
“I like the added platforms, platforming feels very natural. However, I feel that platforming is too vertical and doesn’t take advantage of the 2.5D as well as you could. Maybe try to move more horizontally instead?”
“I still can’t tell the difference between platforms on my layer and other layers.”
By this point, we had lengthened the playtime of this level through the addition of several new platforms. The idea was that the platforming would start off very basic in the beginning and gradually ramp up in difficulty over the course of the level, requiring the player to use more mechanics, which would increase the complexity of gameplay.
Playtest 5 (5/23/2025)
On the fifth playtest, we started implementing a checkpoint system because we didn’t have anything happen on player death. Our checkpoint system respawned the player character at certain locations after crossing them, but were placed very seldomly. However, we were still getting some bugs with the platforming, as players would fall through platforms at random. Some feedback we got was:
“I’m glad it just resets after I die.”
“Why do I keep falling through platforms?”
“If I keep falling how can I finish the game?”
“Conceptually really cool! Maybe add an animation whenever you change layers?”
The checkpoint system proved especially useful during play testing because it allowed players to immediately try a platforming section again after failure, instead of requiring a full reset and rerun of the game, which would also require the players to start back at the beginning of the level. As a result, we were better able to play test different sections and iterate on them, which was especially helpful given that our level had grown longer than in previous playtests.
Playtest 6 (5/30/2025)
On the sixth playtest, while debugging we realized the platform script that allows the player to jump through them was also bugging out the platforms, making the player fall through platforms seemingly at random. We shut off this component on all platforms and reworked the platforming to make sure this functionality was not required to pass the level. We also added a sprite to the player character with animations for running and jumping. Feedback was incredibly positive for this change, with comments such as:
“I can finally make it to the end!”
“This platforming section is really long without many enemies, are you going to include a fighting aspect?”
“Maybe you should include a timer to see how well you do.”
“You should consider adding a shadow of a previous run to compare how you do on subsequent runs!”
“The sprite is really cool, how did you get that to work?”
Playtest 7 (6/3/2025)
On the final playtest in class, we added a start screen to hide the boot-up scene, more platforms, and a backtracking platforming section to encourage players to explore different paths for items they wouldn’t find otherwise. Additionally, during class we changed the colors of each layer of platforms to help distinguish them visually from one another. These changes were incredibly well-received, and we got a lot of comments asking for more, which we really appreciated. Feedback from the last session was:
“Why am I doing what I’m doing?”
“Maybe have something at the end of the level?”
“I really liked the visual distinction of the platform layers.”
“I liked the backtracking for the coin, but I wish I could pick it up!”
“Are you adding music?”
“I love the startup screen!”
“Maybe you should add some moving platforms?”
“The checkpoints should occur more frequently.”
“The platforming is very smooth and there is a lot of momentum in the player, not much downtime in trying to figure out hard jumps which really emphasizes the horizontal movement.”
Final/Current Version (6/7/2025)
For the final build of the game, we focused on adding further polish to the current state of the game. We added particles for the player character’s run cycle as well as a particle animation for lane changes, which was a feature that a play tester had recommended when we first implemented the lane change mechanic.
Based on our draft grade feedback, we also sought to overhaul the look of the game. We replaced the default static image of a jungle in the background with a more dynamic terrain sculpted in 3D, which allowed for an interesting parallax effect when the player runs across the level. Next, we added post-processing effects to the lighting and color grading of the game to make it look nicer. In addition, we added a slight depth of field adjustment to focus on the specific lane that the player character is currently on, in hopes of clarifying where in the game world the player is standing. We found in play testing that players were sometimes confused which lane they were standing on, and the depth of field focus aims to address that.
Furthermore, we finally included sound design to our previously silent game. Now, there are sound effects for when the player runs, jumps, and changes lanes. Additionally, we have included ambient noise to add to the atmosphere of the game. We opted for sounds of nature rather than a typical musical soundtrack with the idea that the ambient noises would better immerse the player in the game world.
The last changes we implemented included adding a dialogue system that shows the player character’s inner monologue as they traverse the world. While our game certainly lacked any explicit narrative elements that would make sense to people that had not heard our game pitch before, we wanted to have at least something that more directly hinted at the narrative that we originally wanted our game to tell. As the player character advances through the level, they share their thoughts on being a messenger, their desire to be a warrior, and their curiosity about events happening in the world around them. Since our ambitions for this game had gotten the best of us, there were certain parts of this slice that we did not get to develop as fully as we had wanted, such as the backtracking section of the game with the coin and the very end of the level. With the dialogue system, we were at least able to provide some in-game explanation for these sections while also explaining to the player playing that this aspect of the game is something that would be explored more in a future level. The hope was that this could be enough to entice players to want to play a full version of the game.
These changes were made to directly address feedback from the final playtest in order to give the player a sense of direction as well as improving overall quality of life within the gameplay. Unfortunately due to time constraints we were unable to playtest as folks were too busy with final exams and many of these changes were made towards the very (veeeeery) end of development, but the final version of our prototype is available to download for free on itch.io here: https://amaruoj.itch.io/turnabout. Please leave us comments and feedback there if you have any!
See here for more photos and videos!
