What Elements has Taught Me as a Developer

Every game teaches me something.  Whether it is learning the actual code or the development process, it is a significant battle to find a target audience.  What does a fifteen year old want?  What does a 30 year old want?  What does a girl want to play?  What makes it fun for them?  How can I program that?  Elements answered an important question for me as a developer, in regards to controlling the game.

Flash depends on an extremely simple control schema.

Working with titles in the past such as Luminara, I have found that using the arrow keys and the mouse is borderline too much for users.  For one, anyone playing from a laptop is limited to a trackpad, which is a terrible pointing mechanism.  Unless the game focuses on a turn-based system or a schema that does not rely on time-sensitive mechanics, the best option to penetrate the largest audience for action games is the keyboard.  If using a mouse though, gestures need to be simple and intuitive.  Elements uses complex mouse gestures to manipulate the playing surface, which causes some problems for users.  The idea of the click and drag is not as simple as it would seem.  The click, drag, and rotate is even more complex without instruction.

There is a prototype method for how players will actively search to find the controls of a game.  Given that Elements will only tell you to use the mouse, a player will ignore the keyboard and try to use the mouse. Usually this will start by wiggling the mouse to look for response.  If unresponsive to the game, they will usually combine some sort of clicking with wiggling.  In Elements, clicking and wiggling will result in triggering an action on the screen but will most likely lead to a larger confusion as the game depends on extremely accurate clicking and dragging.  A random click and wiggle will make the screen go crazy, since this mouse action will rotate the entire level (and screen).  The major reaction from the game will lead to a major reaction from the player, by which the player will try to replicate what they just did.  By this time, they will be infuriated because they have spent their precious game time trying to learn a mechanic.  But as they hone their ability, control becomes more intuitive.

But for a user to learn a new game control system is unintuitive and against general video game logic.  Video games are hard-pressed this day and age to teach something, unless their very nature is to expand gameplay mechanic. Relying on previous control schemes allows a player to engage in a game at maximum proficiency without having to learn a single mechanic.  And this is the very nature of Flash games at this point; to engage a player in a fast-loading, quick-jump-into-and-play atmosphere.  So when the click-drag-rotate function of Elements came around, people were upset that it required an “unintuitive” control system.  But in reality, how else would you rotate an entire level around a ball?  Using the arrow keys would be slow and tedious, and entering in an angle manually will revert users back to a Turtle Math sort of interface.  The mouse allows the user the motor-skills necessary to generate the correct angle in the quickest amount of time.

So what this has taught me is that users do not want to learn how to control something differently; they want to engage in a game without the hassle of relearning game mechanics.

I watched this on the Armor Games site very carefully.  The bulk of first commenters on the comments section told me the game “sucked”; it was unintuitive and hard to control.  Granted these first comments were made about 3 minutes after the game was launched, so it would have been near impossible for the controls to be learned and mastered in this amount of time.  It takes nearly 30 seconds to load the game, and another 15 seconds to get to an actual gameplay scenario once through menus and instructions.

Another 15 minutes later, I started getting the next wave of comments, which were much happier and dedicated users to the game.  They opened the game and were willing to master the controls, and get the full enjoyment out of the game.  They had generally positive feedback and actually could get to the “Elements” portion of the game.

So what does that leave the developer with?  Well, it leaves a very cookie-cutter game control mechanism.  To be safe, it would be best to either use just the mouse OR the keyboard.  And not just any keyboard… using the arrow keys or WASD is crucial (but not even WASD, because I have received complaints from international developers who have AZERTY keyboard configurations which do not have a WASD configuration).  And of course, not everyone has a mouse so a keyboard would be better.  And even then what are we left with?

A game that uses the arrow keys as a primary directional control scheme, which translates to no hurdles for players.

This is what has made games like Portal so easy to get into.  Portal relies on a control mechanism that is essentially the same as a First Person Shooter, even down to the gun which is still a gun that just shoots portals.  But at the same time, Portal changes up gameplay within the FPS design, without removing the FPS control schema.  That is to say, Portal shows that innovation is not limited to a simple control scheme.  Innovation can be achieved if the player can find gameplay control that is intuitive enough to get into the game easily.

The Wii console has also achieved this victory, but from another direction.  Wii has instead taken the control schemes of normal life motions to control the game.  It is intuitive to throw a ball by rotating the arm from the shoulder, and Wii can capture this motion and translate it into a game.  Essentially, its a simulation.

In opposition, it would seem that using a keyboard or a mouse is not a real-life motor skill simulation, so why would players engage it so easily?  In essence, it has really evolved slowly over the past 40 years.  The oldest systems (such as the Odyssey or the 2600) used a knob that twisted to move a player up and down the screen.  Knobs are generally used to increase or decrease a value, such as a thermostat or speed on a motor.  So when a knob was introduced, it translated to an increase or decrease in position.  Paddles soon evolved into joysticks, which generalized motion into moving a stick left to go left, right to go right, and so on.  Joysticks flattened into a directional pad, and by that time home computers were becoming prevalent, along with the games that appeared on them.  The arrow keys provided that simple directional pad necessary to operate the computer interface.

So here we are, 40 years later in a world where computer games now make more money than music sales.  The controls are essentially the same, and people are used to how they work.  Intuition in gaming is important, if not vital to the success of a game.  In a player’s mind, first comes control, second comes the game.  If the first doesn’t settle, then the second will not even have a chance to try.

Or maybe this post should not be called “What Elements has Taught Me as a Developer”, but maybe “What Elements has Taught Me About Players.”  Players just want to play the game, and get engaged.  It’s up to the developers to aid them through this process, by allowing the player a simple setup that reinforces what players already use to control other games.  Long story short: allow for minimum friction for control translation between developer and player.