Part 3 - Give me feedback!

Opinions are like assholes: everybody has one. But which ones (opinions) are valuable? We have a very vibrant indie community in the Netherlands and a lot of wonderful creative people tested my game before its release. Some opinions were crucial to the improvement of the quality of Should Shoot. Some obviously were not… It can be very hard for a designer to decide which ideas and suggestions to take with you and which ones you should disregard. This story should help you with dilemmas of taking or disregarding feedback.

One of the first things I learned as a designer is to always listen to feedback. Always listening is not the same taking everything into account. Developing your own game can often feel like raising a child. Everybody want your child to grow up to become a wonderful human being, as a parent you should listen to everybody’s feedback, right? Not really. As a designer, you must have a clear idea of the value of your game and the kind of experience you want to create in order to evaluate the value of the feedback on your game.

Whether we notice it or not: this seems to be our default attitude.

There’s a natural flow to my testing processes when designing a game. I’m a teacher of Usability/Playability classes at Utrecht University of Arts (HKU) and my lessons mostly focus on play testing processes for teams of 5 or more. My play-testing processes in an early phase of a project is very different from the more formal approach (also taught in my lessons) at a later stage. This developer story I want to share some best practices for the earliest forms of play-testing. These practices could also help you while conducting a play-test in a later stage of development.   

Ok this is probably the last lame image in this developer story.

My first experience of showcasing Should Shoot was early in development in its Tap Tap Shoot phase. It was during a network lunch hosted by the Dutch Game Garden. The Dutch Game Garden is an organisation that is houses multiple Dutch Indies at various locations. Their also host to the network lunch: a gathering of IT professionals where they get to present their projects or just have brief conversations with one another. More then 30 people played Tap Tap Shoot that day. Most players enjoyed the game a lot. The best comment was: “This game is great, it’s simple yet brilliant. I’m surprised there are no existing similar games.”. But quotes rarely give a proper impression of the average experience(s) of playing a game. I took notes and made a list of problems I identified during play-sessions. Because I tested early in the development process and my design goal was a bit unclear, I got a bit confused by all the feedback. I took a step back and used my experience as a play-test monitor in the AAA scene to formulate some take-aways to help me get valuable data and determine what to do with it.

As the designer: You’re the worst observer in the world.

As a designer, you’re probably the worst observer in the world. There is a big chance you’ll only monitor how testers respond to your intended design. For instance, if you’ve placed an ammo box near a boss encounter and the player walks right past it whilst you planned for players to pick it up you might just note ‘player walks past ammo box’. While someone else might note ‘Player walks straight to enemy boss'. There’s no necessarily something wrong about either observation, it’s just that feedback by someone other then the designer might shine a light on aspects of a design that the designer him/her self would not have noticed. If you’re a lonely indie like me it might help to co-operate on play-tests or to reflect with someone (could be another designer) on video footage from the test later on. 

Designers are the worst (play) testers in the world

Designers contributed greatly to the development of Should Shoot. So I wouldn't say never to test with designers but be aware of the fact that their experts at evaluating an experience. They won't think and respond to your design. They'll try and think like 'an average user' and analyze the events, look and feel in your game from the persona they created in their head. Sometimes this can help you spot errors in play-tests with players sooner. Sometimes it can be total crap and another designer-test-participant will create a problem where there really is none. And because most designers are super analytical certain features won't have any impact at all. Instead of having the experience of using a heavy impact weapon they might feek like they're making your camera shake (and critique the way it shakes too!).  

User perception from 'Interaction Desig: Beyond Human Computer Interaction' by Priece (2002)

Note observations, not conclusions

This is very important! Try and avoid drawing conclusions when observing your test-participant’s behaviour. For example: when a test participant is playing and lets out a ‘sigh' it could mean he/she is bored. But it could also be a false conclusion. If the timing is right: try and ask what’s going on. If the test participant describes events in the game that would fit a bored state then you can always ask for the test-participant to describe their own condition. Only when they say they’re bored you can write down something like ‘test-participant says he/she’s bored'.

Be aware of your tester's likes, dislikes and background

Everyone has certain tastes and preferences, likes or dislikes. And even when we think we’re aware of that while giving feedback, it often still shines through. Someone who might not be a fan of action games might start giving suggestions that help to slow the game down or they might hint at mechanics that influence the weight of strategical thinking in order to nudge your game towards something they like. This is ok. And it can be quite insightful and even useful! But it can also be really confusing. I set up a google form and asked people to fill in a questionnaire when they’re done to get a profile of my test-participants. This led to me ignoring some data or it helped me to interpret some off comments or remarks. Try and stick to your design goals and evaluate whether feedback helps you achieve those goals or not.

Be aware of your social environment

This might not be important to everyone but it’s still valuable to be aware of your social environment. Like I said, I am a teacher and sometimes my test-participants were either alumni or students. This kind of relationship influences the way you and your test-participants communicate with each other.  For example, in my case, some students commented on every single asset in my game hoping to impress with their skills as a designer. Some test-participants can also be really impressed with you as a game-designer. If possible, distance yourself from your product. Sometimes it’s even best to lie and say ‘I didn’t make this game.’ in order to enable your test-participant to feel free to talk. 

There’s some great software out there that’s very useful for play-testing alone. As a Mac user, I’m really fond of Silverback. If you want to get more hardcore this might be an interesting read. The good thing about Silverback is it’s performance. For my iPhone/iPad games however, these tools were no good. I had to resort to a small go Pro aimed at the faces and a direct capture. Capturing the screen was a horrible tragedy as I was not able to use the Lightning to HDMI dongle by Apple because of HDCP on the HDMI. 

One particular issue that came back a lot in the beginning is the presentation of score in the game. At first, the game only showed the player’s score. Players tended to tap to continue playing the next round real fast and they missed their' or their opponents score. I considered putting a back button at the end screen but it seemed weird to add another button for a player to go back to something he/she wanted to see earlier. 

Next thing I tried to implement was both player’s scores. Another big design decision: where to put the player’s score? 

• Scenario 1: Always put the highest number first, second highest number second. Both numbers can belong to either players. I would need a clear visual representation of each player. A number could be confusing. Picking an avatar or color would mean a whole new menu. 
• Scenario 2: Always put player 1’s score first, player 2’s score second. This is what I went for the first time. I thought consistency would really help player’s identify which score belonged to who. 
• Scenario 3: Always put the player first, the show the score of the other player. This is the solution I went for. It worked really well. Every play-tester I asked for their score responded with the correct answer. Consider this a tip: when building a game where players can check their own score, always show the ‘owner’s' score first, and the other player’s score second.

Asking for feedback is always a good thing. Listening to every voice isn't. It can make you confused and there's a chance you'll be making someone else's game instead of your own. Formulate your design goals and make sure you know about the preferences, likes and dislikes of the person that is providing you with feedback. Take all points mentioned above into consideration when asking for feedback or organizing an actual play-test. If you'll do this and quitely reflect on all the data I'm sure you'll be able to improve the quality of your project. 

For more tips on play-testing, check out this awesome video by extra credits. 

Part 2: No, no narrative!

Just when I had created an incredibly fun local-multiplayer game for iPad I had decided to raise the bar and make an iPhone version of a similar game. Similar? Not really because I had decided I wanted to change the experience from being mostly multiplayer focussed to being single player focus. And on top of all that I decided I wanted to tell the story of the bird man: Tangatumanu. I’ll reflect on my design decisions in an attempt to help you other designers out there and maybe even prevent you from taking your project in a similar direction. 

Of course, the radical change from a competitive multiplayer to a narrative single player experience should never have happened if I wanted to finish and release my game within half a year. I explained how a poorly defined design goal enabled me to loose focus this much in the previous developer story and thus I will not elaborate here. I will elaborate on my motivation and goals concerning the focus on narrative design.  

There are several things that motivated me to turn Tap Tap Shoot for iPhone into a narrative game. The first: a feeling that I was morally obligated to create something that would urge people to think about their behaviour. You might be thinking: “ Wow there, take it slow, bro. Isn’t that goal a bit too ambitious?”. In hindsight: yes, it is. Designing and developing your first (iOS) game is hard enough and I don’t know why I wanted to change the world with it as well. 

There's a Captain Planet in all of us (at least in me)

I have a hard time accepting the impact of the human race on planet earth. The individualist attitude and the everlasting hunger for more of everything is rapidly exhausting resources and destroying eco-systems everywhere. Boom, there I said it. What could I, as a game-desiger do to let people reflect on their behaviour in relation to these problems? I wanted to create a game where player’s are confronted with an ego-self (someone focused on their own needs and desires), social-self (someone focussing on achieving happiness by focussing on the wellbeing of the social surrounding) and an eco-centred self (someone focussed on balance of resources in the environment in relation to the local population). I want to give a brief introduction of the narrative of the game to be able to explain the design and it’s problems. 

Moai on Rapa Nui: Some of them have their bodies buried below ground.

The story I wanted to tell is that of Easter Island (or: Rapa Nui). Rapa Nui is famous for it’s Moai: tall stone statues of mysterious heads. The island of Rapa Nui once used to be a tropical paradise. However, due to overpopulation and exhaustion of resources the island now looks like a barren wasteland. It is unclear exactly how the Rapa Nui let things get out of hand. Couldn’t they have changed their behaviour before resources declined beyond a point of no return? Details surrounding this question haven’t been answered yet but we do know that the culture on Rapa Nui changed dramatically while the island was suffering. The population had forsaken their old habits and believe in the Moai. Instead they became the cult of the birdman. Scarce resources led to war between tribes. To stop the fighting the people took inspiration from the frigate bird that nests around the small islets around the island. Whoever could claim the first egg laid by the temporarily   visiting frigate birds would be the new birdman. The birdman decides the distribution of resources on the island for a year until the challenge of collecting the egg is repeated and a new birdman comes forth. The birdman challenge did not eradicate all suffering but it seems like it did return the island to a politically stable situation and one could assume life was little less bad then it used to be. This would be the foundation of the story of my game. 

Tangatumanu (bird-man) on the rocks. Men would dive off the rock into the shark infested ocean and swim towards the islet where the frigate birds nest in the background. 

I decided the player would take on the role of the deity that inspired the bird man (or: Tangatumanu in Rapa Nui language). The goal of the game was to ensure the survival of a flock of frigate birds while they’re traveling to the small islets around Rapa Nui. Gameplay was focuses on evoking the feeling of taking care of others (in contrast to a focus on individualistic goals). The player controls an avatar similar to the final design of the Should Shoot avatar. The goal of Tangatumanu was to shoot the relics of the old religion: the Moai who came to destroy the flock. The Moai stood for an individualist-self whilst the birdman cult represented an eco-self (finding happiness in balance with the environment).The player could instruct the flock to move to a certain part of the screen while shooting the enemy moai with the deity.

Telling a story with text. Fun fact: the arrow icon is the 'back' icon still used in Should Shoot.

The story surrounding the main character (Felicio) and the flock would explain the story of Rapa Nui and the islanders. But how to tell this story? Do you hate endless texts in games explaining the situation and context of the game? Me too! It was my main way of telling the story since creating animations and cut-scenes would take way too much time. It was at that time I realised this is not how you tell a story in games, even though it’s how it’s been done for almost two decades.

The best narrative experiences satisfy the player’s desire to learn more about a character’s development and their relation to an interesting game world. Want to learn more about great narrative in games? This might help you. The core-mechanics are means to explore or interact with important characters and the game world in order to engage the player. Telltales’ games do this very well: players can make important decisions while interacting with other characters or they can explore the environment in order to advance. The Stanley Parable facilitates a player’s exploration of self by having them navigate the game world: A different but interesting approach. In games where the gameplay is not focussed on sharing more about the world or context of events it is common to implement events according to the three-act structure. I realised I had two choices: evaluate/change the core mechanics or implement the three act structures and tell the story in text and animation. I even made a draft for the story events during the different levels (called acts!). 

The mechanics in Tangatumanu did not facilitate player engagement in the world and it’s context but I did not want to change the core-mechanics because of their uniqueness and how they could facilitate quick action gameplay. I did come across a great episode of Extra Credits on Narratve Mechanics. The core-mechanics of Tangatu Manu at the time were:

• Directing the flock by double tapping anywhere on the screen
• Shooting by tapping and swiping

Design of Tangatu Manu: getting a flock, managing their movement and shooting enemies.

These mechanics fit the design goal: players feel like they are in control. And they did provide the feeling of having to take care of a group: players are forced to focus on the safety of a flock of birds rather then the player avatar. Everything I had tot tell in text felt like an obstruction to this experience. It’s like a first person shooter with long cutscenes.

I decided I had to redefine the focus of my single player game. The quality of playing the game was best with Tap Tap Shoot when player’s competed with each other. Competition was the best fit for the shooting mechanic. My design goals were rephrased as:

1. The game is about competition: the sweet taste of victory or the sour smell of defeat. 
2. Players feel like their skill (with shooting) and tactical decisions (placement) define the outcome. 
3. Players always feel like they’re in direct control of their avatar and the related events on screen.

Telling a story did not contribute to the feeling of competing! I realised I had to re-think the whole single player experience. It was nice to let go of the art-style since it was a bit time-consuming (considering I’m not really a 2D artist). It was at this time I also started working on the local multiplayer and an art-style that would communicate function while still being customisable. 

One enemy in Tangatumanu chased the avatar and fighting this enemy was by far most fun thing in the game. I tried balancing the enemy in such a way it felt like a challenge: starting easy and getting harder to dodge and shoot as the player progressed. Since I did not want to waste the player’s attention with unnecessary story the enemy had to be something that could come after anything and that anything would always know the enemy is dangerous and is to be avoided. What could that be? A rocket of course! Single player rocket was born.

Players responded really positive to the Rocket mode. I wondered why. My personal philosophy on game-design is that the game should offer the player an interesting choice over x (x = length of time). The 1P Rocket Mode was fun because players had to choose every second or so whether to dodge or shoot the rocket. The 1P Rocket’s behaviour forced this choice on the player by chasing the avatar.

What remained of Tangatumanu in Should Shoot: The Rocket Mode.

I was delighted to learn players were having a lot of fun with the Rocket Mode. It was by this time I also re-made the multiplayer mode that formal existed in Tap Tap Shoot. Since the goal of the game was to facilitate competition: I started thinking of it as a tool rather then a narrative experience with context. I redefined the art style: it had to be as simple and clear as possible. I also allowed for customisation of the game by implementing alternate color schemes and backgrounds. I noticed how players told each other stories about how they narrowly survived and won or how small the chance was for a draw though it still had happened. Players did not consume a narrative: they created one by communicating with each other. 

The biggest takeaway here is that a gamedesigner can't slap a little narrative on to an existing project. IF you do the experience is unlikely to improve: there’s a big chance everything you’re trying to convey something to the player that will just be experienced as being ‘in the way’. Designers should think about the story they want to tell and come up with mechanics that fit with that concept. Navigation and observation are the core mechanics of a first-person game and there are a lot of examples of first-person games that really tell a great story through gameplay. I did not think about the story when I came up with the concept and my narrative did not fit the mechanics. I could have changed the core mechanics but that would have changed my project entirely, increased the already heavy workload and would have required a lot of iterations before it got to a certain level of quality.