Drebin #1: Asynchronous Time

Drebin #1 is perhaps the most revolutionary design concept out of all of the Drebin points. It is a design innovation that applies to games that are played in real time. By taking the progression of real time and breaking it down in specific contextual ways, a new level of game design can be reached. This is the essence of asynchronous time, or async.

------------------------------------------------------------------------------

time is only relative anyway

Async fixes pacing and perspective issues by freeing the game design from a locked, singular POV. By designing a game with async, at any moment (depending on the context of the action in the game) the player can experience additional perspectives without advancing through the game time. The same thing happens in movies when the bomb is about to go off and the movie cuts back and forth between the timer ticking down and the hero making his/her escape. In most cases, if you try to count down with the timer, you'll be off by quite a bit of time. This is because the action in the movie has be desynced in order to gain the double perspective of the hero and the timer simultaneously. What's most impressive is the viewer has no problem putting the desynced images back together in their minds. Adding additional perspectives and stretching time in this way can alleviate many pacing issues with action games when it is necessary to communicate a lot of information at once.

Async fixes the stress on input timing especially for complex motion controls. Gamers today are used to hitting a button and having a corresponding action occur on the screen with practically no delay at all. When we hit the jump button, we expect Mario to be jumping. When we pull the trigger, we expect our guns to be firing. This reveals the inherent issues with buttons and action games. Because buttons are either on or off, the game waits in complete darkness until all of a sudden the button is pressed calling for some kind of action. With buttons there is no warning or heads up for the computer processing. Therefore, to maintain the sense that the player is doing the action, the majority of actions in a game activate quickly after the button is pressed to virtually eliminate the gap between the action of the button press and the action in the game.

Unfortunately, buttons have begun to display their limitations in action games. Very complex actions like Ryu Hyabusa's ninja attacks are not only activated by simple button presses, but the attack animations end very quickly. This leaves little time to add in variance and complexities to the attacks via the controller input.

Games like WiiSports and WiiFit are already proving that expanding the complexity and variance of the player inputs can create deeper gameplay experiences. Swinging the Wiimote like a tennis racket is more complex than simply hitting a button. By combining a more complex and more intuitive input method, gameplay experiences can be much richer than they would with simple button inputs.

Motion controls naturally take longer to execute. An async design can give a game more breathing room. Even in WiiSports golf, after one's swing makes contact with the ball, the power of the swing can be altered in the follow through. This mechanic doesn't obey the laws of physics, however the developers thought it was necessary to take the additional time to read data from the player's swing beyond the point where it makes contact with the ball in order to reach an appropriate level of complexity and variance. Example such as this are small steps toward full async gameplay.

Async stretches the possibilities of action and reaction. When a fast paced game is running in real time without slowing, the visual capacity and fidelity of the game becomes stressed. In the lightening fast action game Ninja Gaiden, battles can be so fast, and chaotic that players are forced to blindly attack their enemies and react to sounds. In these situations the screen becomes cluttered with increasingly more information, yet the game speeds along.

This isn't a problem for the gameplay in Ninja Gaiden Black/Sigma. After all, those games are basically last gen titles. But, I expected Itagaki to address the bad camera issues, invincible frames, and other cluttered design elements for the sequel Ninja Gaiden 2. From the looks of things, the next gen Ninja Gaiden still has all of its last gen problems. Because the series stayed true to its fast pace and button inputs, Ninja Gaiden 2 is looking dated. Swords pass through enemies, yet they can still stand and fight. The player's sword attacks don't clash with oncoming attacks. And physics, momentum, and matter don't react realistically at all. My issue with Ninja Gaiden 2, is not a matter of it not being a more realistic game. It's a matter of reducing the clutter from previous iterations. It's a matter of good game design.

There is no way for Itagaki and his team to fix such serious problems with the Ninja Gaiden series without addressing the drawbacks of the fast pace and input style. If the game's pace were slower, or even if they incorporated asynchronous design elements, Ninja Gaiden could achieve new kinds of interplay. Perhaps swords would clash, or the character bodies could react more smoothly and realistically. In order to successfully play on such a detailed level, more information and time must be given to the player. At least with async, the pace of the game can still be fairly high and achieve such a level of detail. Just imagine, Ninja Gaiden with Wii Sports quality design.

Async fixes lag online. When real time multiplayer gameplay incorporates async mechanics, the game gains the flexibility to bend and stretch time as necessary to keep the gameplay smooth and fair for all the players.

Bad internet connections happen to all of us whether it's our fault or the people we play against. When playing a game with others from around the world, the speed of their connections really matter. Some games like FPSs and other shooters opt to keep the game speed the same for each player. Unfortunately, when the information travels between all the players, some of the timing inevitably falters. I've played matches in Gears of War online where when I fired my shotgun into a wall, seconds later (after I had already moved away from that spot) I saw the bullets hit. Even though all the players in the match appeared to be smoothly running around, there were significant delays between the actions and results.

Other games simply slow down the speed of everyone's game to match the slowest player connected tot he match (Super Smash Brothers Brawl/Super Mario Strikers).

Async is the happy medium between these two options. Even with slow connections, the game can appear smooth. Yet, when the timing between two player's actions becomes important, async mechanics can be shuffled around so that the two players are interacting within the same "time" even if all of the other player are still operating on a different time layer.

At least it's not this complicated...

------------------------------------------------------------------------------

Videogames already feature design elements that play with the flow of real time. In The Legend of Zelda: The Wind Waker, hitting an enemy with an attack briefly pauses the game. The overall effect is nothing more than a more visceral, solid hitting attack.

The same delay effect can be found in the multiplayer game Super Smash Brothers Brawl. Making contact with any attack on another player causes both players to pause briefly. This effect is crucial for letting both players know that the attack connected. For attacks that are a series of rapid hits, the brief pause is extended to a small moment. During this time when both of the characters are "frozen in time," other players are free to move about in "real time." This is another example of how certain levels of asynchronous gameplay exists today.

In Drebin#1#2, I designed the versus mode with a variable about of asynchronous play. Because I wanted the players to focus on the technique of their sword strikes over the speed of the strike, I designed the versus mode to reward the player that strikes with the cleanest technique instead of the fastest strike. After the first player strikes, the second player has a small window of time to finish their sword strike. If the second player doesn't do anything, he/she loses. However, if they complete their strike within the time window, the technique of each strike is compared. If both players struck with equal technique, the faster strike wins. What is most interesting is, the small window of time afforded to the other player is determined by how fast the first player strikes. The faster they strike, the smaller window the opponent has to complete their strike.

Because the motion controls designed in Drebin#1#2 are significantly more intricate and complex than a single button input, async was necessary to keep the game focused on technique and to detract from frantic, panicked sword swings.

Async mechanics work best when there are complex inputs and a variety of information to be communicated to the player. Drebin#1#2 goes as far as possible with async due to the limitation of having no graphics. Because the versus mode is reduced to a single encounter with no on screen character, there is a limitation to how far async can stretch time. Without a visual system to communicate different effects and stages of asynchronous time, the game is stuck at layer1.

• layer 1: no graphics
• layer 2: graphics with all players sharing the same screen/audio-visual-outputs
• layer 3: graphics with a screen to each individual

In future Drebin points, I hope to reach layer2 and layer3 of asynchronous game design. It's a long and complicated process, but I feel that it is a necessary and worthwhile one.