作者：Ingrid Zajec

我将在此讨论《Super Farter》开发过程中的个人经验，探讨一款简单的游戏如何转变成有点复杂的数学计算，以及它至少需要一定程度的心理学见解才能够吸引玩家关注。

游戏简介

其理念是创造一款好玩而快节奏的游戏，并且能够让玩家轻松体验，无需玩家持续投入关注。其目标用户是5-10岁的孩子，因为他们代表着市场上的一个强大用户群。它是一款简单的一键式2D跑酷游戏：点触跳跃，长摁屏幕就可以飞翔。其飞翔元素是为了吸引目标用户。其独特功能在于加速跳跃的理念：通过持续跳跃，玩家就可以有限或无限地加速。但也因为这种快节春，游戏产生了两个独特的问题：平台布置，以及在合适的位置拾取道具。

问题1：平台布置

快速平台跑酷游戏看起来相当简单？给角色加速，分散平台和拾取道具，结果你就会发现它并没有这么简单。

多数手机屏幕都相对较小，所以屏幕上的角色在理想情况下不应该太小（游戏邦注：至少要占屏幕高度的三分之一）。

问题归结于反应时间（RT）。我们知道快节奏的游戏，场景通常应该快速滚动。注意图1中的玩家并不能看到前方世界的太多情况，这会限制玩家及时到达平台所做出的决策（例如，全跳，半跳，不跳）。

人类反应时间一般在持续清醒状态下是200毫秒。以持续清醒的状态玩游戏是一个精神上的要求，所以我们希望将反应时间减少至400-500毫秒。而响应时间则是反应时间+移动时间之和。所以我们假设正在奔跑的玩家，看到屏幕右手边的平台，而游戏世界则向左滚动。角色的移动时间约200毫秒，整个过程平均需要650毫秒来完成。

一个简单的计算可以显示，游戏世界应该（或者说玩家应该）以这种速度滚动（奔跑）：

1屏幕宽度/0.65秒=每秒1.5屏幕宽度

这并不算特别快。

简而言之，快节奏的2D平台游戏并不允许玩家以自己的反应时间来回应视觉刺激物。

这个问题有两个典型的解决方案：

*放慢速度（见图2）

*放大令视图变得更大（见图3）

 

因为我们关注的是快节奏的游戏，所以要忽略第一种解决方案。第二种解决方案会让玩家在屏幕上的角色相对较小，会保持物理速度，但会缩小预期节奏：只要看看10英尺和100英尺距离的火车速度你就知道，后者情况下的火车速度会更慢。

这个问题的解决方法就是让世界具有动态，例如让世界适应玩家的决策。当玩家跳跃时，可以人为地将平台布置在他打算着陆的右边。这原本意味着玩家需要来个大跳跃，但由于玩家每个跳跃都收到了积极反馈，这就为玩家提供了一个长期的正强化：获得“我很幸运”以及“我很擅长此道”的综合感觉。经过一系列成功的跳跃之后，玩家开始理所当然地进行完美跳跃，并且不会意识到平台并不会在跳跃之前出现（这是特意为解决问题而准备的）的这一事实。

让我们深究平台布置问题中的数学层面。玩家路径的计算可以通过开始跳跃时的运动方程或探索方法来计算。

通常情况下，运动方程可能看似一个最佳选择。不幸的是，先前试验表明它们并不能很好地预测玩家移动，原因如下：

*地面可能是曲折不平的，所以计算起来会更复杂，因为物理引擎还需要考虑地面的坡度，玩家动量，摩擦力，恢复等因素。

*跳跃冲力多变，并且取决于用户输入（即何时点触按钮，以及持续时间多长）。

*真正移动玩家的物理引擎实际上并不完美，并且要取决于时间步伐，这一点在整个游戏过程中会有变化。时间步伐则要取决于目前在屏幕上的对象数量，视觉效果的强度，在后端的设备处理能力等。

*如果玩家在跳跃点与其他对象碰撞，其预期就会被严重曲扭。

这种情况下的最佳选择就是推断。因为运动方程仍然会预测一个抛物路线，我们使用二次近似，例如找到最符合玩家轨道的最佳第二度多项式，并计算着陆点。

有两种方法可以找到这个多项式：

*多项式近似法：获取玩家的首个n位置（假设是头20毫秒左右的位置），计算最符合该位置的多项式（见图4）。

*多项式插值法：获取玩家的头3个位置，这里有一个符合这三个点的独特第二度多项式（见图5）。

 

近似法产生了良好的结果。 最小二乘法是一个广泛使用的算法，用于计算特定系列点的最合适曲线（它适用于任何类型的曲线）。当你获得一个描述路径的多项式p(x)=ax2+bx+c之时，只需简单地计算方程式p(x)=h的解决方案，而h就是你跳跃点的高度。这两个解决方法中最大者就是着点陆T的X坐标:

T = (-0.5(b + sqrt(b2 – 4ac – 4ah)) / a, h)

多项式插值法也产生了好结果，但并不是特别理想：它更容易受到扰动，以及物理引擎的初始误差的影响。

缺点

如果玩家完成了一次糟糕的跳跃，或者开始以较慢的速度跳跃，其跳跃目的地仍然位于当前视图，并且由于平台无法凭空出现，玩家的“大跳跃”就会失败，并且会产生负强化作用。所以这就需要玩家投入一定的训练。

问题2：布置拾取道具

在布置拾取道具时也会出现同以上相似的问题。

典型的道具会散落的世界各个角落，以便玩家在自己的反应时间内跳跃并拾取道具。此外，快节奏的游戏也会导致用户无法自然实现这一步操作（见图7）。

我们希望用户至少是在多数时间内能够在自己的最高点拾取道具，例如其抛物跳跃轨道的顶点（也可以是在着陆点），见图8。

之前的解决方案并不适用于这种情况，因为跳跃的长度通常介于1或2个视图宽度，因此在跳跃时间里，顶点通常会出现在视图内部，而目标显然无法布置在游戏中间。

典型的解决方案则包含放慢游戏速度或调整视图大小，但正如之前所言，这会摧毁游戏的快节奏。

我们再次得到了一个动态解决方案。因为游戏持续跳跃的属性，我们会预测如果玩家连续跳跃多次，玩家还会跳跃更多次。为了在理想的位置布置拾取道具，我们必须预测到玩家的跳跃行为：我们希望预测玩家跳程和高度，以获得玩家之后几次跳跃的垂直度（见图9）。单次跳跃与运动方程相关，因此玩家跳跃轨道也会像射弹轨道。

此时我想到的第一个方法就是采用玩家上次n跳程和高度的平均值，以这个平均来预测之后几次跳跃行为。更高级的方法会采用加权算术平均值，因为玩家现在可能比之前一次而非一段时间前跳得更高更远。

平均值方法会产生良好但并不完美的结果。分析显示偶尔的跳跃并不完美，无法获得理想的结果。频繁的“糟糕跳跃”则起源于以下原因之一：

*倾斜会影响用户速度

*跳跃时机不对

*玩家碰撞到一个障碍物

另一方面，玩家也可能完成优秀非凡的跳跃。这些不规律性打乱了平均值。

尝试过多种方法，最后发现异常值排除法可得最佳结果。其理念很简单：从之前的n跳跃开始，排除最出众的m<n跳跃，并取其余跳跃的平均值，跳跃的范围应该乘以一个校准常量。现在我们只需要在预期跳跃的顶点或着陆点布置拾取道具（见图10）。

异常值排除法非常管用：搜集每个道具都有一种非常不自然的感觉。它并不能让玩家产生“我擅长此道”的感觉。但我们可以通过随机散布三分之一的拾取道具来解决这个问题。这样玩家就能获得一种“虽然道具是随机布置的，但我也能搜集到大部分道具”的感觉。

总结

我们已经讨论了快节奏平台游戏中的两种问题：平台布置以及拾取道布置，我们列出了多种解决方法，并指出了能够提供最富经验性的结果。这里所描述的问题只有在我们想让玩家顺利获得道具，令其感觉游戏很有趣但却不会发现其中欺骗性的情况下才会很重要。通过让玩家误以为他们很精通游戏，我们就能够为其带来积极情绪，并令游戏具有“成瘾性”。当然，也应该布置其他障碍物（如敌人、火箭等）以分散玩家注意力，并允许玩家最终输掉游戏。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Mathematics and psychology to improve UX in fast-paced platform games

by Ingrid Zajec

I will discuss my experience during the development of the game Super Farter, how a simple game idea turned out to involve somewhat complex mathematics and at least some degree of understanding the psychology needed to keep a player hooked on.

A little about the game

The idea of the game was to create a funny fast-paced game that would be relaxing to play, that is, no constant awareness is required from the user. The target audience was chosen to be children aging 5 – 10, since they represent a strong consumer group on the market. The game is a simple one-button 2D endless runner: tap to jump, hold to fart (fly). The element of farting was added to attract the target audience (hey, say “fart” to a 5 year old, he will start laughing). A unique feature of the game is the concept of speed jumping: by continous jumping (hopping), the player accelerates with either limited or no bounds on speed. Due to the fast-pacedness of the game two distinct problems arise: placing platforms and placing pick-ups on appropriate positions.

Problem #1: Placing platforms

A fast-paced platform runner seems simple enough? Accelerate the character, disperse around platforms and pick-ups, and voilà! Well, it does not turn out to be this simple.
Most mobile phone screens are comparatively small, so a character on the screen ideally should not be particularly small (ideally at least ⅛ of the screen’s height).

Reaction time vs Viewport size

Figure 1: Reaction time vs Viewport size

The problem boils down to reaction time (RT). As we are talking about fast-paced games, the scenary should be scrolling fast. Notice on Figure 1 that the player does not see much of the world ahead, which disables the player to make a decision (e.g. full jump, partial jump, no jump) in time to reach the platform.

Human RT is about 200 ms at constant awareness. Playing a game in constant awareness is psychically demanding, so we wish to reduce reaction time to about 400-500 ms. The response time is defined to be the the reaction time + movement time. So lets say a player is running along and sees a platform on the right-hand side of the screen, while the world is scrolling left. The movement time of the character takes about 200 ms, the whole process should take about 650 ms on average.

A simple calculation shows that the world should scroll (or equivalently, the player should run) at a speed about

1 screen-width / 0.65 s = 1.5 screen-widths per second,

which is not particularly fast.

In short, a fast-paced 2D platformer does not allow the player to react to visual stimuli within his reaction time.

There are two classical solutions to fix this problem:

Slow down tha pace (Figure 2)

Zoom out and make the viewport bigger (Figure 3)

Jumping on platforms at a slower pace

Figure 2: Jumping on platforms at a slower pace

Making the viewport bigger

Figure 3: Zooming out making the viewport bigger

Since we are concentrating on fast-paced games, we dismiss the first solution. The second solution would make the player to appear relatively smaller on screen, would keep the physical pace, but would reduce the perceived pace: look at a speeding train at a 10 foot distance or at a 100 foot distance, the train would appear to be much slower (or at least less exciting to watch) in the latter.

A solution to the problem is to make the world dynamic, i.e. let the world adjust to the players decisions. When a player makes a jump, artificially place the platform right where he is supposed to land. Initially this means that the player must take a leap of faith, but as the player recieves a positive feedback at each leap, this brings, on the long run, positive reinforcement to the player: a combined feeling of “I am lucky” and “I am good at this”. After a few successful jumps, the player starts to take perfect jumps for granted and does not percieve the fact that the platforms are not visible before the jump, which solves the problem specified.

Lets dig into the mathemacal part of the platform-placing problem. The calculation of the players path can be calulated either by the equations of motion or any method of extrapolation made at the beginning of the jump.

Normaly the equations of motion would seem to be the best choice. Unfortunally preliminary experiments showed that they did not turn out to predict the players movement very good for one or more of the following reasons:

The land can be curved, so the calculations would have to be more complex, since the physics engine also takes into account the land’s slope, the players momentum, friction, restitution, etc.

The jump impulse varies and depends on the users input (when and how long the tap lasts).

The physics engine that actually moves the player is never perfect and depends on the time step, which is variable thoughout the game. The time step depends on the number of object currently on screen, the strength of visual effects, device processes in the background, etc.

If the player collides with other objects at the jump point, the prediction is heavily distorted.

Extrapolation is the best choice in this case. Since the equations of motion still predict a parabolic path, we use quadratic approximation, i.e. find the best 2nd degree polynomial that best fits the player’s trajectory and calculate the landing point.

There are two ways to get such a polynomial:

Polynomial approximation: capture the first n positions of the player (lets say the positions of the first 20 or so miliseconds), calculate the polynomial that best fits the positions (Figure 4).

Polynomial interpolation: capture the first three positions of the player, there is a unique 2nd degree polynomial that exactly fits these three distinct points (Figure 5).

Polynomial approximation

Figure 4: Second degree polynomial approximation

Polynomial interpolation

Figure 5: Second degree polynomial interpolation

The approximation method brings good results. The Least Squares Method is a simple widely used algorithm that calculates the best-fitting curve to a given set of points (it can be applied to any type of curve). Once you get the polynomial p(x)=ax2+bx+c that describes your path, simply calculate the solution of the equation p(x)=h, where h is your height at jump-point. The biggest of the two solutions is the x-coordinate of the landing point T to which we move (or create) the platform (Figure 6).

T = (-0.5(b + sqrt(b2 – 4ac – 4ah)) / a, h)

Dynamic platform placament

Figure 6: Dynamically placing a platform

Polynomial interplation also brings good results, but not great: is it more susceptible to perturbations, initial inaccuracies in the physics engine.

Drawbacks

If the player makes a bad jump or starts the jump at a slow pace, the jump destination is still in the current viewport and since platforms cannot appear from thin air, the player’s “leap of faith” fails and will provide a negative reinforcement. Thus, a bit of practice may be required from the player.

Problem #2: Placing pick-ups

An analogue problem to the one above appears in placing pick-ups.

Classicaly objects are scattered around the world so that the player can jump to pick them up within his reaction time. Again, a fast-paced game disables the user to acieve this naturally (Figure 7).

Figure 7: The player misses the pick-ups outside the viewport

We wish that the user, at least most of the time, picks up an object at his peak point, i.e. the vertex of his parabolic jump trajectory (and perhaps also at the landing point), see Figure 8.

Range, height, and vertex

Figure 8: The range, height and vertex of a jump

The previous solution cannot be applied to this case, since the length of a jump is usually between one or two viewport widths, thus, at the jumping time the vertex often appears inside the viewport and the object obviously cannot be placed there mid-game.
A classical solution would again involve to either slow the pace of the game or resize the viewport, but as argued before, this would ruin the fast-pacedness of the game.

We again work out a dynamic solution. Because of the nature of the game (continous jumping), we predict that if the player jumps a few times in a row, the player will jump a few times more. To place pick-ups on the desired places we must predict the players jumping behaviour: we wish to predict the players range and height to get the verticies of the player’s next few jumps (Figure 9). Recall that a single jump is bounded by the equations of motion, furthermore, the players trajectory bahaves as a trajectory of a projectile.

Predicting a jump with the outlier method

Figure 9: Predicting a jump

The first method that comes in mind is to take an average (arihmetic mean) of the players last n ranges and heights, and take this average to predict the next few jumps. A slightly more advanced method would take a weighted arithmetic mean, since the player is more likely jump a bit more like the previous jump, not the jump made a while ago.

The mean method brings good results but not perfect. Analysis showed that jumps now and then appear to be too imperfect to get a good average. Frequent “bad jumps” appear from one of the following reasons:

a slant distortes the users pace,

the jump timing is off,

or the player collides with an obsticle.

On the other hand it might happen that a jump is unusually good. All these irregularities mess up the average.

Trying out various methods, it turned out that outlier ellimination method gave best results. The idea is simple: from the last n jumps, take out m < n jumps that stand out the most and take the average of the remaining. Best three our of five gave satisfying results. In addition, if the player is accelerating on each jump, the range of the jump should be multiplied by a calibrated constant. Now we just place the pick-up either at the vertex or the landing point of the predicted jump (Figure 10).

Dynamically placing pickups

Figure 10: Dynamically placing pick-ups

In the realization the outlier method actually worked too well: collecting practically every item had a very unnatural feeling to it. It did not manage to fool the player into a “I am good at this” feeling. One can easily fix this by randomly scattering around about ⅓ of the pick-ups . With this the player gets a feeling “eventhough items are randomly placed, manage to collect most of them”.

Conclusion

We have discussed two problems that can appear in fast-paced platform games: placing platforms and placing pick-ups so the player hits them every time. We outlined various solutions and pointed out which of the solutions gave the best empirical results. The problems described are imperative only if we wish to place items in favour of the player and win the player over in the sence that the game is enjoyable to play despite the fact that the player is not consciously aware of the deceptions. By fooling the player into thinking he is good at the game, we bring positive emotions and potentially make a game “addictive”, which we assume is objective to all game developers. Of course other obsticles (enemies, spikes, rockets,…) should be placed to distract the player and allow the player to eventually lose the game.（source：gamasutra）