Game Design case study: Taptap Kidnap PART – II (a.k.a. touch me in the right places)

~PACKING UP AND STARTING THE JOURNEY~

(a.k.a. Let’s Get the Show on the Road)

In part-I here, I have discussed why I decided to make an action-oriented mobile game (Taptap Kidnap),  and how I decided to tackle shortages of touch-input controls to make a crazy fast game playable and enjoyable. It boils down to the idea of designing the game around the restrictions and advantages of touch controls. So right now and right here, I will list them as a convenience.

The Good:

• Touching something with your finger is much more natural and accurate then pointing and clicking with a mouse.
• You have five fingers per hand, which means more actions per minute (APM), along with the abiliy to touch multiple objects at once.
• You can use gestures.

The Bad:

• The hand covers some portion of the screen, reducing visibility.
• There is no “right click”. There are alternatives, but none of them are as efficient.
• There are no other “button” input sources (with mouse, you have keyboard. Gyro or voice input is not as efficient and/or accurate.)

The Ugly:

• To remedy screen-coverage problem, you can lean towards a tap-based play which
  would remove “the good” of using gestures.
• Leaning all towards gestures like swipe and drag would reduce the number of actions per minute, and cancel “the good” of high APM.
• Players usualy hold the device in one hand and play with the other, cutting the potential to half.

This list was my guide when I was designing the game, even before I thought of a single mechanic, visual, or story element. Now that I had a starting point, I could filter my ideas accordingly. With my path now visible, I decided to move to next step: foundation of base gameplay.

~FINDING THE RIGHT MECHANICS~

(a.k.a. THE PUNISHMENT OF SISYPHUS)

This part is arguably what makes or breaks your game. It’s the core, the heart of your creation. Since you want to  make the best game ever, it is very hard to be satisfied with your game mechanic ideas. There is always one step forward, and if you don’t restrict youself, you end up with a Massively Multiplayer Online First-Person-Shooter Roleplaying Game with a procedurally created open world that plays at 60 fps on mobile devices.

This is also where you either clone an idea with the hopes of adding something new to it, or create a new mechanic alltogether. On one hand, the market is full of shameless clones of popular games, on the other hand, coming with a new good mechanic is both hard and risky.

Bottom line is, this part is the hardest if you are taking the process seriously; it is an endless inner struggle where you try to muster your imagination powers with hopes to balance out an uncountable number of variables. You must make your game accessible to casuals but also appealing to hardcore gamers. You must come with good, innovative ideas but also fulfill to industry norms. You must keep an eye on performance as mobile devices, even with all the progress in their technology, are still behind other gaming mediums. You must make it complex but not complicated. It should be new and exciting yet still intuitive and accessible. The vital point is that all this stuff is based on your core mechanic. (That’s why it’s called “core” I guess, duh!)

Not only that, but you must also keep in mind what we discussed before: the design of the core mechanic according to strengths and weaknesses of the input method.

Yes… This  is the Sisyphus’ punishment, at it’s full glory.

A game developer (representational)

~THE CORE EXPOSED, FIRST CODES WRITTEN~

(a.k.a JUMPING INTO A PIT OF LAVA WITH A CONCRETE PARACHUTE WITH HOLES, AND A WEIGHT CHAINED ON YOUR FEET, WHILE CLOUDS OVER YOU RAIN DOWN RADIOACTIVE ZOMBIE PIRANHAS – AND YOU ARE NAKED)

At the time I was contemplating about all these things, a very dear friend of mine (also part of the team now) was sharing his ideas about making small mobile games for children. He was talking about very simple mechanics like painting still images, teaching colors / seasons / vegetables, and popping baloons that would leave behind candies to collect. I wasn’t buying the idea, I was a hardcore gamer and the idea of child’s play was so below me that I didn’t even want to give %1 cpu power from my mind into these. So I gave them %0.5, and suddenly a lightning struck.

This video represents the situation perfectly; with me, my friend, and the idea…

This was it. During a skype conversation with a great friend I had the first idea of what to do. He was kind enough to listen and give his encouragement.

Basically, I had decided to go with a tap-heavy action game, in which player success would be based on keen observation, a little bit of imagination power, and good reflexes. The idea was to free imprisoned little men from kidnap orbs that were ascending the screen. A tap would free them, and the player would get some score, but as time went forward, more and more orbs would come, moving faster and faster. Players focus was to be drawn to these orbs moving rapidly upwards and if they couldn’t catch one before they floated off, they would loose a life. This was the first part of the core mechanic and it was as simple as it could get; so barebones that it barely resembled anything more than a childs game. I would never have settled with such little. Some games like flappy bird did so, and achieved greatness, but this could never be my path.

But it adhered very well to “the good, the bad and the ugly” filters I discussed before, so without a beat, I introduced the second part of the core mechanic: some orbs were actually traps, and instead of little men, they would spawn bombs. If the bombs fell down the bottom, player would loose a life. This time, players attention was to be drawn towards objects that moved downwards. Their overall observation was to be split into two: catch the orbs that go up and catch the bombs that go down.

In a couple hours I made the first prototype, orbs were moving up, a tap was freeing the little men inside, and each orb had a %10 chance to spawn a bomb. A tap on the bomb was giving it a nice upwards jolt, creating a game where I could juggle them with taps. After some quick polishing, “testAlpha01” was born.

So here it is. The idea was a small fish hiding very deep; none of the webs I would cast to the sea would have caught it if werent for my friend. (He is a mad scientist/academican and works on chemistry) In the next chapter,  I will talk about secondary mechanics and what I meant by “polishing” them.

Till then, stay safe, and see you around.