Motion Control: Illusions of function

7:30 PM on 08.01.2011   |   ICLHStudios

34 comments

_{[Our first promoted blog for last week's Motion Control topic is from ICLHStudios, who brings us a very insightful and well-illustrated examination into the dissatisfaction many of us have with waggling, and offers some suggestions to make a better motion-controlled swordfighting experience. Promotions for Motion Control will continue all this week. If you want to see your blog make it to the front page next week, make sure you write something about our current topic, eSports. -- JRo]}

Like many gamers this generation I’m not a huge fan of the push for and emphasis on motion controls in modern gaming (although I'm not extremely anti-MoCo either), but for a long time (also like many gamers) I could not explain why it felt so wrong to me beyond simple declarations of dislike. Recently though, I have discovered the flaw behind the system, the fundamental problem of motion controls, why they sound like they should work but gamers almost always feel that they don’t.

The problem at hand has actually come up before in gaming, and has even been solved. Take, for example, the mechanics of jumping in a sidescrolling platformer. The standard, as used in nearly every single game in this genre entirely devoted to the joys of jumping, is a button press (separate from the movement buttons) that causes the character to jump. The jump is done immediately (or nearly so) with the absolute minimum animation time devoted to the crouch as allowed by the art style. The upward movement lasts until a certain height is reached or the jump button is released. Horizontal movement in the air is approximately the same (acceleration, traction, speed) as on the ground (although sometimes with slightly less acceleration and traction).

Allow Exampleman to demonstrate:

Back when platformers were still young (as well as, more recently, numerous flash games made by designers who most likely haven’t worked all this out or were being sort of experimental) there were many games that tried to be more “realistic” in their controls, they disallowed the ability to alter direction mid-air (which is, in case you haven’t tried it, impossible, except over really long falls where there are special aerodynamic things going on) and had either one set height that the jump always reached, or the height of the jump only effected by the how long the jump button was held before liftoff (since, like with changing direction, you cannot simply stop moving up under your own power once you already jumped).

On the surface the problem seems to be that you have to sacrifice some of the fun and severely limit what the game can get out of the mechanic in order to have some "realism". This is not true; the real problem here is that calling this jumping method more realistic is a lie. In real life a person may jump from a standing position to any specific point in range, and with the limited input allowed by video games, the standard platforming jump is actually closer the end result of a real-life jump. Whether consciously or unconsciously, platformers seem to have noticed this, and now even the “realistic” platformers just use the standard jump with slightly lower maneuverability to mask the “unrealism” of it.

Video gaming is again going through this same problem of thinking that imitating the physics of real life makes a more realistic game, instead of trying to find the best way to reach the same end result (this is one of the few cases were the end justifies the means). The problem at the moment is motion control; with sword-fighting chosen as the example (especially in first person shooters, where the problems of this philosophy are most visible, and the solution makes the biggest impact).

The current Mo-Co FPS sword-fighting method is to try and match the motions of the controller to the motions of the sword in-game, hopefully resulting in immersive gameplay where the game-sword acts as if you are holding it in your own hand and perfectly does what you intend, because in real life when you move your arm your sword moves too. Putting aside issues of lag and calibration, it still has some problems, a few of which are rather large and, in the eyes of some, potentially gamebreaking.

The main problem is that while the virtual sword may follow the movements of your hand, the reverse is not true, if your in-game sword stops on something (such as someone else’s sword, which is kind of a common thing in a swordfight) your real arm keeps going, which can cause problems since the synchronization of sword and controller is now messed up, not to mention what would happen if your in-game sword is forcefully pushed in a separate direction than your real hand (parrying, another basic part of a swordfight, does this). In addition to being unable to perform some of the most basic elements of combat, the hyper-immersive nature of 1:1 motion control means that any deviance from what the player is expecting to happen will completely destroy the immersion and fundamentally alter how the swordplay works.

I think the best solution is to use the tilt sensor and pointer functions of the motion controllers to control the swordfighting.

Witness Exampleman and his daring dueling through his eyes:

There are numerous other advantages to this method, such as the minimal movement required allows for more reaction speed than 1:1 control, using the pointer to control it avoids messing up the camera (and thus forcing some stupid lock-on for sword-fights), it allows for speed and power to be left up to the game itself (whether you want a slower, strategic fight or a fast, twitch-gameplay fight, or RPG-like stats to affect your character, I mean, imagine an Elder Scrolls game where the fighting actually had some depth to it), since the player is somewhat disconnected from the actual act of swinging the sword (but only at a level any gamer is well used to) slight glitches or inaccuracies won’t completely break the immersion, and it can be altered in many ways to match a variety of games (or weapons).

Other uses of motion controls should look at how this principle can be applied to them (not just swordfighting). Try get the input to accurately and efficiently arrive at the end result of the action (and as many of the results as possible for the simplest input) instead of trying to make a inferior imitation of how it works.