"I": Videogame's Greatest Character

I have always felt that the best videogame stories/narrative experiences are the ones that the player contributes to in a meaningful way. In this case, meaningful means through the primary mechanic of the game. What the player does between the beginning and the end of a level (or even between cutscenes) isn't filler set aside from the story. What the player plays is the story, or at least a very important part of it.

I've come up with little test you can give to anyone to determine if the game controlled the story or if the player contributed to it. Ask someone to tell you what happened in any game they recently played. As they describe the events to you, be mindful of the language they use. If their retelling is composed of sentences that begin with "I" then they are relating the events of a journey they had control over. If the sentences between with names like "Snake," "Cloud," or "Charizard" then the teller is acknowledging that there are parts of the game they felt that they had no control over.

Because videogames are an interactive medium, I greatly favor the story of "I" over the story of "insert main character here." I want to know how the player interacted with the world, characters, and story. I'm interested in how the player changes the game and how the game changes the player. When the player is merely a static liaison between cut scenes, or a silent chauffeur obediently carting the characters along until their next esoteric conversation, how can we continue to hold these games up as the best examples of videogame storytelling?

When I recount play sessions with Super Mario Brothers, I use "I" to describe all of Mario's actions. I do this because in this game, Mario does very little on his own. I grabbed the powerup. I squashed the goomba. I saved the princess. When such a close connection between myself and the story/ actions in the game exists, personal feelings and thoughts are that much easier to interject. When I tell stories about playing Super Mario Brothers, I talk about how I had to size-up the Hammer Bros by walking right up in their face. I talk about staring down Bowser tense with anticipation as he stands in between me and victory. I talk about how comboing jumps off the backs of Koopas and Goombas while moving as quickly as possible through a level feels like flying. I talk about how the level tried to trick me by putting a hidden item box right where I was trying to make a tricky jump. The conversation between me and the game that makes up my play experience is really a conversation with myself.

If videogames are to continue to be mediums of self expression, then we must acknowledge the self. With Drebin#1#2 I attempted to design a space where the player can have themselves reflected back to them. There's something about the doing, the action, the mechanic that holds a truth inside the present moments. Don't just take my word for it. Here's are some quotes from Musashi's Book of Five Rings. I believe these words resonate with Drebin#1#2.

The "spirit of the thing" is what will guide a man to his own greatness.

...only when the "spirit of the thing itself" feels comfortable with the warrior as a vehicle for its own expression.

It is very hard to explain these ideas in detail because of their intuitive nature. Once you have understood the depth of the thing you are studying, the "spirit" of all things will reveal itself to you.

When you understand yourself and you understand the enemy you cannot be defeated.

Whether on or off the battlefield, there is no difference in spirit. The warrior sees all of life as the battlefield.

Think about being seen only by yourself and not through the eyes of others.

A Drebin Point of Contention

I've been cracking away at the next Drebin point. As you may already know, the idea is to crank out one Drebin game per week. This weekly goal will ensure that my projects don't expand so large that I can't complete them, and the short turn around keeps things fresh.

I spent the larger part of this week trying to solve a programming issue with Drebin#4. I understand the program I'm using very well, and I knew that making Drebin#4 a reality would be a long and arduous task. Luckily, I was able to get a little help. Someone over at the Yoyo games/gamemaker community forums pointed me to a dll that will make all the difference in the world for this project.

If you don't know what dll stands for, and you don't want to wiki it real quick, then don't worry. I don't know what it stands for either. I just know how to use it. All you need to know is that if all goes according to plan, Critical-Gaming will get another style change and the blog will have more interesting game design points to discuss. The programming battle is over.

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.

Drebin #1#2

As you have surely noticed, the layout of the Critical-Gaming blog have changed a bit. Today is the official release of Drebin #1#2. You can Download the game here, or you can always find it under the "Downloads" section in the side bar.

What is Drebin?
Drebin is the name of small gaming projects that feature innovative gameplay at the core design. Each innovation is given a number, and each game is made with only enough graphics, sound effects, options, and modes to communicate the core idea. Ideally, each Drebin takes about a week to complete.


What is Drebin #1#2?
As the name suggests, this first Drebin features two gameplay innovations. I'll only talk about #2 today.

Drebin #1#2 is a samurai sword fighting game. Instead of going down the traditional fighting game/action game design route, I wanted to take a more innovative approach. To avoid getting bogged down with different characters, stages, attack moves, and attack animations, I decided to focus on a single encounter between two swordsmen.

Unlike in many movies, TV shows, and games where characters can take hit after hit from guns, blades, punches, kicks, and even explosions and keep on fighting, I wanted to simplify things by making Drebin #1#2 more realistic. After reading Miyamoto Mushashi's classic book of strategy "Book of Five Rings," Japanese sword fighting has given me a new perspective on what it means to fight another person. For Mushashi, the way of the sword was his way of life. And back in the days of Japan when one's skill with a sword was how one stayed alive, the way of the sword was a life or death discipline that had to be taken with the utmost seriousness.

So instead of making different characters, players in Drebin #1#2 are all equal. Instead of creating a stage or level for players to move around in, I reduced the gameplay experience so that there is no running away, and each player can only directly face each other. Instead of making a list of moves for the player to use, I only designed one attack in the game. If any of this sounds familiar to you, it should. Wii Sports and Wii Fit were designed in the same reductive approach to minimize the more redundant, cluttered aspects of the game and focus the player on the single action that is supported by the highly sensitive, accurate, and variable Wiiomte/Wii Balance Board.

The real heart of Drebin #1#2 is the emphasis on physical technique. According to Steve Kaufman, Hanshi 10th Dan, "War is mental and physical." Traditional videogame controllers haven't been addressing the physical side of things. And amateurs that design for the Wii often substitute button presses for some manner of motion control. This baby step in design hardly taps into the Wii's potential. I got around this pitfall by taking what would normally be a single button input for a sword slash, and breaking it down into four separate components.


In order to perform the single attack in the Drebin #1#2, players start by holding the Wiimote in the starting position. The game reads the accelerometer data to determine the angle the Wiimote is being held. The next two inputs are determined by the force from swinging the Wiimote forward and then down. And the last input measures the finishing angle of the Wiimote.

By breaking the attack down into four components, the game can determine the overall speed of execution and if any step in the swing wasn't executed correctly. Perfecting the swing requires practice and training much like a real swordsmen would do. Players have to master themselves in order to master the attack. Unlike grinding in an RPG or practicing combos in a fighting game, drilling the sword strike in Drebin #1#2 has the additional benefit of physical exercise.

I had originally designed the game where players had to step off of the Wii Balance Board with one leg and then strike forward with Wiimote in hand, which would have increased the level of phsical exercise significantly. Unfortunately, the Wii Balance Board was trickier to program for than I had anticipated, and I couldn't get it to work in time. Hopefully in an update to Drebin #1#2 I can include this feature.

By taking the focus of the game away from traditional controller inputs, graphics, characters, and stages, Drebin #1#2 is a game that more reflective of the player. Understanding how to execute the single attack in the game takes minutes to grasp conceptually. But mastering the strike, conquering your nerves, and being able to confidently take out any opponent can take hours of training.

Coming up tomorrow... what is Drebin #1 anyway?