“But what if the couch didn’t want to leave?”
Curbside is a third person physics based adventure game where the player controls a sentient couch.
Fifteen week project developed during a semester abroad in Montreal (August 2017 - December 2017).
Developed using scrum and agile development techniques.
Lead Designer (Systems)
Harry Lindner (Designer, Programmer)
Michelagelo Demo (VFX Designer)
Conor Tully (Designer, Repository Management)
Amanda Gates ( Level Designer)
Gavin Heironymus (Producer)
Rory Einiger (Producer)
Rian Atherton (Artist)
Kyle Mays (Narrative Designer)
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.
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.
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.