游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

列举游戏设计需回避的错误做法(3)

作者:Ernest Adams

距离我写上一篇糟糕的游戏设计文章已经近两年了,我觉得是时候再写另一篇了。在玩游戏时,我发现和记录了很多电脑游戏漏洞、设计缺陷和个人失误,终于凑够写一篇文章了。其中有些是低级设计错误或者编程缺陷,但都是游戏设计师本可以有所作为的地方。(请点击此处阅读本系列第124、56、7、89、1011、1213篇)

bad-game-design(from troll.me)

bad-game-design(from troll.me)

幼稚的救世之梦

“征服世界!”“人类的命运危在旦夕!”“拯救宇宙!”摆在游戏商店货架上的游戏盒子们召唤着我们。“不!我才不要!让宇宙自己想办法吧!”我毫不犹豫地拒绝了。

像这种充斥着白日梦式的救世主题的电脑游戏实在太多了,毫无意义的末日情节就是典型的症状。我不当热血少年已经好多年了,我再也不会被这种情节欺骗了。也许这意味着我已经长成一个无趣的成年人了,已经消受不起这么宏大的想象了……但是,老实说,边跑边叫征服世界的人是疯子吧。我想更准确的说法是,我只是不关心世界的命运罢了。我不想统治世界,也没兴趣拯救宇宙。那任务实在太艰巨的,不是一个人就能胜任的。所以,不要把这些重任交给我,我不想要。

所有故事都需要戏剧张力,但戏剧张力是怎么来的?是创造一个情境,把读者/观众所关心的东西或者人置于危险之中。类似的,所有游戏都需要目标,我们所谓的“游戏张力”就是由玩家希望达到的目的创造的。戏剧张力与游戏张力的相似性是电脑游戏通常具有故事元素的主要原因。但如果你想想优秀的文学作品中的故事,被置于危险之中的极少是像世界命运这么重大、这么不可估量的东西,相反地,是某个人的生命和幸福。狄更斯的作品中就富有真正的张力,比如,David Copperfield能否幸免于Uriah Heep的阴谋诡计?这种张力比各种“地球就要被小行星撞毁”的电影强多了。甚至,我们在看那些电影时产生深深的同情也不是因为整个地球危在旦夕,而是电影的主角们及他们的命运。以《When Worlds Collide》为例,地球和其他人都完蛋了,但我们的主角逃出升天了。谢天谢地!真是圆满的结局!

“等一下!”我听到你愤怒地喊住我。“你不是也爱看托尔斯金吗?难道《指环王》不是关于世界末日的吗?”好吧,是的,我当然是,它也当然是。但《指环王》不同于它的低劣效仿之作的地方是,它其实不是关于拯救世界多么了不起,而是关于即使你成功了你也必然失去了某些东西。这本书是一出拯救世界的悲剧,告诉我们拯救世界要付出的代价。

我想,《模拟人生》的成功非常清楚地告诉我们,游戏不一定要拿拯救世界当主题,毕竟许多人都不想的。大伙儿忙着洗碗刷锅、扫地洗衣,哪有空关心世界。并且许多人也很高兴做这些琐事,Maxis(《模拟人生》的开发公司)不正是靠它发家致富的嘛?我们不要求游戏让我们去拯救世界,我们只想拯救我们所关心的人。事实上,如果不以“拯救世界”为题,我们能做出的游戏会更多。

站在正确的角度

这个再明显不过了。如果设计师故意把屏幕的可选择区域做得极小,那么,他的游戏只是浪费时间的无聊谜题。如果设计师是偶然犯这样的错,那么在测试时也应该发现这个悲剧。游戏测试员有一个问题:他们是经验丰富的玩家——玩了几百小时的游戏后,他们太了解这款游戏了,他们可能不会发现让非硬核玩家组成的大众市场困惑的设计错误。随着我们设计的游戏越来越针对非硬核市场,我们需要能站在非硬核玩家的角度发现问题的测试员。

糟糕的寻径

寻径是指,让一个单位从这里移动到那里,并且路上要避开障碍的过程。寻径过程会出现许多种错误,但最让人郁闷的莫过于单位被什么东西卡住,死活走不出来。原版《帝国时代》就因糟糕的寻径而遭人诟病,直到发布解决问题的补丁。你命令一伙人去某地,他们卡住了,原地打转,直到你给他们新命令或移除那个两岁小孩都知道怎么过去的小障碍物。这种问题除了让人郁闷,还破坏了玩家的沉浸感和对游戏的敬意。

寻径绝不是一个简单的问题——我曾经设计过硅板布局和卖布线工具为生,所以我很清楚这一点。游戏寻径在一定程度上更简单了,因为在战场上,一个士兵跨过另一个士兵的路线并不会导致短路。然而,不像布线芯片追踪,不可能放着它运行一晚上。当玩家命令一个士兵走到某处时,这个士兵必须立即行动,不能停住想一下怎么走。

以下有几个关于寻径设计的经验法则:

1、重要的不是游戏中的军队能看到什么,而是玩家能看到什么。一般来说,玩家是俯视的,可以清楚地看到他希望他的军队走的路径。即使他的军队并不“知道”那个地区,也无法“看到”最佳路径,他们也应该使用玩家的视野而不是他们自己的,来计划路径。否则,玩家就会觉得“为什么你要往那走?”

2、步兵不应该被己方设备阻挡。在现实世界里,如果一队步兵要通过一排己方的坦克,他们就能通过,即使这些坦克紧紧排列成一条线。步兵可以从坦克上翻过去,或者从坦克之间的缝隙爬过去,无论什么方法,总之能过去。坦克虽然会让他们通过的速度减慢,但绝对无法阻止他们通过。这就是普通步兵的优势——他可能没有太多装备或火力,但他比其他单位更加多才多艺。不要因为寻径问题而抹煞他们的这个优点。

3、单位群应该过滤与大小接近于他们自身的障碍,穿过大障碍时应该保持整体。作为一般原则,团队应该一直在一起,走大致相同的路径,但不至于所有单位都挤到右手的树旁边。有多少次你选中一组士兵,命令他们走到某处,却发现其中两个士兵自己跑到另一条奇怪的路径上去了?原因是这两个士兵把其他士兵当作障碍而不是自己归属的整体。他们的AI似乎太“聪明”了一点。你必须平衡他们的自由度,用坚持与群体呆在一起来改进个体的路径(过滤树、岩石、小山或建筑)。

进入导航点作为行动命令的一部分。当你的寻径出现漏洞时,这就是你的“逃生办法”,通过进入导航点,玩家可以避开寻径问题。显然,最好第一次就做好,但用导航点解决寻径问题至少让玩家能够继续玩下去而不是因为受挫而放弃。总之,导航点通常是有用的。关于寻径的书太多了,所以我就不再赘述了。大多数寻径问题都是测试和调整没做好导致的。所以请尽量做好测试和调整;糟糕的寻径会让玩家马上判定你的游戏“太蠢”。

低多边形模型

哇,你的游戏使用3D引擎!真是令人刮目相看啊!问题是,你的引擎要显示的东西太多了,所以你决定把它们做成低多边形模式。你的游戏世界中的一切东西都有怪异的边缘,与现实世界中的它们相距甚远。以树为例,低模树看起来就像一把伞,因为树枝都相同的长度,当镜头经过它们的树冠时,就让人觉得很为怪异。

不要那么做。太丑太俗了。让你的美工做得更精致一点吧,如果你没有足够的多边形,那就把它们放在一个矩形上吧。是的,你越接近它们,它们就会像素化,除非你对它们使用锥形纹理技术,但你的墙体也要这么做;我们习惯这样了。记得《毁灭战士》中地上死尸只有一个子画面吗?当你走到尸体的另一边时,尸体仍然面朝相同的方向,好像它们的眼球就画在纸上似的?记住,这没什么,我们其实不在意。树也是一样的,事实上我们更不在意树的朝向,除非它与玩法有一定的关系,否则树总是朝着相同的方向并不重要。看起来正常的树总是比形状像伞的东西来得强。

特定场景的声音片段太少

我讨厌在某个特定的情境出现时听到相同的声音片段一次又一次地播放。如果这个声音只是确认的哔哔声就算了——但这样的话,这个声音就应该始终是一样的,这样才能为玩家提供一致的线索——但如果声音片段是人说话,那就立即让人火大了。我担任《Madden NFL Football》的声音/视频制作人多年,所以我有时候也为这一点感到羞愧。我们给Madden录音的时间有限,所以我们不可以录到我们想要的所有东西。《Madden NFL Football》的声音脚本通常是75页长,如果可以我会多写一倍。

madden_nfl(from nishanblog.blogspot)

madden_nfl(from nishanblog.blogspot)

如果某个情境与某个声音片段有关(比如“我打中了!”),那么就要为个情境录非常多的声音。我自己的原则是,每个情境都不要少于五个声音片段,甚至最少出现的情境也是;至于经常出现的事件,应该至少有二十多个。你不必总是录完全不同的语句;有时候相同的语句用不同的语气念出来也是可以的。在游戏中,可以使用软件,这种软件可以把与情境对应的声音罗列下来,当情境出现时,就在列表中随机选择播放的声音,播放完后就把该声音片段标记;当同样的情境又出现时,再从剩下未被标记的声音片段中随机选择,如此循环。当所有声音都被播放过后,就重置列表。这样,玩家就不会连续听到同样的片段两次了。

带剑的鸟

啊呀!我们被恶魔附体的鸟类攻击了!我们面临被啄死的危险。我们砍啊、劈啊,我们施放烤箱+3的魔法。莫名其妙的数字不断地跳出来,似乎是一种跟血跟痛无关的攻击方法,但我们当中有些人却因此受伤了。最终,我们消灭了最后一只鸟类(坏蛋从来不会聪明到逃走,甚至当它们失去数量上的优势时;这是鸟类令人钦佩的责任感啊)。检查尸体时我们发现,这些恶鸟不仅穿得像人,还带了人类的钱和武器。真是出乎意料!其中一只恶鸟还带了杀伤力+5的宝剑。可笑,当这只鸟人还活着的时候,我根本没注意到它还带了这样的好家伙。如果它装备这么好,为什么不在战斗中使出来呢?还有,这家伙把钱放在哪里呢?胃里吗?

你懂的。

总结

以上就是我积累了多年的怨念。如果作为游戏设计师的你也犯过同样的错,那我得说你真是糟糕的设计师!不要为自己找借口了。如果你自己也发现了一些游戏设计失误,请通过邮件分享给我吧。我正准备再写一篇文章呢。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Bad Game Designer, No Twinkie! III

By Ernest Adams

Well, it has been close to two years since the last “Bad Game Designer, No Twinkie!” column, so I think it’s time for another one. I keep a collection of computer game misfeatures, design errors, and personal annoyances as I play, and it’s now long enough to publish. Some of these are level -design errors or even programming weaknesses, but they’re all things that a game designer has at least some influence on.

Adolescent Armageddon

“Conquer the world!” “The fate of humanity is at stake!” “Save the galaxy!” scream the boxes on the shelves down at the game software store. “No!” I’m tempted to scream back. “I don’t want to! The galaxy can go stuff itself!”

Too many computer games are fulfillments of adolescent power-fantasies, and a meaningless apocalyptic scenario is a classic symptom. It’s been quite a while since I was an adolescent, and I just don’t believe them any more. Maybe that means I’m a boring old adult, no longer capable of grandiose visions… but let’s face it, the people who run around yelling about conquering the world are nut cases. I think it’s more accurate to say that I just don’t care. I don’t want to rule the world. I’m not terribly interested in saving the galaxy. It’s too big and impersonal a task, and it’s not credible that a single individual can do it anyway. Don’t ask me to. I don’t feel like it.

All stories require dramatic tension, and dramatic tension is created by establishing a situation that puts something, or someone, that the reader cares about at risk. Likewise, all games require a goal, something that the player is hoping to achieve, which creates what we might call “gameplay tension.” The similarity of dramatic tension and gameplay tension is the reason that computer games so often have a storytelling element. But if you look at the great stories in literature, what’s at risk is seldom something vast and incalculable like the fate of the world. Rather, it’s the lives and happiness of individual people. There’s more genuine tension in a novel by Charles Dickens – will David Copperfield survive the wicked machinations of Uriah Heep? – than there is in all the movies about earth-shattering asteroids ever filmed. And even those movies don’t really try to engage our sympathy for the Earth as a whole. Rather, they engage our sympathy for the movie’s main characters and their individual fates. Take When Worlds Collide, for example. They destroyed the Earth and everyone on it, but — whew! — our heroes got away safely. Thank goodness for that! Happy ending!

“But wait,” I hear you cry in irritation. “Aren’t you one of those Tolkien nuts? And isn’t The Lord of the Rings about as apocalyptic as you can get?” Well, yes, I am, and yes, it is. But what sets The Lord of the Rings apart from most of its pale imitators is that it’s not actually about how wonderful it is to save the world. It’s about what passes away irretrievably even when you succeed. It’s a book about the tragedy of saving the world, the price to be paid for doing it.

I think the success of The Sims demonstrates pretty clearly that it’s not necessary to rule the world, and a lot of people don’t even want to. They’re busy just trying to keep the dishes washed and the newspapers picked up. Millions of them are perfectly happy doing it, and Maxis is making a fortune out of fulfilling that particular, if peculiar, fantasy. We don’t need for games to be about adolescent armageddon. We only need for them to be about people that we care for, and in fact that allows us to make a much wider variety of games than “Save the world!” does.

Having to stand in (or select) exactly the right spot.

There’s not a lot that needs to be said about this. If the designer has made a selectable region of the screen extremely small on purpose, it’s just a trial-and-error time-waster, a boring puzzle. If the designer has done it by accident, it’s a misfeature that should have been caught during testing. There’s one problem with testers: they’re such experienced gamers – and after a few hundred hours playing a game, so experienced with that particular game – that they may not catch design errors which would annoy the pants off mass-market, non-core players. As we make more and more games for the non-core market, we need testers who can think like a non-core gamer.

Bad pathfinding.

Pathfinding is the process of figuring out how to get a ground-based unit from here to there, avoiding obstacles on the way. Pathfinding can go wrong in a lot of ways, but the most frustrating is when a unit gets stuck behind something and can’t figure out how to get around it. The original Age of Empires was notorious for its bad pathfinding until they released a patch for it. You’d tell a group of people to go somewhere, and they’d get stuck and wander haplessly around until you either gave them new orders or removed some trivial obstruction that a two -year-old could figure out how to get past. In addition to being frustrating, it destroys the player’s suspension of disbelief and respect for the game.

Pathfinding is not a simple problem by any means – I used to program silicon layout and circuit routing tools for a living, so I know something about it. Game pathfinding is easier in some respects because soldiers don’t create a short circuit if they cross another soldier’s path on the battlefield. However, unlike routing chip traces, it can’t be left to run overnight, either. When the player tells a soldier to go somewhere, that soldier needs to leave immediately, without visibly stopping to think about how he’s going to get there.

Here are a few design rules of thumb about pathfinding:

It’s not about what the troops can see, it’s about what the player can see. Typically, the player is looking at an aerial perspective of a region, and can clearly see the path she wants her troops to take. Even if those troops don’t “know” the terrain, and can’t “see” the best route from the ground, they should use the player’s degree of knowledge, not their own, to plan a route. Otherwise the player will be asking, “Why are you going that way?”

Foot soldiers should not be obstructed by their own side’s equipment. In the real world, if a group of foot soldiers are trying to get past a row of friendly tanks, they can do it, even if the tanks are lined up axle to axle. They’ll climb over, crawl under, or whatever. It may slow them down, but it won’t stop them. That’s one of the best features of the common infantryman – he may not have much armor or firepower, but he’s more versatile than any other unit. Don’t take that away from him by needlessly obstructing his pathfinding.

Groups of units should filter among obstacles similar in size to themselves, but should stay together when travelling around large obstacles. As a general rule, groups should stick together and follow roughly the same path, but not to the extent of all walking around the right-hand side of a tree. And how many times have you selected a group of soldiers, told them to go somewhere, and found that two out of the twenty of them are wandering off on some other weird route of their own? What’s happening is that the two are treating the other 18 as an obstacle rather than a group that they’re expected to remain part of. They’ve got a little too much independent thinking in their AI. You have to balance their freedom to improvise individual paths for themselves (filtering among trees or boulders) with their obligation to stick together (taking the same way around a hill or building).

Make it easy for the player to enter waypoints as part of her movement orders. This is your “escape clause” if your pathfinding has bugs. By entering waypoints, players can work around pathfinding problems. Obviously it’s preferable to get it right the first time, but solving the problem with waypoints at least lets the player go on playing instead of giving up in frustration. And waypoints are generally useful anyway

Whole books are written about pathfinding, so I’ll leave it there. Much of it is a question of testing and tuning. But do try to do it well; bad pathfinding will cause a player to dismiss your game as “stupid” more quickly than just about anything else.

Low-poly trees (and other models, too).

Oooh, you’ve got a 3D engine. We’re all very impressed. The problem is, you’ve got too many objects to display with it, so you’ve decided to make them all with very few polygons. Everything in your game world will be strangely chunky, with odd edges, and they’ll look nothing like their counterparts in the real world. Trees, for example, will look like peculiar umbrellas, with all their branches at the same height, and disturbing things will happen as the camera moves past their foliage.

Don’t do it. It’s ugly and tacky. Get your pixel artists to do nice sprites instead, and stick ‘em on a single rectangle, if you don’t have enough polys to go around. Yes, they will pixellate as you get closer to them unless you MIP-map them, but so will the textures in your walls; we’re used to that. Remember how the creatures in Doom only had one sprite when they were lying dead on the floor? And when you went around to the other side of them they still were facing the same way, following you like the eyes in one of those creepy paintings? And remember how that was OK, and we didn’t really mind? The same is true for trees – even more so, in fact. Unless it’s significant to the gameplay somehow, it doesn’t really matter if a tree’s orientation is always the same way with respect to the player no matter where he is. It’s still better to have a nice -looking tree sprite than some weird blocky green umbrella thing.

Too few audio clips for a given situation.

I hate hearing the same damned audio clip over and over whenever a particular situation recurs in a game. It doesn’t matter if it’s just a confirming beep – in that case, it should always be the same sound, so it sends the same cue to the player – but if it’s a person speaking, it gets annoying very fast. I was the audio/video producer for Madden NFL Football for many years, so I’ve been guilty of this one myself on occasion. We had a limited amount of recording time with Mr. Madden each year, so we couldn’t record everything we wanted. The audio script for Madden NFL Football was typically about 75 pages long, and I would have written twice that much if I could.

If you’re going to have voice clips associated with particular situations (“I’m hit!” and so on), then record a lot of them. My own rule of thumb is that there should never be fewer than five audio clips for any situation, even the rarest; and for common events there should be at least two dozen or so. You don’t always have to record completely different sentences; sometimes the same sentence delivered with a slightly different emphasis will do. In the game, have the software keep a list of them and choose one at random to play when the situation calls for it, then mark it off the list. The next time the situation arises, choose at random from the remaining ones, and so on. When you’ve run through them all, reset the list except for the most recently played clip. That way the players will never hear the same clip twice in a row.

Birds that carry swords.

Argh! Our party is under attack by evil doom-chickens from the foul fowlyard of Kafoozalum! We’re in danger of being pecked to death a la Tippi Hedren. We hack. We slash. We cast spells of Oven Roasting+3. Some of us get hurt in a vague, numerical sort of way that doesn’t actually seem to involve blood or pain. Eventually we kill the last of the chickens (no evil creature is ever smart enough to run away, even when it’s hopelessly outnumbered; an admirable sense of duty for a bird). Searching the bodies we find that, as with all evil creatures, even blind cave-dwelling slimeworms, they’re carrying money and human weapons and armor around with them. How fortuitous! Evil doom-chicken #3 (second from the left, but otherwise indistinguishable from doom-chickens #1, 2, and 4) had a Great Big Nasty Sword of Serious Hurtfulness+5. Funny, I didn’t notice that sword anywhere on its feathery person while it was still alive. If it was so heavily armed, why didn’t it use it in the fight? Come to think of it, where was it keeping all this gold, too? In its gizzard? Eeeeew!

You get the idea.

Conclusion

Well, that’s my catalog of complaints for another year or so. If you’ve been responsible for any of these mistakes, bad game designer! No Twinkie for you! And if you’ve got a few personal peeves and game design gaffes of your own, by all means send me some E-mail and tell me about them. It’s time to start making a new list.(source:designernotebook)


上一篇:

下一篇: