'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!
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.
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.
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:
- The game is about competition: the sweet taste of victory or the sour smell of defeat.
- Players feel like their skill (with shooting) and tactical decisions (placement) define the outcome.
- 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!’.
