Curbside

“But what if the couch didn’t want to leave?”

Project Description:

Curbside is a third person physics based adventure game where the player controls a sentient couch.

Development Info:

• PC

• Fifteen week project developed between January 2018 - May 2018

• Developed using Unity 2017

• Developed using scrum and agile development techniques.

My Roles:

• Lead Designer (Systems)

• Technical Designer

• Team Management

• QA Facilitator

Team Members:

• Harry Lindner (Technical Designer)

• Michelagelo Demo (VFX Designer)

• Conor Tully (Designer)

• Amanda Gates ( Level Designer)

• Gavin Heironymus (Producer)

• Rory Einiger (Producer)

• Rian Atherton (Graphic Designer)

• Kyle Mays (Narrative Designer)

Premise:

This couch lived peacefully; providing a safe, comfortable spot for its family to sit and bond with one another. That was until one day, during one particularly heartfelt family bonding moment, the couch let out a soft sob of happiness, and its family, mortified at the seemingly possessed couch, tossed it to the curb in hopes of ridding it from their lives forever. This act of ungratefulness angered the couch and caused it to become bent on getting revenge. The main objective of the game is to wreak havoc on the family’s property by collecting the five orbs of destruction and using them to channel other-worldly power that will smite the family for their indiscretions.

Conception:

Curbside was born from a concept known as “The Couch Dilemma”. This refers to the often puzzling nature of moving a couch around a house, specifically around a corner; often requiring the couch to be rotated at odd angles to make it fit through an opening. The idea was to personify this dilemma by controlling a sentient couch as it moved around a house.

Curbside Systems:

Prototyping and iterating player movement:

The initial challenge was creating a series of movement mechanics that would allow the player to control a rigid, couch shaped object, in a way that feels intuitive, realistic, and not cumbersome.

The initial idea was have the couch’s movements reflect how an actual couch would be moved in a real physical space so it would not create too much cognitive dissonance for the player. In our early stages of prototyping, we allowed the player to make 3 distinct types of movement, a forward & backwards roll, a left & right roll, and sliding the left or right side of the couch forward & backwards (like a shuffle) to allow for turning.

In testing our basic movement, a few things started to become clear. The core movement mechanics, while functional, were somewhat hard to control and the players lacked a level of precision that allowed them to complete the obstacle course we had set up for testing. Through rapid iteration and continuous testing, we eventually concluded that this was a factor of two things, the player’s lack of reliable left/right movement, and our key bindings.

Players had no easy way to cover large distances as this would often require them to either awkwardly shuffle forward or roll like a madman and hope they did not either overshoot where they were aiming, or lose control in the middle of transit. To remedy this, we added the ability to strafe left and right which then allowed players to angle themselves in a direction and then slide over to their destination.

The elephant in the room however was our key binding. Our initial control scheme relied solely on using mouse movement to control the couch. The idea was that the player would be making the same, or similar physical movements with their hand that the couch would make in game; reducing the cognitive dissonance with trying to manage a rolling/sliding couch in real time. While this allowed players to better understand how the couch would respond, the control scheme did not feel intuitive to use and was rather tedious when making large movements as player’s often did not have enough desk space to make a lot of the necessary mouse movements.

On top of this, because we were using just the mouse to control the couch, we needed to restrict the player to only being able to use one movement function at a time, requiring them to have to toggle between individual abilities as well as camera movement. This severely limited what players were able to accomplish and often ended up with players simply frantically moving the mouse to try to glean some sort of accidental advantage by bumping the environment in such a way where they got lucky and were able to progress.

Our remedy to this issue was to remap our control scheme onto an Xbox controller, as this allowed for players to both execute multiple movement abilities at once, and provide a constant input for rotating or sliding; eliminating the need for tiresome arm movements. This in turn, allowed for a higher player skill ceiling as players were now able to execute significantly more precise and advanced maneuvers which allowed for more interesting level design opportunities. This change in control scheme also brought to our attention a bug that allowed players to fly. However, after initially removing the bug, we noticed players having less fun as it felt like we were being too restrictive on what they were allowed to do. We realized the ability to fly did not negatively impact gameplay, and was often one of the player’s favorite abilities to use. So, we decided to make it a part of the full game and keep it as another movement maneuver the player could execute if they were skilled enough.

Perhaps one of the most helpful changes that switching inputs brought to the game was the new camera behavior. Since the mouse previously drove both player and camera movement, the player would need to toggle between the two abilities and as such would not be able to move the camera as they moved the couch. In addition to this, all of the player’s movement abilities were relative to the couch, meaning if the player moved the mouse forward and the camera was looking at the right side of the couch, it would not roll away from the camera and would instead appear to roll right.

When we transitioned to a controller however, we were able to decouple these abilities and use one joystick for player movement and the other for camera movement. However, this meant that implementing camera based movement was of extremely high priority as this change made the couch based movement feel very frustrating and clunky. As such, we spent a good deal of time updating the movement code base to be significantly more dynamic, which made controlling the couch feel incredibly intuitive and fluid despite it being a rigid object.

Teaching Through doing:

While the process of transitioning from mouse to controller did allow us to loosen up on the controls and allow players to execute multiple movement abilities at once, it made one issue a bit more apparent; our confusing control scheme. Since we had lost that mental link between physical action and game response when switching inputs, players became even more confused about how to control the couch. In addition to this, when refactoring our code, we still had to maintain a few checks to keep the movement from breaking. Both of these factors made it rather difficult for us to show or explain to players all of the minutia involved in moving the couch. One idea we came up with was to give the player the option to toggle an instruction page on screen. However, we quickly decided that this would become tedious, needing to constantly toggle between instructions and play. What we ultimately decided on was implementing a reactive UI system that displayed the buttons and actions a player could perform to execute a movement function, and would behave differently according to what the player inputted.

By default, the UI would display grayed out versions all of the buttons the player could press at any given time. If the player pressed one of these buttons, any UI element pertaining to an action the player could no longer perform would then disappear. Likewise, any actions the player could still perform, would remain visible. This system allowed players to teach themselves how to move the couch with zero input from anyone on the development team. During testing, prior to implementing this system, we watched players pick up the game and go from initial confusion to complete understanding, and sometimes mastery, faster than it would take for us to explain the control scheme verbally.

In addition to teaching the player movement mechanics, the reactive UI was also able to teach the player more abstract abilities like our orb collection mechanic. In order to collect an orb, the player simply had to bump the couch into it and the orb would cling to the couch wherever it made contact. All collected orbs were then dropped if the player pressed the X button. The catch was that the grayed out X button was only visible on the UI if the player was holding one or more orbs. This, combined with their existing knowledge of how the reactive UI functioned, taught players how to drop their collected orbs through experimentation.

In addition to this, with a more clear explanation of the movement system, and a higher skill ceiling, players began to try to push the boundaries of the movement system trying to pull off more and more complicated maneuvers. Seeing this, we decided to add a slow motion ability where players could slow down time to readjust their angle or position in the middle of a maneuver to perfectly nail that one feat they have been wanting to pull off.

This drive to execute high level maneuvers led us to creating a “Couch Co-op” mode, where two players work together to control one couch. The controls are evenly split, one player controls rotating, and the other controls strafing and sliding. We were initially worried that this cooperative mode would be impossible since the movement system was so complex and intricate. However, it seemed to have the adverse effect, where players were able to spend all of their mental focus mastering their respective abilities as they had less to focus on overall. Additionally, since players were a bit less overwhelmed by having to manage all of these mechanics, they were able to work together in new ways. A player favorite was cooperative flying, having one player act as the thrust, and the other aim the couch where they wanted to go.

Postmortem:

“Curbside” was my first experience working on a team size of more than 5-6 people and naturally there were a lot of lessons and hardships that came from it. This project was the first time I had been in a position to have my game cut and deal with on-boarding new team members. The original team of six had about five weeks to prototype a vertical slice of gameplay, which we would then pitch to a small panel of Ubisoft employees. After the pitch, they would come play our games and deliberate on which had the least risk associated with it, cutting the games that were too risky.

Before we onboarded new members the team was small enough that I had a very easy time managing the design direction and we all had a very clear vision for what “Curbside” was; a physics based, adventure narrative game where the player played as a couch trying to reclaim a spot in its home after being exiled. However, upon bringing new team members on board, we struggled to communicate what exactly our narrative was and new ideas were thrown out, some were liked, some weren’t, and some were adopted by some members and not by others. We very quickly found ourselves in a position where no one really knew what the narrative for the game was and no one was in a narrative design position on the team since we left that role up to the team as a collective.

I was the lead designer on the team and one of two stand-in programmers, meaning my hands were full. I spend my work either programming the couch/gameplay events or trying to manage the team and unify our vision for the game. Being a fifteen week project, we did not start having these issues until about halfway through development, meaning we had very little time to fix the issue. We eventually did iron out a more solidified vision for the game as we soon found ourselves with a design and programming stand still until the issue could be solved. I then held a number of meetings with the sole purpose of rectifying the issue and patching together a new team vision. Unfortunately, this meant a few major adjustments to the game’s narrative which was simply not feasible with the given time frame.

In the end, on of our biggest hangups on “Curbside” was both creating a narrative and designing gameplay around it, using that as the foundation for our game. We originally designed the game around one mechanic; moving the couch. The narrative while present in the game, took more of a back seat as we focused on the gameplay which ended up hurting us in the long run since we struggled with making steps to finalize the game once the basic movement and gameplay structure was set up since we only had a shaky narrative to tie these systems and mechanics to.

On a related note, another huge issue with “Curbside” was our road-mapping. Because we did not have a strong narrative to base our development decisions around, we found ourselves in a difficult position between developing a narrative while polishing gameplay. We found ourselves needing to add in additional, less polished features to try to bring out a sense of narrative, that just was not there. This also made assigning tasks to all of our team members rather difficult since it did not ever feel like we knew what needed to be worked on. So, in the end the allure of “Curbside” ended up being simply mastering the couch movement, which admittedly works phenomenally well and is rather fun. However, beyond this mechanic, the game falls extremely far from the tree as there really is not much to do beyond this.

If I were to go back and start this project over now, I would go in one of two directions. I would either immediately establish a strong narrative and base all of my design decisions around it. Or, the more likely option, I would scrap the narrative aspect entirely and design the game to be played in a more playground-like setting awarding points for pulling off maneuvers, getting to certain areas, breaking/collecting an object, etc. I feel as though the latter would be a better move because, while the lore is wacky and fun, “Curbside’s” strengths have been and always will be in the couch’s movement abilities.