Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
One Button Games
Long-time game designer Green discusses game design mechanics with when 'one button is the limitation on interaction', using Flash-based interactive examples to flesh out some surprisingly extendable, innovative gameplay ideas using limited controls.
26 Min Read
Introduction
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.
Movement (the Player Toy's movement around the playfield)
Attacking (the execution of an aggressive move or construction and deployment of a projectile)
Activation (a change in state of one or more Toys or playfield elements)
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?
Movement
There are a surprising number of applications. Here are some options:
Option #1
Player toy experiences gravity.
Player toy collides with ground.
Player toy jumps (to fixed height) when the button is pressed.
Option #2
Player toy moves to next fixed position each time the button is pressed.
Option #3
Player toy moves forward a step when the button is pressed.
Player toy rotates when button is not pressed.
Option #4
Player toy occupies position B when the button is pressed.
Player toy occupies position A when the button is not pressed.
Option #5
Player toy moves forward continuously when the button is not pressed.
Player toy stops when the button is not pressed.
Player toy rotates when the button is not pressed.
Option #6
Player toy moves down continuously when the button is not pressed.
Player toy moves up continuously when the button is pressed.
Option #7
Player toy moves forward continuously regardless of button state.
Player toy rotates counter-clockwise continuously when the button is not pressed.
Player toy rotates clockwise continuously when the button is pressed.
Option #8
Player toy experiences gravity.
Player toy collides with ground.
Player toy lowers trajectory when the button is pressed.
Player toy increases jump power when the button is pressed.
Player toy jumps to fixed height when the button is released.
Player toy jumps horizontally with speed proportional to button held time when the button is released.
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
Timing might also be used in the first three options in our table above. Let's give it a go:
Option #1b
Player toy stops when the button is pressed.
Player toy jumps to a height which is proportional to held time when the button is released.
Option #2b
Player toy selector cycles through positions with highlighter when the button is pressed.
Player toy jumps to selected position when the button is released.
Option #3b
Player toy stops rotating when the button is pressed.
Player toy jumps forward in proportional to held time when the button is released.
Player toy rotates continuously when the button is not pressed
Attacking
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?
First the most basic system of all: The event of the button changing state (from released to pressed) triggers the shot. The player has to release the button in order to fire again. In other words, the duration that the player holds down the button has no effect. The event (firing) is triggered only when the button goes from released to pressed.
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.
A slightly more advanced interaction would be the auto-fire ability. In this situation, the character on screen will continually shoot while the button is pressed and will stop firing when released. This is how Ikaruga and many other shooters work. It is a simple system that has an impressive visual effect, and focuses the play experience on the Player Toy movement, rather than the accuracy of shooting.
The next step is to change the effect or power of a shot in proportion to the time the button is pressed and consequently, the shot would only fire when the button is released. This might be called a "charged shot", as the analogy is that the time spent holding the button down is the action of channeling power into the shot over time.
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.
Any attribute could be selected to vary with time, rather than just the power of shot. The spread of fire could be varied. With this system a short tap might produce a wide, weak shot and a held button might produce a tight, focused, powerful shot. Perhaps the mode of shot could be changed entirely in discrete stages. A tap could be a simple low power shot. Held for longer and then released, it might split into three shots. Held longer still, it could invoke homing shots. There is a great deal of variety to be found in trying out different approaches.
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.
Button Loading
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:
Press Button = Activate "A". Release Button = Activate "B"
Press then Release Button = Activate "A". Press then Release = Activate "B" then cycle back to "A"
Press Button = Activate "A" and "B"
Hold Button = Activate "A". Release Button = Activate "B"
Press then Release Button = Activate "A". Hold Button = Activate "B"
Press Button = Activate "A". hold Button for more than N seconds = Activate "B"
Press Button in situation X = Activate "A". Press Button in situation Y = Activate "B"
Hold Button for less than N seconds = Activate "A". Hold Button for longer than N seconds = Activate "B"
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.
Considerations
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.
Jump
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.
Jump systems:
Press Button = Jump to fixed height and drop to floor. Release Button = N/A (Manic Miner, Chuckie Egg, Donkey Kong)
Press Button = Jump to fixed height. Release Button = drop to floor. (unknown)
Press Button = Jump to fixed height. Press Button again = Jump to extra height – “double jump”. (Devil May Cry, Lego Star Wars)
Hold Button = Jump and continue to add upward thrust with diminishing returns until maximum jump height is reached. Release Button = cancel upward thrust resulting in smaller jumps. (Most Mario games, James Pond)
Hold Button = Jump and continue to add upward thrust with diminishing returns until maximum jump height is reached. Release Button = drop immediately to floor. (unknown)
Hold Button = Build Jump power. Release Button = Jump up and/or across proportional to power. (Spiderman, Bugaboo the Flea)
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?
Horizontal movement is carried over into the jump.
If the previous position was a duck/crouch the jump is higher
If the last action was a jump and the Player Toy landed less than N milliseconds before then jump higher (somersault with third consecutive jump – Mario 64)
If the last action was a jump from the ground, jump again from current position: “double jump”.
If the Player Toy was shooting, the jump becomes a somersault to maintain target lock and dodge projectiles.
Or, some more experimental ideas:
If the Player Toy is locked on to an object or – if a First Person Shooter game – the view is centred on an object then automatically jump to that object or intercept it.
If the Player Toy is locked on to an object or – if a First Person Shooter game – the view is centred on an object then jump in an arc over the object maintaining distance.
If the Player Toy is rolling along the ground the Jump with more horizontal force than normal.
If the Player Toy is running the Jump distance is influence by which frame of the run cycle the Player Toy is in when the button is pressed.
Player Toy jump height is proportional to how many meanies are attacking at the moment the button is pressed (similar to Bangai-O's special attack)
Appendix
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.
Possibility 1. (A) as a primer for (B) which can't be canceled once begun. This might be useful for loading a weapon: drop empty magazine (A), load new magazine (B). While in most situations you may want (B) to follow (A) immediately, by separating the actions you can allow new situations to develop without hindering or confusing the player. Examples: (A) stop (B) fire, (A) drop guard (B) kick, (A) duck (B) jump.
Possibility 2. This is really a toggle system. It might be used to raise (A) or lower (B) an undercarriage for a plane, or lock (A) unlock (B) a car door. Ikaruga uses this system to switch modes of the ship. If A continues acting for a period of time B can be used to augment it, e.g. (A) = jump, (B) = Double jump. This makes it much more than a toggle system and introduces the rule: B only comes into action if A is running.
Possibility 3. Activating 2 actions at the same time will have the effect of making it seem as if it's just one action, depending on the application. If the actions are different enough it will probably be more useful to have the option to activate them separately, however this is still an option so what can it be used for? What if (A) is a speed modifier (turbo) and (B) is some sort of force field? This forces the player to be less at risk when moving quickly. How about if (A) is a forward roll and (B) is drop a bomb?
Possibility 4. In Wild Metal (Country), the Space bar is used to raise the gun turret (A) and when released the turret fired a shell and the turret lowered (B - combined action, fire + lower). A simple, elegant system there. In Prince of Persia: Sands of Time (A) is the action of wall running, and a few games will have (A) as a target lock system. In these last two examples (B) is just the action of canceling (A), but how might these games change if (B) were assigned a function? What action might be appropriate? And how might it affect the rest of the game and the level design?
Possibility 5. Does (B) eclipse (A): that is to say, if (B) is activated does the (A) action cease? An example of this would be if (A) is jump, and (B) is drill down. In this case activating (B) might have the effect of immediately dropping the character out of the air to drill. In this case, it is unlikely that (B) should always to follow (A). (B) would activate only if (A) was active. If (B) doesn't eclipse (A), (B) could be used to augment (A), for instance if (A) is jump and (B) is glide. Possibility 5 is a variation on Possibility 2, but in this case there is more control over action (B)
Possibility 6. Again there is the option of eclipsing (A) with (B), however, here (A) can be triggered many times before choosing to activate (B). It also means that the player has to activate (A) in order to activate (B). (B) also has a specific time cost which could be used to push the limits of the players skill and timing. With this system it isn't usually intuitive if (B) eclipses (A) unless (B) could be seen as an enhancement to (A). The reason for this is that the state of the button has not changed, so the action should not change. (B) might be best used then as an augmentation, or enhancement to (A). If (A) is a jump action again, (B) might be shield activation, or activate rocket pack. If (A) is firing a shot, (B) might be fire a more powerful shot, or fire a different kind of shot...
Possibility 7. This context sensitive action is quite a common device and is used heavily in Conker's Bad Fur Day. Typically a player toy will have an "action" key assigned to it which triggers different actions in specific places which are marked on the playfield. It is also used in combat systems to change the type of attack depending on factors such as relative positions (and attitudes). Or it can be based on rule conditions, such as: Player Toy has Ball then (A) = kick ball; Player Toy doesn't have ball then (B) = tackle. It could be argued that this is not a very consistent system, especially when based on playfield location, but really this depends on the type and scope of actions. This possibility encompasses many of the others as context can also be button state and/or time eclipsed.
Possibility 8. When the button is pressed, the player is committed to action (A) or (B). But in this case (B) could be do nothing, in which case, there is an unusual decision for the player: If quick action is needed, they must decide whether to activate (A) so that another action can be performed, or cancel (A) by selecting (B) which costs time. If (A) costs resources other than time, this immediately puts the player in a dilemma. A simple example: (A) is shoot, (B) is cancel. The player is faced with a target to shoot, as they press the button, the target covers itself with something valuable to the player. At the same time another hostile target appears. The player has a number of options: 1. shoot the valuable and then both targets, 2. Cancel and then shoot the new hostile target (risking that in that time they don't get shot themselves), 3. try and line up with the hostile target and fire before the switch to (B) happens. (B) can also be an enhancement of (A) which will give us a simplified version of the R-Type firing mechanic seen in the last interactive example in the section on attacking. This system can also employ eclipsing and layering of action (multiple actions happening at the same time) depending on how long actions (A) and (B) take to complete.
Definitions
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.]
Read more about:
FeaturesAbout the Author(s)
You May Also Like
.jpeg?width=700&auto=webp&quality=80&disable=upscale)
