Tightrope

Overview

My main goal was the outline the structure of the game and how the story beats should unfold. A big challenge was figuring out how to keep the player engaged in such a heavily story and text driven game. The solution I came to was by adding mini-games (or as we called them Vignettes) as an additional interactive narrative tool. These vignettes work as a window into the target character's inner life, reflecting their day to day and how invasive questioning by doctors add a strain to it. As the player progresses they replay a similar version of the Vignette over and over again, getting progressively more twisted each time they play. The individual vignettes get slowly harder as they tackle different characters to further hook in the player and so they don't become desensitized to purely reading text.

Game Design Document - Tightrope

Documentation

As the timeline for this project was tight and that there was an external client. The aim was to create the most polished product with the least amount of difficult to implement content. This was partially a challenge as keeping the player engaged without introducing a lot of novel gameplay mechanics was difficult. The main constraint I imposed was that the entire game had to be playable with a simple mouse click, this was based around hidden object games as they can be found in newspapers and in casual mobile games that are very approachable.

It was this "hidden object-like" mechanic which I developed. Introducing a simple tutorial in the form of click the weeds on a gardening field, seeing the weeds take over the small garden. A butcher having to cut pieces of meat the clients ask for, by finding the correct shape of meat. And finally finding a correct sequence of rocks to knock down in order to create a statue. All of these mini-game are based on the idea of looking for a specific item in a scene made up of other objects in different skins.

Here you can see the Game Design Document that I wrote for this project which was handed and cross referenced by the team to get the project to it's final state. I used Google Docs and kept updating the document live, informing the team where changes were made to the document for them to look over, implement and comment on if the changes were technically feasible or not. Some big overhauls were kept in the document to see the evolution of the ideas and to keep it for archiving in case of legacy code issues and most importantly for the ability to reflect on past changes. A strong focus was put on using visual diagrams to convey information as the team was way more receptive at interpreting concepts from the GDD.

Feel free to scroll through the game design document on the right.

Iterative Design

One of the mini-games dubbed "Sculptor," was the most challenging part of the design process in Tightrope. The mechanic in this Vignette was as follows:

The goal is to chip away at a shattered piece of rock to reveal a statue underneath. To do this the players would have to repeatedly click on stone blocks on the edge of the overall rock to slowly break them down. If the rock were to be hit on a block fully encircled by other rocks the statue would crumble and a new pile would be brought over

New design diagram

Old design diagram

What felt like a simple idea on paper, had brought a few design challenges. First of all this design felt kind of like a step back in challenge. The first mini-game was a simple flower picking game where you could press objects to progress in any other, then the second mini-game was a game where you needed to press on objects requested by a speech bubble. This did not feel like a progress in difficulty it was in an odd in between the two mini-games in feel. Secondly was the issue of teaching the player to go from the edges. For the mini-games we wanted to avoid at all costs any sort of non-diagetic tutorial explaining how to play the games, with the "edge-breaking" mechanic this was hard to convey in a quick manner.

The second rendition of the mini-game got transformed into a sequence finding "puzzle" where the player has to click all the blocks in a given randomized sequence. This was something that felt more challenging than the previous mini-game, and was a good step up difficulty. However, this didn't answer the second issue, the abstractness of mechanics, if anything this made the issue worse.

My first idea was to add a "durability" to the stone, meaning if the player clicked a stone out of order, the whole rock would get damaged, giving the player 3 tries to find the correct stone. Once the player found the correct stone the durability would reset and the whole loop would start again until there were no stones. To aid (as three strikes and you're out when guessing was obviously harsh), I have made it so the correct stone would slightly wobble to indicate to the player to click it.

This felt like the perfect solution and I was happy to move on however after doing internal play testing, there was still something that felt off. The durability taking damage when guessing felt like we were punishing the player for doing what they are meant to (searching for the correct stone) so to fear was that we were giving the player the wrong feedback. What in the end made it to the game was a simple change, making it so the correct stone "shakes" once the cursor gets closer to it. This was a perfect balance of giving the player feedback without punishing them, while making it feel more like a sculptor searching for a correct strike. And now the durability felt more like a challenge not an inevitability that you will mess up (even if intended and accommodated for by the design) giving the situation a form of stakes.

This fit perfectly into the progression of mini-games going from: click all interactable objects > find asked for specific interactable object > search for the correct interactable object in sequence.

Page updated

Google Sites

Report abuse