dinsdag 18 augustus 2015

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. 

dinsdag 11 augustus 2015

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. 

vrijdag 31 juli 2015

Part 1 - Touch baby, TOUCH!

'Learn how to code, bitch!' This is what I thought the first 5 years of my career as a game-designer. In fact, it’s the tip every gamedesigner on my online web show ‘Indiekings' gave whenever I asked them what their advice would be for aspiring designers. Ok, they might have left out the ‘bitch' part. Should Shoot is the first release I worked on as a programmer. This story describes the design and development process of Should Shoot’s core shooting mechanic from the perspective of a coding virgin or: a n00b. Non-programmers, designers and other n00bs are likely to find this an interesting read. Code Gods: this is not for you. Sorry!

As a designer, I’d love to surprise gamers with innovative gameplay. Says every gamedesign student ever. I did too, and I actually do stuff these days you could consider innovation. For instance, I tried shitting backwards not too long ago: it didn’t work, I tried. And guess what? This is what makes me a designer! There’s a crazy idea, you try it out and analyse the results. In some industries, senior -insert any management position here- means that as a senior: you KNOW stuff. Why? Because you have been a senior for so long, you have studied, remembered and now you’re an expert. With game design this could be true for production skills but for a large part of your work you’ll never be an expert. Why? Because player behaviour with a new system (your game!) is so darn unpredictable. And because hopefully: your games are in some ways something that never existed before. It’s the crazy ideas, INNOVATION! 

Innovation Pus
True Innovation.

Hardware innovation has always driven innovation in software- and game-design and so new hardware is always interesting to me. If you would have asked student me ten years ago what kind of games we would see on today’s  mobile platforms I probably would have said we couldn’t even imagine at the time. Touch-screen interfaces, dedicated health or motion chips, light sensors, connectivity over wifi, GSM/CDMA, Bluetooth, microphone, flashlight, almost every gamer is practically married to a little super computer with this hardware. And what does the industry offer a gamer? Mostly clones or ports of retro games or ports of desktop games (I won't hate on AppStore related stuff too much since I already did it last time in the prologue to this story). What if designers embraced at least one of these hardware features and focus on creating a game and experience not possible on other platforms? Well, the endeavour would be time consuming, thus potentially expensive with a huge risk for failure.  

The list’s with developers actually making money on the AppStore: I consider only few of those titles are innovative

What started as nothing more then a scruffy looking photoshop doodle and a few words in an .rtf file would eventually become Should Shoot. At the time, I could write some simple code in Actionscript 3 (mostly animation related stuff) and I was able to get some simple stuff done in Unity but it would take me weeks to create simple mechanic. I briefly mentioned in the previous developer story how my conversations with players of Adriaan de Jongh’s Bam-Fu prototype  sparked my first idea for Should Shoot. Adriaan even kindly sent me his prototype by mail after the play-test but at the time I wasn’t capable enough to actually make use of it. This made me realise the value of my idea. Zero, nothing, nada. If I couldn’t see what it did with players, I had no way of knowing the quality of it. I started doing tutorials of both Unity and Gamemaker in the evenings: I had to learn how to code.

Look it’s Gamemaker and Unity! you can download it for free!

I wasn’t the father of the first prototype of Should Shoot though. 'Tap Tap Shoot’ as it was called then was made by the talented and admirable Niels Keetels, a friend and colleague at Utrecht University of Arts. Settle in while I take you on a journey to the summer of 2012. A summer when Niels and I didn’t go on a holiday. We went nerd. We jammed. During a 14 day gamejam, we shared the role of game-designer. Stupid idea. NEVER ever do this in your project. Tip: don’t share the role of designer in a jam with a small team. I strongly believe that someone with a talent for creative (lateral) thinking and excellent analytical skills should be responsible for the game-experience. This designer should be open for ideas and suggestions from the team, but he or she has to be able to make strong decisions based on design goals that define the kind of player experience. Our brainstorm session resulted in a concept a that would be part building, part rhythm action game. It was a big clusterf*ck of ideas, accepted by both of us because we did not want to hurt the other one’s feelings. 

I love talking about design goals like a fat kid loves cake. Yet it’s hard to actually be aware of their value when you’re full of energy at the start of the project. It’s tough to reflect on ideas while they’re in their infancy. It’s like having kids. You inherently love them from the moment they are born: just because you created them. But there’s no way to know their qualities or to pinpoint exactly why you love them and what they could accomplish. There’s a huge difference between these darlings though: kill the bad ideas, NOT the kids. 

During one of our daily morning meetings, Niels and I realised just what kind of mess we got ourselves into. Design issues everywhere. We weren’t sure what kind of experience it was supposed to be. Even if we were to elaborate on the clusterf*ck, we were confident we would have to iterate on it a couple of times to turn this experience into an enjoyable one. We chose to axe the project. Start over. We had 72 hours left. That should be enough to conquer the world with pure GENIUS game-design, right?  Niels wanted to know if I had any concepts lying around. I drew what was then still called ‘Rocket Riot’ on a piece of paper. Niels liked it. At the end of the jam, we had a first playable that looked something like this:

Impression of first playable prototype of Tap Tap Shoot.

The prototype was a huge success! Not that we conquered the world with it, but people were enthusiastic whenever they played it. The game ran on iPad 1. The goal was simple: shoot the other player. A playing field covered the entire screen and was divided by two halves: one for each player. Players appear on their part of the screen by placing their first finger. The second finger should be placed behind the player character (a disk). What to call a game where player’s have to tap, then tap again to shoot? Tap Tap Shoot, of course. I wanted Tap Tap Shoot to be a fast paced action game, so it made sense to me that player’s would shoot a bullet the instant they placed their second finger on the screen. To avoid the other player’s bullet’s, players would have to remove both their fingers and place one somewhere else on the screen. When a player gets hit, the game is over and the surviving player get’s a point. First player to get 3 points would win the game.

The art style of Tap Tap Shoot was inspired by the steam-punk retro futuristic style also seen in Disneyland’s discovery land (home to the Space Mountain). I can’t believe I went for this. I’m still happy I did though, as the terrible art style sparked a lot of questions and suggestions that would help me in defining the final art style. Question’s like: 'What am I?' 'What am I shooting?' 'Why can I teleport?' encouraged me to think of an art-style that would inherently answer these questions. So wooden objects would behave like you would expect from wooden objects, lightweight, easily breakable with floaty bullets. Metal would be heavy, rubber could bounce and so on. Hurray for skeuomorphism! People spent an average of 10 minutes playing the prototype as I carried it with me at game-conferences, indie-meet-ups or other social events.

Interfaces of ‘Notes’ App for iOS: left is skeumorphism in design: the interface resembles an actual notepad, the right is a more abstract representation of an interface used to save notes. 

A year went by. I worked mostly on freelance projects as a graphic,- or interaction-designer as well as ’15 Second Zombie’. The latter was a side-scrolling zombie game with kid’s as protagonists’. I encountered all sorts of issues during this project. Did you know, 99% of anyone's ideas are total crap? This becomes apparent when you transform you’re ideas in playable prototypes. Maybe that’s the reason too few designers still want to learn how to code? The next thing you’ll learn when you start writing your own code is that 99% of the first 10.000 lines suck as well. I learned what people would call the basics of mobile game development by doing it wrong the first time. Performance issues, memory issues and what not. *Points finger in the air* Be aware of the importance of resource management and the impact of your coding practices on performance! Articles like these on how to optimise your performance helped me a lot! I had to change a lot at one moment for 15 Second Zombie that I considered starting over (a wise decision I learned from an excellent blog post by Ronimo’s Joost van Dongen). The blogpost had not been written at the time so something else entirely pushed me to start over or perhaps stop working on the project entirely: My ex-girlfriend broke up with me. It was a devastating event for me and I didn’t feel like working on 15 Second Zombie anymore. So what other projects did I have lying around? Tap Tap Shoot! By the way this is the part where readers start checking their scrollbars to see how long this freaking story will last: almost halfway buddy, almost half way.

New project, new beginning. I made a huge list with all the feedback gathered during the times people played the first prototype. I redid the visual design and the idea was to apply skeuomorphism so player’s would understand the behaviour of game-objects. I decided to set up design rules. First rule: the player always feels like he or she is in direct control. Second rule: well that’s where a lot of trouble begun as I hadn’t thought about more design rules.  

There was a big problem with the core-mechanic in the first prototype: people had trouble aiming their shot. The resulting behaviour was for players to fire multiple shots so they could tell where their bullets were heading. The result: unnecessary spamming of bullets which reduced tactical play. It promoted and sometimes even rewarded chaotic and unskillful play. One of the things I planned to introduce in the new version was an abstract version of an iron sight so people could tell where their shot would go. Seems like genius me hadn’t thought about that when writing the elaborate design document.

                                Tap Tap Shoot! Now with astonishing reticles!

Writing code for the game was actually quite a challenge. Well writing it wasn’t but getting it to do stuff was. Remember, I just upgraded from total n00b to kinda n00b in programming (these are not official terms to describe skill levels). The challenge is to handle input from two players with two fingers, mathematicians reading this have already calculated there are at least four different fingers on the screen to handle gameplay. But players tended to keep their hand above and sometimes even on the screen, which adds 2 accidental mouse-inputs. I tried to figure out a way to ignore the accidental input by measuring the time the input lasted and the constant movement. Players tended to slightly move their arms around a bit. This distinguishes accidental arm input from purposeful character movement because this was done by tapping the screen. So if the input (device_mouse_button_check(i, mb_left) lasts longer then half a second or +/- 30 fames and shows slight translations in either the x or y axis, refer the character or shooting finger to the last known position. But could gamemaker even track as much as 6 input signals? Yes. It can handle exactly 6 different ‘mouse device’ type inputs. The next challenge was to figure out when the player avatar should listen to which finger. Gamemaker counts how many times the screen is pressed: 0 being the first press, 1 the second and so on. If all players would wait for each other to place their fingers and then start playing there would be no issue, you just assign the first two inputs to the first player (maybe add one as a buffer for the accidental hand input) and assign the next two or three to player 2.  

How to play Tap Tap Shoot: First finger to appear in the screen, second to aim and shoot!

However, players have to shoot frantically, which means any input can belong to any character. There’s no such thing as finger recognition on the touch screen either of course so how do I know which input belongs to which player? It wasn’t as hard as I thought but I had to check the details of the way gamemaker handled multiple input from touch screens. I could determine where players pressed the screen: the upper half is always input for player 1 while the lower half is always input for player 2 (for reference, check the image above). Remember, I never faced a problem like this before so I also had a lot of questions that seem silly to me now. For instance, whenever a number (n) get’s assigned to input, is it constant once the input is given (does it stay the same when the program is running) or does it change per frame? I had to find out if (scenario 1) n gamemaker returns is the id (a id number) of the touch input or whether (scenario 2) n was based on the total amount of input on the screen. (remember all non-programmers, counting in programming languages always starts with 0). In both scenarios, the first input for placing a character (for example, player 1) would always be 0. Let’s imagine the second input is from there other player (2) responding to it. Since it’s the first input on the second half of the screen, the game knows that the avatar of the second player should appear at the location of the second input. Now player 2 places his/her second finger to shoot. Now we have: input 1 with n = 0: finger of player 1 spawns avatar to that location, input 2 with n =1: finger of player two: avatar of player 2 spawns to that location and input 3: player 2 shoots a bullet. And what if player one removes his/her finger from the screen in response? In the first scenario, input 1 would n =0, input 2 does not exists anymore and input 3 would still be n = 2. In the second scenario, input 1 would still have n = 0 but input three would now be demoted to n =1 since input two with n=1 would not exists anymore and input 3 was the last new input. It turned out scenario 1 was how gamemaker handled input, the number represents an ‘id’. Which leads us to the next question: now two inputs are on screen with the id’s 0 and 2, what id would a new input four get? It get’s the lowest free input id: in this case 1. I also found out that (of course) the id only changes when input does not exist anymore, so once the screen is pressed, it will keep the same id until the input disappears when the player removes their finger. Writing the final code for player input appeared to be rather simple: I just checked if there was any input on one of both sides on the screen, if it was the first the player appeared at the location of input (this means the player’s behaviour is activated) or when a player already existed, a bullet would be spawned in the opposite direction of where the player pressed it’s finger. 

Scenario 1 and 2 explained.

I could not ignore accidental shots fired since bullets fired with the press and not with the release of the finger and checking for movement in order to possibly ignore the input measured a distance over time. This bothered me a bit and I considered having players fire when they release their second finger, but that would take away some of the speed of play and therefore possibly violate design rule number one. In any case, whenever any of the fingers would be removed, the avatar would start a timer and once the timer hit 0 the avatar would remove itself from the screen.

A strange bug made it’s way into my code. Sometimes players could not dodge or shoot although they were pressing the screen. This obviously frustrated a lot of players as it always happened when a game got intense. I thought I had made a programming error because somewhere along the line, in spite of my thorough testing process I had misunderstood how gamemaker handled touch input. I started double checking my assumptions and started double-triple or even quadruple testing my code for errors. Maybe gamemaker can handle only 4 inputs at the same time? Maybe the code checked for input in the wrong order? Maybe the code did’t allow the player behaviour to activate quickly enough resulting in it ignoring the second finger? I even made sure the game ran at 60 fps with 3 checks per frame for player actions. I kept running into the problem where player input would be mis-interpreted or not activate player or shooting behaviour at all. Colleagues at Utrecht University of Arts even went through my code with me and we found no errors. Then I found out that gamemaker automatically assigns a double mouse button press as a right mouse button press. So the rapid tapping by players in Tap Tap Shoot sometimes registered as a right mouse click and for this reason the expected actions like shooting or avoiding did not always happen. Well that cost me a week of endless code-checking and testing (Tap Tap Shoot was also hard to test on your own because I had to use 4 fingers on 1 iPad screen). I ended up adding device_mouse_dbclick_enable(false); to it the conversion of double taps to right clicks and voila! everything worked perfectly. The downside was that I learned gamemaker always has something up it’s sleeve, something hidden somewhere that might be interrupting your work. The upside was that the code I had written worked flawlessly, hurray for programmer me!

Development went along smoothly for a change. One of the design problems on my big list was that players didn’t always notice when they got hit. I tried scaling the player, but that didn’t always help because player’s own fingers covered the avatar anyway. Stubbornly, I tried adding dust particles near the impact zone. That did not help. Then I tried breaking my own design rule. Whenever a player got hit, his or her avatar would kind of bounce away with the force of the bullet that hit it. That worked really well! No player had reported not noticing his/her own death with well over 10 different player playing at least 3 games in a row. I also noticed that the whole skuemorphism idea didn't work that well. The screen size mostly dictates the ideal speed and behaviour of the bullets and players. I would only limit the potential fun by sticking to the expected behaviour of the materials.

Skeuomorphism in Tap Tap Shoot.

Some players (especially the ones with fat fingers) had trouble overseeing all the events in the game. Some also had trouble shooting. When Wytze Kamp and Yhorik Aarsen from the Ostrich Banditos came over they suggested altering the mechanic so it wouldn’t involve two fingers. I thought about it. Players were so enthusiastic about Tap Tap Shoot, they started asking if there would be an iPhone version as well. I started considering that as well. It would mean I had to make sure players could shoot using only one finger: no way there would be space for 4 fingers on a 3,5” screen. Right? 

To the left: the initial sketch for iPhone version of Tap Tap Should which would evolve to ‘Tangatu Manu’ on the right.

My main design rule: 'Players always had to feel like they are in direct control.' was more or less what I liked about the mechanic, but it took me on a crazy trip down a path to create a more single-player centric game with an deep-philosophical narrative. I dropped the name ‘Tap Tap Shoot’ and went for ‘Tangata manu’. (This is not a joke, this actually happened and I will tell more about that in the next developer story!). The ‘narrative design’ approach also let me to reconsider the fact that players could move to any location instantaneously. I decided player’s would be able to shoot just by touching the avatar and dragging their finger in the opposite direction like a catapult and releasing their finger. I build in simple enemies the player could shoot. Player’s had to shoot enemies before they got hit by them. Trying to make this fun proved difficult. For the enemies to be a thread to the player, they always had to move towards the player. This made it really easy for players to survive, they only had to focus on enemies going towards them. Increasing the number of enemies that approached the player didn’t help much. Having 2 enemies attack at the same speed made for interesting scenarios, but as soon as there’d be three of them moving at that speed the player barely stood a chance. Due to the screen size, players only had a small window of opportunity to spot and shoot enemies. The window was extremely small when enemies approached from the sides since the game was played in portrait mode. My philosophy in game design is that any entertaining game would have to offer player’s an interesting choice over x time. The x determines the pace of the game, it can be every few hundreds of a second or every minute. The choice would probably be interesting when it’s related to the possibility of clearing a goal, scoring points or understanding more about the characters or gameworld. The only choice players had in my game was whether to shoot an enemy or not. I wanted to add more interesting possibilities. In multiplayer, movement was an interesting choice, survival depended on it. I decided it was best to reintroduce control of movement in the game to offer players more interesting choices. 

At this point in time, the new iPhone prototype of Tangatu manu didn’t even have multiplayer. I decided to drop the whole narrative idea (once again, I’ll go into that in the next developer story). I spoke to Adriaan again at Indievelopment 2014 in Utrecht. He wondered (with his affinity for local multiplayer) why I had started on a single player game on iPhone and drop the multiplayer mode from Tap Tap Shoot. I explained my reasoning: iPhone screens could be too small for 2 avatars and my assumption was that iPhone owner’s were looking to kill time on their own since it’s a personal device. Not convinced, Adriaan urged us to ‘fake' local multiplayer by taking turns shooting enemies in the current single player mode. It turned out to be a lot of fun and the screen size was not a problem. I decided to start working on a competitive multiplayer mode and to implement the possibility for moving player’s.

Indievelopment 2014 at the Zijdebalen theater in Utrecht.

The new control scheme required only one finger to both place an avatar and to shoot. I wasn’t sure if I wanted players to tap (for placement of avatar) and then tap again at the same spot to shoot (so that both placing and shooting were two separate choices) or if I’d want players to be able to shoot from the location they’re placing the avatar (one choice, but two possibilite outcomes: avatar placement and shooting). I quickly realised players wanted to be able to place their avatar and shoot directly after tapping to position the avatar. Input for this action is a tap and directly swipe gesture. This solution also matched my design rule best: players always had to feel like they were in direct control if the avatar. This definitely brought more speed and excitement to the multiplayer matches and that (strangely enough) brought some excitement to me. 

On one hand I felt bad for heading in a direction with Tangata manu in a way that the qualities of Tap Tap Shoot were totally lost. On the other hand, because of it I did learn a lot about what that quality really was. It was a fast-paced, preferably local multiplayer action game where player’s should either move or shoot. The strongest drive for player’s to keep playing was the competitive vibe of the multiplayer. I added a design goals to capture the qualities I’d want to realise with the new prototype:

  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.

It appeared my design rules helped me a lot with a lot of difficult decisions in both single- and multiplayer-modes. I would never have gotten so far if I hadn’t build the prototypes and if I hadn’t constantly reflected on the result of the changes. It’s hard to stay focussed and to switch from programmer to designer mode all the time but it does enable you to iterate on ideas much faster. As a designer, you’re never an expert of your own design until you’ve seen player’s interact with your design. I learned there are many assumptions on how things will work and what the impact of the design is on the player experience. It’s better to take two small steps in each direction before you know which step improves the kind of experience you want your game to be. My game was no longer about birdmen and this would reflect it’s new name: Should Shoot. A simple idea can often become even more simple when you learn about players’ behaviour. I will explain why exactly competition instead of story/narrative was my focus in the next part of the developer story: 'No no narrative!’.

donderdag 30 juli 2015

Prologue: It's all shit except for some golden sprinkles

All games in the AppStore are shit. It’s all copied colorful free to play crap that I wouldn’t want to play even if I’m bored to death. Alright maybe that’s not entirely true, but it is the view of a very large group that spends a lot of their time playing games. And who can blame them? Only if you’re looking real actively for the beautiful golden sprinkles in an AppStore filled with dirt left behind by gold diggers you could maybe, MAYBE find one of the excellent innovative titles that will never appear in one of the ominous top- or featured lists. I know this and I have accepted this. So why would I still go ahead and develop my game for this platform? What were my considerations? 

On the day of it’s opening back in 2008, the iOS AppStore was filled with only 500 apps. Only 500? Around 160 of these apps are games, which is actually a lot compared to the average ten to twenty titles serving as the launch lineup of a dedicated video game console. In the wonderful world of the AppStore, these are the smallest numbers you’ll find. Within days after the launch of the AppStore, stories of one-man developed apps and their financial success reached the ears of other money hungry app developers. The result was a goldrush: Already over 10.000 apps were released that year alone. It was only because Apple did not allow non-native apps in their store that it took a while before the daily submissions reached over a hundred(which it did, in 2009). Apple's native  programming language for iOS is Objective C so to be able to release a game, developers had to understand Objective C.

At the time of writing (mid-2015), over 1600 apps are submitted to the store every day. Over three times more then there were apps in the store on the day it went live! Close to 480 of those apps are games. That’s a lot! But let’s admit it: in the eyes of gamers, 99% of these games are no more fun to play then it is to poke a turd. Which is funny, because most of them are shit.

It was my appreciation for Apple’s products and the excitement of self-publish being reality that brought me to add my own turd to the shitpile of AppStore releases. Mr. Kubus is a small and colorful game released in 2010(3). It was developed by two guys: Christiaan Berger (coding, design) and me (2D art, design). The reason I’m not proud of Mr. Kubus is because it did one very, very naughty thing too many apps are still doing today: not being designed for touch-based devices. Mr. Kubus, the main protagonist of the game was controlled by BUTTONS. Yup, what a stinker. I don’t know exactly why we decided on a control scheme with on-screen buttons. Maybe it was a lack of experience in designing for touch. Maybe it was the tight production schedule (one month). Or maybe it was both of those things. 

Screenshot of Mr. Kubus gamplay.

On-screen button controls take what their name imply from the player: control. Because of the lack of haptic feedback a player is never quite sure if or when a button is pressed or released. Using  digital on-screen buttons for action gameplay on regular touch screens means the core of a happy user-experience is damaged. The effectiveness, efficiency and satisfaction of performing in-game actions are all affected by the lack of physical feedback. A port of Super Mario Bros. (1988) running on Android made this painfully clear to me one day. My Android owning friend was happy to have Mario Bros. in his pocket at all times. It took 3 deaths at the first Goomba before I realised a game of Mario had never felt so frustrating. This might be Mario in your pocket, but I’d rather have big pockets and put a gameboy in there because this was not even close to how a Mario game should play. So I learned a big lesson from both Mr. Kubus and Android Mario Bros. : Don’t include on-screen buttons in a touch game. But there had to be other ways to control action games on touch right?

Screenshot of Mario Bros emulated on Android.

A lot of action games on the App store would probably work a lot better with a controller. Many of them are in fact playable with controllers designed to work with Apple’s mobile devices. Some controllers look and feel really great (Gamevice is my personal favourite) and they support quite a lot of games thanks to Apple’s Controller framework. Some are actually  really, really great: GTA: San AndreasWalking Dead (S2)OceanhornLimbo amongst others. But these are all games we can play on our Mac, PC or console right? I considered making an iOS game that would ideally be playable with controler. Heck, I even started production of it with the talented 2D Artist Jolanda van Zandbergen. It’s called 15 Second Zombie and the art is still online as it is Jolanda's personal art project now. Production of the game ceased because of design problems and my personal lack of knowledge as a programmer for Mobile (I learned a lot about optimisation since then). I learned my greatest problem with the use of iOS controllers as a game-designer is that when you release the game, you're offering a less-then optimal gaming experience to a large group part of your audience (the ones without the controllers). Luckily I have yet to even achieve having a large audience, so that’s one thing less to worry about. (Edit: Not including Killzone 2 since it was such a big project, I consider my design influence as a play-test monitor to be very small). 

The wonderful Oceanhorn running with a controller for iOS.

One of the design problems of 15 Second Zombie was that it’s gameplay was very traditional. It was a 2D side scrolling shooter. One tip I can give you right now is to check possible competition early. Because man was I bummed when I saw any great 2D side scrolling game on iOS (Battle heart being my favourite). Now I’m thinking: what’s the point of making conventional action games for touch platforms? Especially as a small developer. The big(ger) guys will always win: they have more money to run larger productions and thus create more content. So, I decided I did not want to work on a controller based action game myself. 

A screenshot of gameplay of the canceled 15 Second Zombie project for iOS.

Are there any other games out on Mobile that do not have on-screen controls and aren’t an easy port from another platform? (And okay, I’ll admit it: Hearthstone is probably my most played game on iOS and it’s a port). There are some titles that defined iDevices as a gaming platform for me. Critter Crunch by Cappybara games was one of the earliest ones I loved and played a lot. Other favourites are: Year WalkDevice 6 (actually everything Simogo made), Fingle, Friendstrap (unfortunately no longer online), BoundenLuxuria SuburbiaMonument ValleyThrees!Ridiculous FishingBlekInfinity BladeBadlandTiny Wings and Fieldrunners. A lot of these games are great! But there’s something they don’t offer. Something many gamer's hearts are craving for. A solid headshot. Maybe not really wanting to shoot digital heads. But wanting that feeling of pride and joy when performing great, the feeling your motor skills are what keeps you in the game. The feeling of quick tactical thinking, coming up with rapid responses to enemy fire. We all know these feelings because many of us enjoy them almost on a daily basis on console. Of course I’m talking about first-person shooters. Have we ever had this feeling with a game made for touch? Personally I haven’t ever.

When I did enjoy fast-paced gameplay I enjoyed it mostly with friends. There was a time afternoons used to be about a TV, three of my friends, a Nintendo64 and a Goldeneye cartridge. We played, we screamed, we won and we lost. Good times. Why have I never yelled at one of my friends when playing an iOS game? I realised I would be proud if I could create a game like that!

There are a lot iOS titles that do not necessarily feel intense. I guess this is a good thing. It’s one of the reasons Threes! probably works so well as a mobile game. You can put the game away at any moment. The same goes for starting a game. It doesn’t take too much attention to play the game and it’s easy to start or end. There are also a lot (mainly free to play) titles that even make you feel unsatisfied on the long run. But this shallow gameplay is not inherent to the platform. The terrific Fingle made me sort of awkward or even slightly aroused when playing with others. It did not really feel intense to me, but it was a powerful experience. I think Adriaan (designer of Fingle) is a really inspiring and talented designer. His games on touch devices can spark such powerful feelings!  

This is Fingle.

I realised this once more when I was in a bar watching a group of friends and fellow game-developers play one of Adriaan's prototypes that would later develop into ‘Bam fu'. It was amazing to witness the sheer intensity with which player’s were whacking the screen. Everybody wanted to win. Badly. The prototype was controlled by large buttons on the iPad's screen. It looked similar to the released version of BAM-FU only the game-goals varried. In any case, players were motivated to press these buttons fast, and boy did they press fast. And hard! That triggered me to think about a game concept of a competitive game with a character that can shoot. The results were documented by me the moment I got home. Just look at this impressive art and 'design-document':  

‘Rocket riot'

'Putting a finger on the screen means creating a presence in the screen: a dot appears. A second finger is for shooting a rocket in that direction. Goal is to avoid other player’s rocket.'

Impressive right? Not really, I know. When I’m developing an idea or defining a concept I usually draw the most unreadable scribbles. And if there’s no paper I do almost exactly the same thing in a new Photoshop or Illustrator file. I play around with shapes and texts before anything else: Illustrator is usually my greatest design tool (but more about that with more interesting examples in the next developer story!). My frustration with the lack of solid action games on iOS, the play test-session and the conversation I had with players and Adriaan is what drove me to eventually design and develop Should Shoot. 

But why would I want to enter such a crowded market space? I don't really have a choice. I just really think there's a lot of room for innovation in touch-based game design. Also, the AppStore is filled with games made by people that don’t want to make games, they want to make money. With the risk of sounding like a hipster designer and a hint of care bear I will declared the following: I wanted to make a game because I love games and because I want there to be more games made by people who love them on mobile platforms. Care Bear Stare!