Process of Design for ‘Tether’

Hello all, I present the post-mortem for Teather my latest (as of this writing) collaborative game at Sheridan! Working with Nicholas Phan and Alexandru Chira.

A rough approximation of the Tethered main screen
A rough approximation of the Tethered main screen

Intro
What is ‘Teather’? Teather is a 2D platformer focused on cooperation, you and your partner are TETHERED together, and have to swing yourselves from platform to platform. Can you use physics to your advantage? Or will you fall to your collective death?
If you like the look of super hot, the joy of local multiplayer, and the acrobatics of Indiana Jones, this could be the game for you!

Design and Development
DThe design takes many steps. For this week’s game, we needed to either go competitive or cooperative, we chose co-op, and tried to build from there. This is easier said than done, but after a weekend of thought, the idea of a teather was put forwards. Mixed with a Little Big Planet style grabbing mechanic we had the basis of our game.
Form there we looked at level design. Our levels went through a few theoretical variations: we began with a large 2D world, made up of a series of puzzles. As we moved into development time and technology united to force us into a new method of level design. We ended up with a series of individual levels, all taking place in one screens worth of space.
With that settled we began producing the layouts. Nic brought some of his own resources for player control to the projec in the form of a ‘starter pack’ this ended up being the building blocks of each level.
We would grab a new scene, bring in a ‘Starter pack’ and block out the platforms with unity primitves. THis freed up our time to focus on unique and intelectualy challenging puzzels.
Once we each created 4 or more puzzels they where imported into a single project, and our first build was made.

Playtesting
More than almost any previous project, playtesting was essential to our success. The constraints of physics and the tether meant we had very fine lines that separated a good level from an impossible one. Each level was playtested by us throughout the building phase. Some levels we had to test and redesign as many at 8 times (at 2-6 test per redesign).
After the first build we needed to make sure others could play the game, we tested with 6 other people and in that process found dozens of quirks and glitches we would never have otherwise.
presentation
Our presentation was fairly strong, as always we were a little tired but we and the rest of the class managed to pull through. The game was well received, and people seemed to enjoy the game.

Post-Mortem
A lot went well, our team brought a mix of talents to the table. From the get-go, ideas seemed to form well. And the forethought to package past assets helped speed up development. Even playtesting went very smoothly.
Net time I would like to work on the game earlier, though this is often determined by course work. I would also make the player’s keyboard compatible so we could have a web version ready. As it stands, the controller version is still very fun.

Conclusion
The team worked well, the game was fun, and don’t leave your dev blog to long or else you forget stuff!

Leave a Reply