《Rubberband Racing》设计经验编辑本段回目录
作者：Max Knoblich
什么时候才适合始终遵循游戏设计想法，舍得花时间执行、平衡和制作资源？
什么时候你才能承认功能没有达到你的期望，甚至对游戏本身有害？
最近，《Rubberband Racing》这款3D Flash就让我面临上述问题。在开发这款游戏的过程中，我学到了许多东西。
rbr_collecting(from gamasutra)
限制因素
《Rubberband Racing》的设计存在若干限制因素，因为我希望尽可能缩短开发时间。
在不知道我的受众是否会喜欢游戏的基本机制和背景以前，我不敢冒然花时间制作某些功能特征。
没有多人模式
虽然对一款赛车游戏而言，没有多人模式是有风险的，但制作多人模式意味着我得开发（或寻找）、测试和维护提供即时玩法的游戏服务器。
Flash player不允许对等网络连线，所以那条路走不通。
不只是维护后台需要成本，运营也是费时间的事。
无NPC/AI赛车
与AI比赛可能是一项有趣的任务，但我估计制作这个功能会大大延长游戏开发时间。
给AI制作必要的元数据、修复漏洞和测试，轻轻松松就能消耗掉数周的时间；这些工作量取决你希望玩家遇到多少赛道障碍。
改进玩法
如果我既不要多人模式，也不要NPC，那么玩家还有什么可挑战的呢？我想只能绕圈驾驶、争取得到更高分的玩法会很快让玩家觉得厌烦。
最初的想法是让玩家一边驾驶赛车一边收集如下图所示的小球。
rbr_collecting2(from gamasutra)
小球的位置与赛道是分离的。
玩家每收集到一个小球都可以获得额外得分或时间加成。
如果玩家收集到完整的一连串小球，就可以得到额外的奖励。
一开始，作为丰富玩法和刺激玩家的一种设计，上述设计看似合理又简单。另外，小球的排列轨迹还起到提示赛道路线的作用。
总之，这似乎是非常好的设定。
反思
我做了小球放置的实验，并且实现了赛道提示的功能。
但是仍然觉得不对劲。事实上，这个设定可能会使玩家觉得受挫。
当我去掉小球，我更加肯定自己的猜想——这款游戏没有小球反而更有趣。
我开始寻找原因。
为了收集到一整串的小球，你必须非常小心地驾驶赛车。甚至使小球排列整齐再加上大量练习，玩家为了不偏离赛道，仍然很容易漏掉一两个小球。
赛道误差的设计存在矛盾，说明了玩家在完整收集到一连串小球的情况下，多多少少会偏离路径。
下图显示了允许玩家偏离赛道的最大范围：
rbr_collecting_suggested_lane(from gamasutra)
因为玩家总是希望圆满完成挑战，错过小球却使这个过程变得不完美了，即使赛车仍然稳当地行驶在赛道上。
玩家觉得“成功”或“正确”的范围其实被小球的排列轨迹大大缩小了。小球轨迹强加的有效路线如图4所示：
rbr_collecting_effective_lane(from gamasutra)
总结
事实上，这个设定既没有丰富玩法，也没有提供更多选择，反而限制了玩家。
另外，我必须承认：《Rubberband Racing》的操作缺少准确度，无法让玩家执行这么微妙的操纵技巧。我之前开发的一款游戏《Satellite》也存在类似的问题。
如果收集小球只是一个可选择的挑战，那就不算什么大问题。可惜那就是游戏的核心玩法。
最后，无法完整收集小球的挑战一点也不有趣。它并没有使游戏更刺激更紧张，也不要求玩家有其他操作风格或决定。
所有这些原因都使这个设计的害处盖过好处。即使一开始觉得这似乎使游戏设计锦上添花，我仍然决定完全放弃小球轨迹的设定。
另寻出路
这时候，我基本被打回原点了。但我仍然想到了其他东西：
收集物品或小球应该作为可选择的挑战，而不是游戏玩法的核心元素，至少在这款游戏中不行。
如果玩家没有收集到物品，应该引出另一个挑战或其他有趣的游戏情形。
以下是我的做法——得到火箭发射器：
rocketlauncher_preview(from gamasutra)
火箭发射器是玩家可以收集的道具。如果他收集到，那么他的赛车就可以同时发射三枚火箭。我承认这个与《马里奥赛车》等游戏的机制非常类似。
但是，如果游戏中没有其他玩家，也没有NPC，要火箭发射有什么用？
rbr_evading(from gamasutra)
在玩家得到火箭发射器后，很快就会遇到许多分散的障碍物。
如果他收集到火箭发射器，他就可以炸掉障碍物，给自己开道。在我看来，这肯定很有趣。
如果他没有收集到火箭发射器，那么他就会遇到其他困难。也就是，他必须小心地避开障碍物。
这两种情况都很有趣，使游戏玩法更加丰富了。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
Letting Go Of Game Design Features
by Max Knoblich
When is it a good idea to follow through with a game design idea, investing the time to implement, balance and create assets?
And when should you acknowledge that a feature is not working the way you had hoped, and might even be detrimental to the game?
I had to make this decision recently for Rubberband Racing, the 3D Flash game I am currently developing, learning a couple of interesting things in the process of doing so.
Limiting Factors
There are several limiting factors for the game design of Rubberband Racing, which are owed to the fact that I want to keep the development time as short as I can.
I’m hestitant to invest time into elaborate features without knowing whether my audience will like the basic game mechanics and setting.
There will be no multiplayer mode
While this might be risky for a racing game, implementing a multiplayer mode would mean that I had to develop (or find), test and maintain a game server which is capable of providing real-time gameplay.
The Flash player doesn’t allow peer-to-peer connections, so going that route is not an option.
Not only is maintaining a backend a cost factor, but getting it to run can be time consuming.
There will be no NPCs/AI cars
Implementing a racing AI would be a fascinating task, but I estimate it would blow up the development time by a great deal.
Creating the necessary metadata for the AI, bug fixing and testing can easily take up weeks, depending on how much road blocks you encounter.
Spicing Up Gameplay
If I’ll neither have a multiplayer mode nor NPCs, then what is there left to challenge the player with? I suspect that only driving around in circles trying to score better times would get old very fast.
The original idea was to have the player collect pellets with his car. I already mentioned that feature in my article about heatmaps.
The idea was to have separate trails of pellets on the track.
Each pellet that is collected by the player would either grant score points or a time bonus.
If the player collects all pellets in a certain trail, he would get an additional bonus.
At first this seemed to be a logical and easy way to give gameplay an additional dimension and to motivate the player. Also, the trails would provide the player with hints on how to find the racing line.
All in all, it seemed like a pretty good feature.
Having Second Thoughts
I experimented with the placement of the pellets and had some success in streamlining the path players would take.
Still, it didn’t feel right. In fact, the feature made gameplay a little frustrating.
My suspicions became worse when I deactivated the pellets after a while, and had the feeling that the game was more fun without them.
I set out to find out why that is.
To entirely clear a trail of pellets, you needed to steer your car very precisely. Even with well placed trails and a good amount of practice, it’s easy to miss one or two pellets due to not following the path accurately.
There was a discrepancy between the margin of error the track design suggested and how much players could actually veer off of a certain path without failing the challenge posed by the trails.
This is the acceptable space the player can use as suggested by the track design:
As players will want to complete the course as thoroughly as possible, missing pellets in the trail will feel like a blunder, even if the car stayed safely on the street.
This considerably narrows the path that the player would consider “successful” or “correct”. That makes this the effective lane imposed by the pellet trails:
Conclusion
It came down to the fact that the feature didn’t diversify the gameplay or offered more options, but actually limited the player.
Also, I had to accept that the controls in Rubberband Racing aren’t precise enough to let the player perform such delicate maneuvering. My previous game, Satellite, had a similar problem.
That wouldn’t have been a big problem if collecting the pellets was perceived as optional. But they were a central element of gameplay.
Finally, failing the challenge posed by the pellet trails was in no way interesting. It didn’t make the game more suspenseful or gripping, it didn’t require alternative play styles or decisions.
All of these reasons made this feature more frustrating than rewarding. Even though it felt like an elegant addition to the game design at the time, I decided to discard the pellet trails entirely.
Finding Alternatives
At this point I was basically back at square one. Still, I had realized a couple of things:
Collecting items or pellets should be, and feel optional. It shouldn’t be the central gameplay element, at least not in this game.
Failing to collect an item should open up a different challenge or interesting game situation.
This is how I implemented these lessons: Meet the rocket launcher.
The rocket launcher is an item that the player can collect. If he does so, he is granted three shots, which is admittedly much closer to proven gameplay mechanics in games like Mario Kart.
Now, what does the player need a rocket launcher for if there are no other players or NPCs?
The player will encounter a couple of scattered obstacles shortly after the rocket launcher item.
If he collected the item, he will be able to blow up the obstacles and shoot his way through them. Which, in my opinion, is inherently fun.
He will encounter a different challenge in case he didn’t collect the item, namely that he now has to evade the obstacles and try no to bump into them.
Both are interesting and engaging situations, making for much more rewarding gameplay.(source:gamasutra)
