70th day of development and gameplay

One of the gameplay tests

My ride to the 70th day of development wasn’t very smooth, but I got here anyway, and now I am working on actual “playing game” part. All that I read about UX, game control and gameplay, was supposed to give me a clear idea about how the game will be played. But in my core, I am still a storyteller, not a game developer. And I know who goes where and why, how the story progresses and what character’s actions are, but I had no idea about player’s actions. I had bits and pieces, and it was time to put them together. Surprisingly, no amount of reading and researching can do this for you.

Most of the 70th day I felt like Kai, who has to spell “eternity” using ice pieces with letters “a” “r” “s” and “e”.
My pieces were:

  1. Character runs left to right without stopping.
  2. Character has to jump up on platforms to keep from falling.
  3. Character can jump over obstacles or destroy them from the distance by “firing” a weapon.
  4. Character has to destroy enemies by “firing” a weapon (enemies can’t be “jumped over”).
  5. Character has a set of elements that make the process of destroying enemies and obstacles faster or give the player a bonus.

Throwing away all the less exiting stuff like choosing a weapon or pausing a game, I am left with several actions for a player:
1.Make character jump
2.Make character fire a weapon
3.Make character fire a weapon with element augmentation (up to 3 choices)

How can you build you gameplay (and mostly — game control) with that? (And just to show off — I actually used Nielsen’s components of usability, because I have an exam next month)

Var 1. Static buttons everywhere

My draft for the first version of gameplay controls

Just put buttons on the screen. One for jumping, one for shooting and additional elements fire near shooting button.

Pros:

  • Super easy to implement for a developer.
  • Easy to learn and to memorise.
  • Unavailable elements are not present on the screen, so player clearly knows which elements are available and which aren’t.
  • Efficient — you fire it once, and you know it all.

Cons:
Cons started to jump out the moment I showed it to my dearest tester. He was very polite. “I hate this shit! I can’t hit the button and at the same time look at my character. Also, it’s uncomfortable on my big and pretty iPad!”

  • So, high amount of errors.
  • Low satisfaction — seriously, where’s fun in pushing jump button and jumping as a result?

Progression:

  • More buttons on higher levels (amount of errors rises) -
  • Increasing character’s speed as a part of the progression asks for the change in speed of background animations. Which means additional work for the developer. -

Var 2. Endless guitar hero

My draft for the second version of gameplay controls

Put elements buttons in the lower part of the screen, either with the jump button or with jumping by up swipe (gesture). Move them to the left as level progresses.

Pros

  • Adds to overall “everything moves” feel of the game.
  • Easy to learn especially if you ever played Guitar Hero.
  • Easy to implement some crazy element compilation like “push those three buttons at the same time and break your fingers in the process”.

Cons

  • Dev needs either to save all the obstacle elements before the level is loaded, or generate buttons as level progresses.
  • Takes user some time to learn how it works.
  • Buttons are in the middle of the screen, so it’s difficult to hold the device in hands and perform the task at the same time.
  • Because player always can fire a simple weapon, there should either be a static button “fire” on the screen, or it should always appear along with elements buttons (that’s confusing!)
  • Need to find a clear way to show that player doesn’t have the same element as this obstacle and has to fire a simple weapon instead (confusing again)

Progression:

  • Instead of increasing character speed just increase the speed of buttons appearing/disappearing (easier to implement) +
  • With jump button on the screen, player can try and push the “fire element” button too close to the “jump” button, so Dev has to put some work in separating “element” button hits from “Jump” button hits -
  • With jumping done using swipe, we get the mix of control elements (fire with a button, jump without the button). That can confuse player, and I personally hate it -

Var 3. Tap on everything

My draft for the third version of gameplay controls

Throw away the buttons. Swipe and tap for jump and simple fire. Tap on obstacle or enemy to fire element if player has it based on timer (kill it fast/slow or kill it with/without the bonus)

Pros

  • Easy to learn, especially if I make some visual clues
  • Efficient and memorable (just tap on enemies, what else 8)))
  • Don’t need any control buttons; that makes the experience better.
  • I can fairly easy create interesting elements combinations

Cons

  • Dev has to add listeners for a “tap” on every enemy and check if the player has necessary elements to destroy this enemy.
  • Lots of timers.
  • The player has to be aware of elements they have and don’t have, so Dev has to add some visual clues, reducing the joy from lack of buttons on the screen.
  • Lots of errors (also player probably has to put the device down to tap on the obstacle in the middle of the screen).

Progression:

  • Lessen the time for “element tap” as game progresses, instead of changing animations time and velocity +

Which way did I decide to go? Not sure yet.

I’ve implemented Var 1 and wasn’t happy (yea, all the nice words above tat my tester said were told after he checked actual gameplay with this control).
Var 2 doesn’t speak to me, probably because I am the one person in the world who doesn’t like Guitar Hero.
Var 3 is in development and if after finishing the prototype I see that it works, I’ll probably go with it.