作者：Maxence Voleau

最近我正致力于创造一个根据连线消除机制进行调整的游戏原型。经过多次迭代以及来自好友们的各种反馈，我最终完善了它的核心游戏玩法。但是在不久前我却遇到了另外一个大问题。（请点击此处查看旧版与新版游戏原型）

Match Tree(from racine.meedoc.net)

即当所有宝石都被摧毁后，“清除阶段”便会让人感到异常困惑：所有的宝石组合将会同时爆炸，但是玩家却很难看清到底发生了什么。而解决方法便是我需要延长两次爆炸的间隔，一个接一个摧毁这些组合。如此，玩家便能够淡定地观察到自己的表现。

游戏循环(from gamasutra)

现在你便拥有了一个完整的游戏循环，我将详细阐述清除阶段是如何运作以及我需要做出何种改变。

原先的清除阶段（from gamaustra)

分数的增加主要归功于两个不同的变量。第一个变量是一行中被摧毁的群组数量（也就是我们在上图中所说的倍增器）。第二个变量则是基于链条长度的典型combo，创造新群租的原理主要与宝石的重新定位有关（游戏邦注：也就是上图中所说的combo）。

因此，如果玩家触动了链条便能够获得更好的奖励，但是为了能够更好地利用这一点，你同时也需要使用倍增器。这种双速系统将为那些水平欠缺的玩家的直接表现提供奖励。而对于那些硬核玩家，我们也设置了一些更有深度的系统（找到combo和倍增器增量之间的平衡）。

除此之外，这种简单的倍增器将进一步帮助那些缺少技能且不足以触发链条的玩家。这种游戏区域设置便是为了让更多群组获得奖励。

而我的目标其实非常简单。就像我之前所说的，这只是一个关于速度的问题。这时候，清除阶段的第一步只花费我们不到半秒的时间，而整个阶段也只花费了1秒。所以为了提供给玩家更多休息时间，我便决定延长两个摧毁阶段之间的过程，以让玩家有时间思考他们的目标。

目标清除阶段（from gamasutra)

不幸的是因为我不熟悉如何使用运算法则去调整当前的系统，所以我便难以有效地执行这种预期的延时。

这时候我有两个选择：

1.放弃这一功能

2.寻找另外一种解决方法（即使它将改变你的设计）。

从我个人以及游戏设计视角来看，我们必须确保这一功能与连线消除游戏的速度相一致。通常来看，这都是一些节奏较快，带有强烈紧张感的游戏。你必须马上分析游戏范围，并立即找到最佳选择。我所做出的修改包含一个双速系统。即经历一个短暂且紧张的准备阶段，然后休息一会，再经历一个短暂且紧张的准备阶段，在休息一会，如此循环。这其实与游泳类似：快速呼吸，屏息游一小段，快速呼吸，再屏息游一小段，如此反复。

而如果你删除了游泳者“快速呼吸”的时机，他们肯定会在游了一小段距离后死亡。而如果我不能提供给玩家休息的机会，我怕他们也会遭遇相同的下场。这种休息将提供给玩家一种视觉上的奖励（即让他们能够淡定观察自己那些被摧毁的群组）以及分析游戏区域的机会，从而让他们计划自己的下一步行动。

一种简单的解决方法便是使用以下述系统进行替换：

新清除阶段(from gamasutra)

但是如果选择了这一解决方法，我的分数系统便会失去许多趣味。倍增器将失去用处，也就是说这种解决方法并不能满足玩家。以前的系统之所以非常出色是因为它能够帮助那些缺少技能的玩家更好地进行游戏，并也能够提供给硬核玩家一定的游戏深度。

所以我将根据相同的原理去寻找其它解决方法。以前的倍增器将奖励那些未使用链条机制而创造出更多群组的玩家（游戏邦注：即奖励玩家的直接表现）。而我在执行系统奖励中唯一能够使用的变量便是群组的规模。所以我所设计的新规则如下：

倍增器将根据每个被摧毁的群组规模，而非同一行中被摧毁的群组数进行增加。倍增器+=基底（群组规模/5）：

当前清除阶段(from gamasutra)

使用这一系统，我们便能够轻松地增加combo的数量，但是现在的游戏深度则与倍增器息息相关。所以我到底应该创造一个巨大的群组还是一些小群组？此外，我们将从左至右摧毁群组，所以玩家必须注意宝石的移动。虽然现在的游戏变得更加复杂，但是游戏中的分数系统却同时变得更加宽容了。

总结

这些内容都预示着你不需要受制于自己的技术水平！游戏设计师在面对任何难题时都必须想办法去寻找合适的解决方法。技术局限性与设备输入方式一样是种常见问题。

你需要认识到，不论遇到了何种问题都需要牢记之前规则/选择中的原理。千万不要彻底改变你的设计，因为你可能永远都不会再创造出同样的内容（除非你能够通过实验而真正找到取代它的优秀内容）。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

When technical skills influence game design

by Maxence Voleau

Introduction

This article is especially dedicated to students and junior designer like me, but it may interest others. The game prototype which is used in the following example is playable:

here for the old version

here for the current version

Actual Example

Recently, I worked on a prototype of a Match Three with a twist. I did several iterations to improve the core gameplay thanks to feedback from friends. But the other day, I had to face a big problem.

The “clearing phase”, when all the gems are destroyed, was too confusing: all the groups exploded simultaneously and so, the happening events were not clear for the player. The solution I wanted to do was to destroy groups one by one with a certain delay between two explosions. Thus, I thought the player could peacefully observe his performance and breathe a little.

Now that you have an overall of the game loop, I’ll detail how the clearing phase worked and which changes I wanted to do.

The score’s increment works thanks to two distinct variables. The first one depends on the number of groups destroyed in a row (it’s the one called multiplier in the figure above). The second is a classic combo depending on the length of the chains, the principle of creating new groups thanks to the repositioning of gems (it’s the one called combo in the figure above).

Thus, there is a better reward if the player provokes chains but in order to take the greatest advantage of that, you need to use multiplier too. This two-speed system helps the less skilled players by rewarding their direct performance independently of their anticipation. For, hardcore gamers, we have a system with a subtle depth (searching a balance between the increments of combo and multiplier)

Moreover, this simple multiplier helps less skilled player which cannot anticipate enough to provoke chains. Just arranging the game area in order to have a lot’s of groups is rewarded.

What I wanted was quite simple. Like I said earlier, it was just a question of pace. At this point, the first step of the clearing phase (the successive destructions) took less than a half second and the whole phase 1 second. So, I though I’ll just had a delay between two destructions in order to offer a break to the player, and the time to contemplate what he worked for.

Unfortunately, I didn’t succeed to implement this delay as I did not have enough skills in algorithm to rework my current system.

At this point, I had two choices:

1.Forget this feature

2.Find another solution even if it may modify the design.

In my opinion, and regarding to the game design, it was really important to keep this feature as my twist plays with the pace of a match three. Usually, they are games with a fast pace, intense and exhausting. You have to analyze the game area in an instant and find the best option immediately. The modification I made involves a two-speed pace. A short and intense preparation phase, a quick break, a short and intense preparation phase, a quick break… It’s quite similar to swimming: quick breath, short swimming session without breathing, quick breath, short swimming session…

If you delete the “quick breath” opportunity to the swimmer, he will surely die after a few sessions, and I was afraid that players will feel the same if I did not offer them a break. This break offers to the player both a visual reward (peacefully observing the destruction of the group he just organized) and the opportunity to analyze the game area in order to plan his next moves.

The simplest solution I found was to provide the following system in replacement:

However, by choosing this solution, my score system was a lot less interesting. The multiplier was useless. And that was not satisfactory, to say the least. My previous system was cool (IMO) because it helped less skilled player and offered depth to hardcore (Should I take advantage from the multiplier or the combo?).

I then tried to find a solution with a similar philosophy. The previous multiplier rewarded the fact of doing lots of groups without using the chain mechanism (the idea behind that was to reward the direct performance of the player). The only variable I could use to implement a system rewarding direct performance was the size of the groups. So, the new rule I designed was the following:

Instead of incrementing depending on the destroyed groups in a row, the multiplier is going to increment depending on the size of each destroyed group. Multiplier += Floor(group_size / 5);

With this system, it’s easy to increment the combo but the depth is now related to the multiplier. Should I do a huge group or several tiny groups? Moreover, the groups are destroyed from the left to the right, so the player has to take care of the gems movement caused by a group’s destruction. The game is now more difficult but the score system is also now more tolerant.

Conclusion

What all this blablabla means is that you are not limited by your technical skills! A game designer has to find a solution when he faces a wall. Skill’s limitation is one type which exists as well as device’s inputs.

The point is that whatever the problem is, you have to keep in mind what was the philosophy behind the previous rule/choice. Do not radically change your design because you cannot apply it as such (except if you find an awesome thing by experimenting). Be wise, and trick the computer!(source:GAMASUTRA)