作者：Yoann Pignole

这两种相异的感觉却存在相同的问题：缺乏对玩家输入的反应性，以及缺乏准确性。

在此我的目标是帮助新手游戏设计师（或者更有经验的设计师）避免此类控制问题。但要记住，设置具有反应性和准确的控制方式并非义务，也并不适用于所有玩法。

现在让我们谈谈产生这种感觉的普遍原因：

优先的动画

原版《波斯王子》、《Another world》和《暗黑之魂》有何共同点？没错，就是优先于玩家输入而出现的玩家动画。如果这3款出色的游戏以这种约束条件创造玩法，也许它就不会是你想要的“响应性”游戏了。

当动画“优先”时，玩家就不可能在其他动画仍在运行的情况下执行某些操作了：

所幸这种情况很容易避免：赋予玩家输入的完全优先权，即便这会中断角色动画。

对富有经验的设计师来说，这个问题也许是显而易见的，但提醒一下总没有坏处的。

低地面摩擦

我所谓的摩擦是指当玩家松开手柄时，在角色相反方向作用于角色速度的力量，直到角色停止。

没错，拥有小小的地面摩擦很好，带有美丽的破坏动画时尤其如此。但当你的玩家需要0.5秒才能完全停速时，这真的太漫长了。

除了针对冰面平台或滑板角色，设计师要慎用低地面摩擦力，不要对此犹豫。

改变方向时没有反应

如果你使用经典的系统来移动地面上的玩家，使用奔跑加速，最大速度以及摩擦力来停止，可能在突然改变方向时就会注意到一个从未料到的结果：玩家并没有反应，并且需要一些时间转弯。

让我们以2D平台游戏为例。其每帧速度计算速度为：

speed = speed + acceleration (当然有最大速度限制！)

如果玩家给予“正确的输入”，其加速就会是积极的，速度也会以积极方式增加，以便角色正确移动。

但如果玩家突然来了个“向左输入”，现在的加速就是消极的，并且速度会逐渐从积极向消极减少，玩家会逐渐减速最终转向左边。其机制如下：

现在，解决方案是什么？实际上很简单：你只要使用“响应性比例”。

我所谓的“响应性百分比”是一个当玩家针对实际速度的相反方向给予输入时的额外加速比例：

If input direction opposite to actual speed direction
speed = speed + acceleration + acceleration * reactivityPercent
Else
speed = speed + acceleration

如下图：

这个方法也适用于3D环境，只需要进行一点小调整，令方向与原方向相反得“更多或更少”。其理念是为这个加速百分比分配一个比率，这与“相反量”有关：

oppositionPercent = opposition ratio between input and actual direction (0 is the same direction and 1 the complete opposite)
speed = speed + acceleration + acceleration * reactivityPercent *oppositionPercent

模拟摇杆上的非模拟速度

有些游戏会使用2种速度值，通常一个用于“行走”，一个用于“奔跑”。

这在8位和16位主机（拥有控制移动的方向十字架）上是个显而易见的解决方法（游戏邦注：在默认状态下，玩家是行走状态，如果摁住按钮就会奔跑），但在现代衬垫的模拟摇杆上却并不合理：你的拇指移到摇杆上就是前进，你当然也会对前进速度有所期待。

只有2个值的模拟摇杆并不总是会产生“僵硬”之感，但如果这些值相差甚远，玩家就会觉得这中途“阻碍”摇杆。

摇杆速度非常容易设置，因为多数商业游戏引擎每条轴线都有-1到1的值。所以，你可以设置一个“最大化”最大速度来确定你当前最大速度（游戏邦注：最大速度就是当你的摇杆处于全左/右状态之时）：

currentMaximumSpeed = MaximumSpeed * AnalogStickRatio

以同样方式来考虑调节加速的问题总是个好主意。

低重力

带一点点过低重力值可以让你获得一种软弱无力的控制感，就好像你的角色是一片羽毛或者身处月球一样。

这也许是种选择，但有时候，设计师会降低重力以便削弱平台挑战性。要记住这一做法可能让你失去“重量感”，而这正是在平台挑战中获胜的重要元素。

没有调整空气控制（空气中的加速）

空气控制（在空气中向水平方向移动玩家）是一种根本不现实的东西。但现实感的行为在电子游戏中并不总是有趣的，对于拥有跳跃挑战的平台游戏来说，你可能需要一点空气控制。

如果说地面上的加速参数一定要小心调整，那么空气加速就更是如此了（因为玩家处于下坠状态，没有足够的时间作出反应）：

*过低的空气加速过程中玩家没机会更正自己在空中的轨道，他会产生一种沉重感。

*过快的空气加速将让玩家难以估量情况。

很显然，低空气加速将极增加高重力值的“重量”感，而高空气加速则会产生低重力的“飘浮”感。

所以，重力和空气加还应该一起考虑和进行调整。

但是，要注意不要一直用高空气控制来“补偿”高重力，反之亦然。有时候最好是保持这两个值的一致性。不要忘了“极端”值可能会产生拥有强大特征的出色游戏。

非模拟跳跃

非模拟跳跃解决方法，例如没有任何调整可能性的跳跃重量，经常在现代AAA游戏中出现。首先，让我们先明确我所谓的模拟跳跃机制与非模拟跳跃机制之间的区别：

在AC或GTA系列等游戏中，非模拟跳跃并不是一个问题，因为它们关注的并非跳跃挑战，并且其游戏追求的是一种“真实感”情绪。但是，在以“跳跃为中心”的游戏（游戏邦注：例如《超级食肉男孩》、《马里奥》或《Sonic》系列）中，能够在空中“切断”跳跃却是成功完成某些挑战（例如在带有尖角的天花板下跳跃）的关键。除此之外，这还有助于产生一种响应性控制之感。

执行一个模拟机制可能有点棘手。作为设计师我的一个解决方法是来自《Sonic》的一个启发：似设你使用一个冲击速度来跳跃（让角色以重力操作一步步后退），其理念是定义“切断跳跃速度极限”，以及假如当玩家松开了输入操作，垂直速度超越了这个极限，那就将垂直速度设置为与该极限相同的水平。如果该速度低于这个值，这就意味着角色已接近于后退，那就没有必要减少“直接”的跳跃速度。

当然，你将需要一些尝试才能找以“切断跳跃速度极限”的优秀值。因为该值与你的重力相关，对我来说，“重力/10”的值甚为管用：

cutJumpSpeedLimit = gravity / 10

If isJumping and jumpInputReleased and verticalSpeed > cutjumpSpeed
verticalSpeed = cutJumpSpeed

无耐性的跳跃调用

你希望自己的角色能够只在着陆的时候才跳跃。但如果你严格使用这个条件，可能就会产生一些缺乏反应性的感觉。的确，如果玩家在角色触碰到地面时每隔几帧就调用一次跳跃（这种情况经常发生，因为人脑的期望总是大于行动），该调用就会无法及时生效。同样，如果玩家想在角色磅到平台末尾时跳跃，他可能就会在角色开始下落时迟了几帧才回应。

玩家的意识会让他觉得自己能够跳跃，即使这在技术上并不现实。

为了避免这种情况，我们可以采用增加“容忍度”的方法，这意味着：

*当玩家给予输入以及角色接近地面时，就会登记一次跳跃调用。所以，当角色接触到地面时，他就会再次跳跃：

*当角色从一个平台降落时，如果玩家给予一次输入时他还有一次时间延迟，可以在空中跳跃：

跳跃无能

当你的输入在屏幕在出现一个直接结果时，就会产生“高反应性”之感。这看起来很显然，但在玩《Skylanders Swap Force》时，我惊讶地发现自己在跳跃时无法攻击：没有任何动画或声音反馈，在空中时摁下按钮就是没有反应。

在平台游戏中，跳跃就是你常用的主要能力以及移动方式。所以，在跳跃过程中禁用任何其他功能一定要慎重考虑。尤其是在动作阶段需要这种能力时（就像在混战游戏中的攻击能力一样）。

如果你真想在空中禁用动作，最好是使用一些声音、特效或动作反馈这种不可行。

圆角平台边缘（光滑的边缘）

在某些游戏中，所有平台都有圆角。这种设置的原因有很多种，其中一个普遍原因就是避免角色因“压缩”碰撞机而卡在棱角边缘中。

像Unity 3D等许多易用性的游戏引擎，使用这种“压缩”碰撞机加上其物理引擎来处理碰撞效果。所以，很多开发者会使用这种简便而快捷的方法来避免“卡住”问题，以免应对棱角边缘。

实际上：如果你的游戏并不是基于跳跃挑战，并不需要高度准确的移动，那就可以使用这一方法。但如果你想制作类似《马里奥》这种极具跳跃要求的游戏同，那就应该避免圆角设计：因为这可能令玩家在到达平台边缘的时候非常抓狂，让他们觉得自己好不容易在平台着陆了，但最后却因为一个几乎看不见的圆角而跌入虚无中。

视觉和声音反馈

没错，反馈很重要，甚至是在原型过程中。

我是在制作某一个人项目过程中意识到平台游戏中反馈的重要性：即使运用了以上所有其他“原则”，我仍然觉得游戏存在一点软弱之感。我试图调整变量，修改移动系统等等，但一切均无济于事。最后，我努力搜索并决定开始编写一个声音管理器来“放松”，我最初添加测试的声音是跳跃声。这样我意外地发现我的角色更具响应性了！我决定继续这一做法，并植入与角色速度相关的奔跑动画速度：游戏看起来获得了更多反应性！

这个故事只是为了说明，即使你懂动画，声音或特效应该在开发后期再考虑，也还是需要这些元素来“实质化”速度、移动或重力等某些理念概念。因为平台游戏涉及对特定物理机制的了解，我认为很有必要在调整移动变量之前植入占位符反馈。

结论

当然，本文只是我个人的主观看法，游戏设计并没有什么不可变通的准则。游戏设计师的职责并非恪守“理论”，在我看来，这一工作的职责除了上述内容之外，还包括创造理念的原型、测试原型，再制原型等，直到找到“趣味”元素为止。如果你想设计一种需要大量反应性和准确性的游戏，但却没用运用到本文的建议，那也无妨，只是一定要确保你的原型具有可行性。

最后，我要以自己的游戏设计黄金准则来总结此文——游戏设计并没有什么黄金准则！（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Platformer controls: how to avoid limpness and rigidity feelings

by Yoann Pignole

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

Paradoxically, it’s often the same problem behind these 2 feelings: a lack of reactivity to the player’s inputs and a lack of precision.

My goal here is to help novice game designers (and maybe more experienced ones) to avoid this kind of control feelings if they don’t want it. But keep in mind having reactive and precise controls is not an obligation and won’t work for all the gameplays.

So, after this little clarification, let’s talk about the common reasons which could, in my mind, contribute to this feeling:
Priority to animations

What the first Prince of Persia, Another world and Dark souls have in common? Yes: the priority to player animations before the player’s inputs. If these 3 great games build their gameplay with this constraint, maybe it’s not what you want for a “reactive” game.

For more details, when animations have “priority”, it will be impossible for the player to do some actions while another animation is still running:

Hopefully, it’s very simple to avoid: give full priority to player’s input, even if it cut your character animations.

This issue may appears as obvious for experienced designers, but always good to remind it!
Low ground friction

What I call friction is a strength applied on the character speed, when the player releases the stick, on its opposite direction, until he’s stopped.

Yes, having a small ground friction is very cool, especially with a beautiful breaking animation! But when your player takes 0.5 seconds to stop at full speed, it’s most of the time too long!

Except for ice platforms or for a skateboarder character, be careful with too low friction on the ground and don’t hesitate to increase it.
No reactivity when changing direction

If you use a classic system to move your player on the ground, with run acceleration, maximum speed and friction to stop itself, maybe you noticed a result you didn’t expect when you suddenly change direction: the player is not reactive and needs some time to go the other way.

Let’s explain with a 2D platformer. The speed computation each time laps is:

speed = speed + acceleration (with a maximum speed limitation of course!)

If the player gives a “right input”, the acceleration is positive and speed increases in positive à the character moves right.

Now, if the player gives suddenly a “left input”, the acceleration is now negative and speed progressively decreases from positive to negative à the time the speed takes to move from positive to negative, the player slows down progressively to finally go left. With a little scheme :

So, now, what’s the solution? Actually it’s pretty simple: you just have to use a “reactivity percentage”.

What I call a “reactivity percentage” is an extra percent of acceleration when the player gives an input in a direction opposite to the actual speed:

If input direction opposite to actual speed direction
speed = speed + acceleration + acceleration * reactivityPercent
Else
speed = speed + acceleration

And with a scheme :

This solution can be used in 3D environment too, with a little modification as a direction can be “more or less” opposite to one other. The idea is to apply a ratio to this acceleration percentage, relating to the “amount of opposition”:

oppositionPercent = opposition ratio between input and actual direction (0 is the same direction and 1 the complete opposite)
speed = speed + acceleration + acceleration * reactivityPercent *oppositionPercent

Non-analog speed on analog stick

Some games use 2 values of speed, often a “walk” and a “run” one.

If this solution was evident on 8 and 16 bits consoles with a directional cross to control movements (by default, the player walks and, holding a button, the player runs), it seems not logical with analog stick on modern pads : as your thumb move on the stick is progressive, you expect a progressive speed too.

Having only these 2 values with an analog stick don’t always result with a “rigid” feeling but, if the values are too far from each other, the player will feel this “step” at stick midcourse.

Analog speed is quite simple to implement as most of commercial game engines have a -1 to 1 value for each axis. So, you can determinate your current maximum speed setting a “maximum” maximum speed (the maximum speed when your stick is all to the right/left):

currentMaximumSpeed = MaximumSpeed * AnalogStickRatio

And it’s always a good idea to think about modulate the acceleration the same way.

Low gravity

Having a little bit too low gravity value can definitively give you this feeling of limp controls, like if your character was a feather or was on the Moon.

It can be a choice but, sometimes, designers lower the gravity to make the platform challenges easier (or keep the Earth default one, 9.81m/s, not adapted to their objects dimensions). It’s a possibility but keep in mind you risk to lose the “weight feeling”, which is paradoxically important to succeed in platforming challenges.
Air control (acceleration in the air) not tweaked

Air control (ability to move player on the horizontal plan in the air) is something not realistic at all. But realistic behaviors are not always fun in video-games and, for a platformer with jump challenges, you’ll probably need some air control.

If acceleration parameter on the ground must be carefully tweaked, it’s all the more true for air acceleration (because the player is falling and don’t have all the time in the world to react):

Too low air acceleration won’t give player a chance to correct his trajectory in the air and he’ll have a feeling of “heaviness”.

Too fast air acceleration will be tricky to measure for the player

And, obviously, low air acceleration will multiply the “weight” feeling of a high gravity value and a fast one the “floating” feeling of a low gravity.

So, gravity and air acceleration should probably be considered and tweaked together.

However, be careful to not always “compensate” high gravity with a high air control and vice versa, sometimes it could be better to keep consistency between the 2 values. And don’t forget “extreme” values can lead to great games with strong identities:

Non-analog jump

A non-analog jump solution, namely only one jump height without any possibility of modulation, is frequent, even in modern and AAA games. First, let’s be clear on what is the difference between what I call an analog jump mechanic and a non-analog one:

In some games, like AC or GTA series, it’s not a problem to have non-analog jumps, because they’re not focused on jump challenges and the game want to keep a “realistic” mood. However, in “jump-centric” games (like Super Meat Boy, Mario or Sonic series), being able to “cut” your jump in the air is essential to succeed in some challenges (like jumping under a spiked ceiling). In addition, it contributes to have a feeling of reactive controls.

Implementing an analog mechanic could be a little bit tricky. My solution as a designer is directly inspired by the one used in Sonic (thanks to the “Jump velocity” part of Sonic Physics guide): assuming you use an impulsion speed to jump (letting the character falling back step by step with the action of gravity), the idea is to define a “cut jump speed limit” and, if the vertical speed is superior to this limit when the player releases the input, set the vertical speed equal to the limit. If the speed is inferior to this value, it means the character is close enough to fall back and it’s not necessary to decrease “directly” the jump speed.

Of course, you’ll need some tries to find the good value for the “cut jump speed limit”. As the value is linked to your gravity, for me a value of “gravity / 10” worked well:

cutJumpSpeedLimit = gravity / 10

If isJumping and jumpInputReleased and verticalSpeed > cutjumpSpeed
verticalSpeed = cutJumpSpeed
No tolerance for jump calls

Naturally, you want your character to be able to jump only when he is grounded. But if you strictly use this condition, you will probably encounter some lack of reactivity feelings. Indeed, if the player calls for a jump a few frames just before the character touches the ground (and it’s often true, because the human brain tends to anticipate too much the action), the call won’t be considerate. The same way, if the player wants to jump when the character reaches the end of a platform, he may reacts just a few frames too late while the character just start to fall. Clearer with a little scheme:

The perception of the player can make him think he was able to jump, even if technically it’s not true.

To avoid this perception, the solution is to add a “tolerance”, which means:

A jump call is registered when the player gives the input AND the character is close enough to the ground. So, as the character touches the ground, he will jump again :

When the character falls from a platform, there’s a time delay during which he can jump when in the air if the player gives the input :

No abilities when jumping

The sensation of “high reactivity” appears when having an immediate result of your inputs on the screen. Yes, it seems obvious but, playing Skylanders Swap Force, I was surprised to be unable to attack when I was jumping: no animation or sound feedback, just no response to the attack button when in the air.

In a platformer, jump is your main ability and way of moving and you will use it very often. So, forbid any other ability while jumping must really be carefully considered. Especially if this ability is needed in action phases (like the attack ability in a melee fight based game) !

If you really want to forbid the action in the air for any good reason, it’s always a good idea to feedback this impossibility with some sound, FX or animation.

Round platform edges (slippery edges)

I some games, all the platform have round edges. There a lot of reasons to do that but a common one is to avoid the character “capsule” collider to get stuck on right-angled edges:

A lot of accessible game engines, like Unity 3D, use this kind of “capsule” collider to handle collisions with their physics engine. So, it’s very tempting to use this easy and quick solution to avoid the “stuck” issue instead of dealing with right-angled edges.

Actually, it’s not necessarily a bad solution: if your game is not based on jump challenges and don’t need high precision moves, it’s probably ok. However, if you want to make a Mario-like with critical jumps, you should probably avoid round edges: it could be very frustrating for the player to reach a platform on the edge, feeling he touched the platform ground, and finally slip into the void because of an almost invisible round edge!

If you are interested in coding, I wrote a previous article in my “hobbyist coder” series about a way to code a custom 2D platformer controller in Unity 3D, especially to avoid this kind of problems.

Visual and sound feedbacks

Yes, feedbacks are important. And yes, sometimes even during the prototype process.

I realized the importance of feedback in platformer working on a personal project: even with all the other “rules” above applied, I still found the game a little bit limp. I tried to tweak the variables, modify the move system, etc… Nothing changed. Finally I was tired to search and decided to start coding a sound manager to “relax” and the first sound I added to test it was the jump one. And how I was surprised to find my character much more reactive! I decided to continue on this way and implemented a run animation speed linked to the character speed: the games seemed to gain more reactivity again!

This little story was just to say that sometimes, even if you know animations, sounds or FX will come later in the development, the brain needs them to help it “materialize” some physics concepts like speed, move or gravity. And because platformer games are all about the understanding of specific physics, I think it’s important to implement placeholder feedbacks early before trying to tweak your move variables.

Conclusion

Of course, this list is non exhaustive and I’m really interested to hear about other observations about platformer controls.

This list is also subjective and it’s why I put a lot of “in my mind, “In my opinion” and “most of the time” expressions in this article: nothing is set in stone in game design. The game designer work is not really about “theory” and it’s why it’s very tricky to write about it. In my opinion (again!), the center of his work is above all to prototypes ideas, test them, prototype, test, etc. until he end up with something “fun”. So, if you want to design a kind of game which usually needs a lot of reactivity and precision, but going against these few tips, just don’t hesitate. But prototype your work!

Let’s finish with my game design golden rule: there are no golden rules!（source：gamasutra）