This article is an exploration of interaction. It is likely to appeal most to designers with a particular interest in the low-level mechanics of basic actions. It does not intend to set out facts and figures, rather its intent is to pose questions, provide suggestions, and present possibilities. The focus is on the abstract, where exploitation of interaction is not considered or considered only in moderation where necessary. A glossary is included in the appendix.
In this article, one button is the limitation on interaction. Using this limitation, the reader can then draw their own conclusions about how these ideas may be exploited on multi-button interaction systems.
By beginning with the most fundamental interaction, it is possible to carefully explore and experiment with it. By the end of this section, it should be apparent just how many applications there are for such a basic interaction. Whatever is discovered will be applicable to elements of most games, since they use one or more buttons. This is the basic currency of interactivity.
Let's begin with looking at our button:
Our button has two states: Pressed and released. How can this be used?
There are an infinite number of answers to this, so let's begin with some basic actions of early computer or arcade games.
All of the above might be considered actions of the Player Toy, and for the moment this will be the focus.
Taking movement as our first study, it's customary to assign multiple buttons - or as is more often the case now, an analog control - to movement, as this is usually intuitive to the Player. However, the purpose of this section is to explore the diversity of options available for manipulating a Player toy with one button. What is possible?
There are a surprising number of applications. Here are some options:
|Movement options (interactive Flash demo)|
Of course, this is not a complete list. Each possibility holds a number of sub-possibilities each of which are open to many different exploitations. If natural rules are added to the system, such as inertia, gravity, and perhaps even torque, the number of ways each can be exploited increases still further.
It is also worth noting at this stage the powerful, yet often underused, significance that time can play in interaction. In many of the examples above, holding down the button affected a continuous action over time, which is similar to applying an upward force on an analog joystick to move a Player Toy forward in the world. However, the last example is different.
The last example has two systems at work. The first part is the continuous action again: the raising (or lowering) of the trajectory based on whether the button is held down (or released). The second part is quite different. The jumping of the toy or firing of a projectile happens on release of the button. This has an important effect on the player. They will know that, once they have pressed down the button, they are committed to jumping/firing at some point in the future. With the added element of trajectory involved, there are the mechanics for a simple skill based game. This system was employed in DMA's Wild Metal Country for the firing mechanism
|Wild Metal Country|
Timing might also be used in the first three options in our table above. Let's give it a go:
Many of the same mechanisms in the movement example can be used in firing. Simple shooter systems will be looked at in this article, along with examples and variations where it is useful.
Deconstruction Note: It might be useful to think of what shooting is. From a design perspective, firing is the creation of a toy (projectile) that is positioned at the exit point of a weapon. The projectile toy is then given a direction to move in and continues moving until it hits something it is designed to read as a viable target (i.e. a meanie toy or the playfield). It can be taken for granted, but can provide our player with some original experiences by questioning what is taken for granted.
For instance: what if the projectile toy was not created at the point of firing, but was instead part of the player toy, so that the Toy got lighter as it ran out of ammunition. This could be taken even further by suggesting the player toy was entirely constructed of ammunition. What would happen when it ran out? Game over? Does the player become the last shot? What natural and supernatural rules affect the toy?
|Button state changing in action (interactive Flash demo)|
This is how Space Invaders works, except it has the further restriction (in the original version) that you will be unable to fire again until the first missile has hit something, or exited the screen.
|Shoot and release action (interactive Flash demo)|
|Shot charging (interactive Flash demo)|
This basic variation has huge consequences. In the mind of the player, a "charged shot" has invested in it time and risk. The shot is now much more important than before, and the player will be that much more intent on using it well.
R-Type used this to great effect and became a classic game which many others tried to copy.
Although some of the options above may seem more powerful, this does not mean they are better. Consideration should be given to the game as a whole. Treasure's Ikaruga, for instance, has a very simple shooting system, and its binary mode player toy really makes it stand out. Treasure knows not to overload the player with unnecessary options, and they focus on the original aspects of their design to make them really shine.
It is possible to play almost any type of game with one button, but it is rarely convenient or intuitive. On the other hand, it is also easy to get sloppy and just assign actions to different buttons because it's the quick and easy solution. Simplicity is often good, but can the product be designed in such a way where we can be more certain the player enjoys the experience of playing?
By loading the button with more than one function the player can be forced to make, and commit to, multiple actions at the same time. Actions can also be distributed over time, or even eclipse actions depending on the context.
Before looking into applications, it may be interesting to investigate how a one button interaction could work with a multi-action toy without being specific about what the actions might be. If the actions are defined abstractly as "A" and "B", what ways can the player activate them? Below is a non-comprehensive list of possibilities:
Even in this short list, there are things like context-sensitive actions, overlapping actions, actions in series, eclipsing actions and actions that are explicitly activated at the ends of other actions. Examples of how these may be exploited are given in the Appendix.
If the actions are continuous or act over time, the combinations of actions increase again. More configurations can be added by making action "A" last in proportion to the time the button is held. For instance, in possibility 4, action "A" could still be operating when the button is released for a time set by the held period. With possibility 5, the player can choose whether to overlap the functions.
The key with loading is working out what will combine naturally, and what actions you don't want to eclipse others.
Hypothesis: Consistency is more important than simplicity. How does this apply to Button Loading?
Let's look at the second possibility in our list, which is basically a toggle system. The problem with toggle systems is that they have two states, and if the player has no feedback, it would be impossible to tell which of the two actions has been performed. This is different to something like a jump button: You press jump, and you know the player toy will jump, even if you can't see it. So, although the toggle system is logical, and internally, cyclically consistent, it doesn't do the same action every time you activate it, only every other time.
An example of where this can be a problem is on flight simulators. Imagine playing a flight simulator and there is a key mapped to the lowering/raising of the undercarriage/wheels. On the instrument panel there is a button which is also mapped to the key. The button shows a picture of the wheels in a lowered (ready for landing) position. Does this mean that the wheels are currently in the lowered position? Or does it mean that when the button is pressed they will move into this position? Is this is a problem with the graphic of the button (the User Interface or UI)?
The toggle function has some blame to take in this. As a toggle system isn't explicit about its state, it is not obvious whether a player is activating one action or another. If no direct feedback is given, there is then the UI problem of distinguishing between state and potential state.
This section is all about jump mechanics
As the action of jumping is almost always performed via one button and there are so many different ways of jumping in computer games, this seems like a good place to look at some examples and maybe come up with some alternatives
What is a jump? A possible definition is: To move suddenly and in one motion. Usually jumping is thought of as an upward (and optionally horizontal as well) motion from a surface (e.g. the floor). But what of double jumps? Or jumps that push down from a ceiling? For this next list only conventional "jump from floor up and then fall from jump to floor" situations are considered.
Chances are that you will immediately identify with many of these systems. The more adventurous modern games often include many extra jump opportunities by involving other objects, such as walls in Prince Of Persia: Sands of Time.
Several new games are beginning to employ option 6 as their jump action with some interesting results. This deserves a special note: with options 6 - or any action that involves charging up – it is very important to give some visual feedback that it is having an effect. Shooters often do this with a rather attractive build up of particle effects. Jump and run games less often show sufficient feedback such exaggerated swinging of the arms and stooping posture as the jump 'winds up'.
A jump is often changed by the motion of the Player Toy before the jump and often by other control inputs when the jump button is hit. Avoiding the complexity of adding more buttons for this article and assuming that a previous action has been executed, what ways can previous actions have on the character of the jump?
Or, some more experimental ideas:
Button Loading examples
So how might button loading be used? There are a few examples in the movement section, but just using the list in the Button Loading section, how might these be used specifically? Of course, the applications are infinite really, but some examples might provide a useful illustration.
Playfield: The physical and/or logical areas of play (eg. A spooky castle)
Toy: A focal point of attention and imagination. These are the interactive elements of/in/on the playfield (e.g. A robot)
Player Toy: The player's representative in the playfield (e.g. Hero)
Meanie: A Toy that is aggressive towards the player toy (e.g. a mutant monkey)
Toy Set: The set of all interactive elements
Action: A feature of the toy (e.g. Jumping)
Activity: The result of using the toy's action on another toy or the playfield (e.g. jump over robot or up spooky stairs)
Challenge: A defined goal - by the player or designer - or objective (e.g. kill robot or get to the top of the castle)
Natural rules: Rules inherent to the environment (e.g. collision, gravity, light)
Supernatural Rules: Rules that dictate the laws and logic of the game (e.g. If Robot hits the hero, the hero will die)
[Special thanks to Gary Penn for his help with this article.]
Return to the full version of this article
Copyright © UBM Tech, All rights reserved