作者：Ernest Adams

又一年，又一堆游戏设计失误。我的邮件文件夹又满满当当了，我总是希望收到新邮件。我太忙于自己的日常工作了，以致于没有时间玩我喜欢玩的游戏，所以每一年我总是指望靠忠实的读者帮我发现游戏设计师的“罪证”。

我们从Kris Kelly提的两个出自RPG的问题入手（为什么RPG的问题这么多？可能是游戏机制太复杂吧）。（请点击此处阅读本系列第1、2、3、4、5、6、7、8、9、11、12、13篇）

超能力的AI

Kris Kelly说得非常清楚：“在《上古卷轴：湮没》中，守卫非常擅长自己的工作，他们总是可以马上发现你干的‘好事’（游戏邦注：比如杀掉建筑里的某人、偷了某物），甚至当他们并不在那个区域时也不影响他们的超能力发挥。他们有时候会跑遍整个小镇只为抓住你。

“《湮没》的另一个问题是偷东西：商人会愉快地接受你从敌人的尸体上‘解放’出来的道具，但如果你拿着个偷来的东西，他们却连价都不等你开就拒绝你了。”

这些潜在的设计问题其实是不同的。超能力守卫本应该只能知道自己所在地的信息，但却知道了整个世界的信息。商人的道德标准很奇怪：他们宽恕行凶抢劫，却不原谅入室盗窃。这是怎么回事？

超时空传送的NPC

这个问题特别恶劣，因为它违背了玩家的完全合理的期待——敌人不可能同时呆在两个地方，这就破坏了玩家的高明策略。

还是Kris指出来的：“我只记得一个，但我肯定其他游戏也存在这个现象。在《无冬之夜2》中，有一场火巨人和红龙的战斗。你可以选择协助其中一方，但我决定先帮助红龙一方，等他与巨人战斗时，我就偷偷地洗劫他的巢穴。

“我跑到他的住所，准备偷东西，却迎面撞上满血、没有被巨人打死的红龙！我跟他打了一会儿，决定还是回去打巨人（因为更容易），却发现红龙又在那跟巨人对打了，还是满血的。”

红龙要么看好自己的家，要么在外面跟巨人混战。不能两件事都做。显然，设计师使用了两条龙，让玩家相信他们是一样的。太不公平了，太无趣了。

过度（或不充分）使用游戏设定的关卡设计

我认识多年的自由游戏设计师Pascal Luban写道：

“一个好的游戏设定做不成一款游戏，而是执行游戏设定的方式才成就一款游戏。最好的游戏设定本身支撑不起一款游戏，因为当你在相同的情境下使用太多次，再好的设定最终也会变无聊。这个问题在游戏中经常出现。

“关卡设计不是针对游戏的某个特定机制的使用创造一个特定的情境。那就是为什么关卡设计这么重要：因为它使设计师得以围绕一个给定的机制创造出多种变体和挑战。”

Pascal不愿意指名道姓，但他确实举了一款著名射击游戏的例子：玩家角色有非常强的跳跃和力量技能，但没有一个关卡好好利用这个设定。

我经常说，游戏设计师决定了游戏是由什么“积木”搭起来的，但关卡设计师才是真正用那些积木搭建游戏的人。如果关卡设计不能好好利用设定，那么设定就被浪费了。如果以完全相同的方式使用得太多次，那么这个设定就会变得乏味。

《Sonic the Hedgehog》是一个充分利用有限的设定的好例子。Sonic只有两套动作：跳跃和超速旋转，但关卡设计提供了足够多的变体，使游戏始终非常有趣。

不完整的或含糊的设计文件

我通常从玩家的角度出发寻找设计师的“罪行”，但游戏设计失误也会让开发团队的日子不好过。设计师没有指定的任何东西，程序员都要自己琢磨出来，这就浪费时间了。更惨的是，如果他们的想法不在一个方向上进行，那就可能导致不连贯的结果或甚至灾难性的后果。David Mullich提到一个他不得不拯救的项目：

“我重写了大部分游戏设计文件，包括把必要的逻辑理清楚的伪代码（感谢我的编程基础）。但甚至除了这些逻辑之外，设计师也为程序员留下大量其他细节——比如用于警告和确认弹出框的文本。

“另外，当程序员加班时，设计师不会留下来回答问题或确认自己的设计被正确执行。”

Mullich不得不重写设计文件显然反映了某个问题。我知道这在一些设计师当中是不普遍的，但每一支游戏设计团队都必须有人懂得编程。

无论我们谈论多少美学和游戏作为艺术（没有人比我更爱谈这些话题了），电子游戏就是软件，设计软件的人必须能够清楚地阐述关于算法系统之类的东西。

没有理由放空必须出现在对话模式中的文本。如果是，那只能说明设计师在偷懒。设计这种文本可能很无聊，但那也是工作的一部分。

设计师不懂技术限制

在我们讨论惹恼开发团队的设计师的同时，也说说不懂目标硬件的功能范围的设计师。

Gregg Tavares写道：“例如，许多设计师可能希望屏幕上同时出现25个敌人，但引擎只支持最多10个。所以他们就强迫程序员花几个月的时间攻击引擎的技术限制，而不是制作游戏。

“我想如果你看看大部分优秀的游戏，你会发现那些游戏的设计师总是想法克服严重的技能限制。《Metroid Prime》就是一个经典的例子。还有《塞尔达传说》系列。”

当好莱坞于90年代初开始入侵这个行业时，这是一个严重的问题——许多所谓的“游戏设计师”从电影行业空降到自己一无所知的游戏行业，他们用不切实际的要求带领开发团队。他们的无知是为什么入侵失败的原因（之一）。但这个过程浪费了许多资金。

了解你的硬件。这是必须的。如果你不是技术达人，那么你最好问问程序员并相信他们告诉你的，因为与他们争论并不能改变什么。

嘲笑玩家

我已经在我的《玩家独立宣言》中提过这一点了，但这种事一直出现，应该也列入设计师的“罪名”之一。我不跟陌生人玩网络游戏，因为我不喜欢他们的粗鲁，而且他们往往没什么竞争精神。我也不喜欢单机游戏嘲笑我，我不是唯一这么觉得的人。Owen Clark写道：“不要嘲笑我！如果我在游戏的某部分失败了，没有必要在我的伤口上撒盐！”

我知道什么是善意有趣的嘲笑。作为《Madden》的资深玩家，我知道正确地玩这款游戏的方法是，跟一大群朋友一起闲扯。不过这里的关键词是“朋友”。朋友知道玩笑的度在哪里。

当游戏嘲笑玩家时，那并不能让玩家觉得游戏是在开善意的玩笑，反而像在冒犯，像在侮辱，像是设计师在嘲笑玩家，这是不公平的，因为一切都控制在设计师手中，玩家没有办法反击。不要嘲笑玩家的失败。否则，游戏设计师就显得太幼稚了，太自以为是了。

必要但无法获得的道具

还是刚才那个Owen Clark，他写道：“不要提供必须但可以不拾取的道具！如果我必须有一种我应该在早期的关卡中获得之后很重要的道具，那么这种道具应该是强制获得的。没有‘如果’、‘但是’，不要让这种道具的拾取可以自由选择。玩了三四个关卡后从头再开始，因为发现错过了一件重要的道具，还有比这个更让人郁闷的事吗？”

如果你没有给玩家那个通达必需的东西，那么这个游戏就是无法获胜的，这当然是糟糕的设计。如果玩家可以选择放弃某个关键的东西，且不能返回再找回，那么这个游戏也是不可获胜的——这就是为什么许多冒险游戏允许你捡起来却不准你扔掉。”

（非常）老游戏《Monty on the Run》要求玩家在游戏开始前选择几种道具。如果玩家选择错误的道具，游戏就不能获胜，这真是一个严重的设计缺陷。

Clark希望拿到技术上非必要但极其有价值的东西；他引用《Crysis》中的狙击视野作为例子。玩家如果没有它就面临着严重的劣势。我不知道是否可以把隐藏的狙击视野归咎于游戏设计师；我认为这是调节游戏难度的问题。如果游戏没有它就接近不可玩，有了它就非常容易玩，那么这个狙击视野本身的价值就过头了（或游戏没有它就太困难了）。

刷游戏

Ben Matson写道，“刷”玩法的历史可以追溯到2004年，可能到现在才完全明显，但必须列为设计师的失误。他写道：“花了那么多个小时打小怪，这样你就可以花双倍的时间打大怪，总让我感到非常恼火。我喜欢MMORPG，但最终一切都只是攒经验。应该有更好玩的东西。比如《无尽的任务》、《Dark Age of Camelot》等等……”

不只是MMORPG有这个问题，单人在线RPG也有这个问题。早期的RPG有随机生成的关卡，玩家除了刷怪就没有太多事可做了。在这里不批评这些游戏是因为它们面临严重的存储空间的限制，但即使是那样，有些好游戏也成功地解决了这个问题。

如果提供的玩法够丰富（如冒险游戏），那么节奏慢一点也无所谓；如果玩法够刺激，只有一种也无所谓（如《俄罗斯方块》）。但如果你的游戏又慢又沉闷，你就完蛋了。简单地说，你的游戏就只剩下“刷”了。无趣、过时、多余。

如果玩家真的想刷游戏，他们可以玩《Progress Quest》。

射击游戏中的魔法掩体

Pascal Luban写道：“有时候，你可以看到敌人身体的一部分从掩蔽物后面伸出来，而你的子弹却打不了他。那是因为当敌人在掩蔽物后面时，设计师不希望你打到敌人。当只是几像素露在外面时，那就无所谓，但半个头都出来了，还不让打？太令人郁闷了！”

确实。随便一个军人都可以告诉你，把头伸出战壕外面并不好，即使你的身体还在里面。无论是设计师做了无论身体露出多少都能提供保护的魔法掩体，还是物理和图像引擎出了错，都是不能接受的。

如果在你的视野范围内能看到某物，你就应该能射击它。（在第一版《Gulf War》中，美国坦克摧毁了自以为躲在掩蔽物下面的伊拉克坦克。不存在所谓的“完美掩体”这样的东西。）

总结

回头再看了一下这篇文章，我发现上述几条设计师失误没有之前的那么搞笑了。我仍然觉得这些建议提供了有价值的东西——应该注意的错误，应该避免的问题。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Bad Game Designer, No Twinkie! X

By Ernest Adams

Another year, another collection of game design errors. I’ve got a whole mail folder full, and I’m always eager to hear about more. I’m so busy with my regular work that I don’t get the chance to play the variety of games that I would like to, so every year I count on submissions from you loyal readers to find the broken ones for me.

We’ll start with two from role-playing games sent in by Kris Kelly. (Why are so many Twinkie Denial Conditions in RPGs? Complex game mechanics, probably.)

Psychic AI

Kris’s own words are perfectly clear: “In The Elder Scrolls IV: Oblivion, the guards are so good at their job, they instantly know when you’ve committed a crime (i.e. killed someone in a building, stolen something), even when they were never in the area. They’ll sometimes run all the way across town to try and arrest you.

“Another Oblivion issue is the stolen items thing: merchants will happily accept items you’ve ‘liberated’ from the corpses of your enemies, but if you take a candlestick in, you can’t even offer it to them, never mind get refused.”

The underlying design problems are actually different here. The psychic guards have access to global information when they really should have access only to information about their local region. The other is that the merchants have a peculiar sense of morality: they condone mugging but not burglary. What’s that about?

Teleporting NPCs

This one is particularly bad because it violates the player’s perfectly reasonable expectation that an enemy can’t be in two places at once, and ruins a clever ploy.

Here’s Kris again: “I can only think of one occurrence of this, but I’m sure it happens in other games. In Neverwinter Nights 2, there’s a large battle involving fire giants and a red dragon. You are expected to fight on the side of one or the other but I, being a sneaky type, decided to start the battle on the side of the red dragon and then sneak out while he was fighting the giants and raid his lair.

“I wander over to his abode, loot sack at the ready, only to be confronted by a fully-healed un-harrassed-by-giants red dragon who is hell bent on fighting me, I beat him up a bit (and he reciprocates), then decide to go back to the giant fight (because it was easier) and there he is again, fighting the giants and fully healed once more.”

Neverwinter Nights 2

Look: a dragon is either guarding its lair or it’s fighting giants somewhere else. Not both. Clearly the designers implemented two dragons and led the player to believe they were both the same. Not fair and not fun.

Level Designs that Over- (or Under-) Use a Game Feature

Pascal Luban, a French freelance game designer I’ve known for many years, writes:

“A great game feature does not make a game, it is the way it is implemented that does. The best game feature is not enough to support a game by itself, because the best feature eventually becomes boring when you have done it too many times in the same circumstances. I see that on a regular basis in games.

“The level design does not create unique situations tailored to the use of the unique game mechanics of the game. That’s why level design is so important: because it allows designer to create diversity and challenge around a given mechanism.”

Pascal was reluctant to name names, but he does mention as an example a famous shooter in which the player has super-jump or super-strength abilities, but none of the levels make good use of it.

I’ve often said that game designers determine what sorts of “LEGO blocks” the game will be made from, but level designers actually construct the game out of those blocks. If the level design doesn’t make good use of a feature, then the feature is wasted. If it is used too many times in exactly the same way, then it becomes tiresome.

An example of good design with a limited feature set is Sonic the Hedgehog. Sonic only had two moves, jumping and super-spinning, yet the level designs offered enough variety to keep the game interesting.

Incomplete or Ambiguous Design Documents

I normally think of Twinkie Denial Conditions from the viewpoint of the player, but game design errors can make life hard for the rest of the development team too. Anything that a designer doesn’t specify, the programmers will have to figure out for themselves, which wastes time. Worse, if they start pulling in divergent directions, the results will be incoherent or even disastrous. David Mullich writes of a project that he had to rescue:

“The original game designer typically described only the main flow for any system or UI. He didn’t describe the alternate flow or extreme circumstances, leaving it to the programmer to identify what those situations were and how to handle them.

“I wound up rewriting much of the game design document so that it included pseudo-code (thanks to my programming roots) that specified the required logic a little more clearly. But even beyond the logic, the designer left a lot of other details — such as the exact text to use for alert and confirmation pop-ups — to the programmers.

“Plus, when the programmers stayed late, the designer did not hang around to answer questions or ensure that his design was being implemented correctly.”

The fact that Mullich had to take the project over is evidence enough that things weren’t working out. I know this is going to be unpopular with some designers, but every game design team must have somebody with programming experience on it.

No matter how much we talk about aesthetics and games as art (and nobody loves such talk more than I), video games are software, and to design software requires the ability to communicate clearly about algorithmic systems.

And there’s no excuse at all for leaving out the text that needs to appear in dialog boxes. That’s just laziness. It may be boring, it’s part of the job. Bad game designer! No Twinkie!

Designer Ignorance of Technical Limits

While we’re on the subject of designers who annoy their dev teams, let’s include those who don’t understand what their target hardware can actually do.

Gregg Tavares wrote: “I know lots of designers who might, for example, want 25 enemies on the screen at once when the engine only supports only 10 at most. Or they want the engine to be able to see forever. Then they force the programmers to spend months on technical engine design instead of fun gameplay.

“I think if you look at most of the best games, the designers figured out a way to be creative within severe technical limits. Metroid Prime was a perfect example of designing within technical limits. So is the Zelda series of games.”

Metroid Prime 3: Corruption

This was a serious problem when Hollywood tried to take over the industry in the early ’90s — a lot of so-called “game designers” arrived from the film world knowing nothing about how computers actually work, and they drove their development teams mad with unrealistic demands. Their ignorance is one (of several) reasons why the takeover failed. But a lot of money went down the tubes in the process.

Know your hardware. It’s compulsory. If you’re not a technical person, then you’ll have to ask your programmers and trust what they tell you, because arguing with them isn’t going to change anything.

Mocking the Player

I already listed this one in my Bill of Player’s Rights, but it bears repeating as a Twinkie Denial Condition. I don’t play online games with strangers, because I dislike their rudeness and poor sportsmanship. I also don’t like it when a single-player game mocks me, and I’m not alone in this. Owen Clark wrote in to say, “Don’t mock me! If I fail a specific part of the game or whatever there’s no need to rub salt in the wound!”

Now I realize there’s fun in smack-talk. As a long-time member of the Madden team, I know that the right way to play Madden is with a lot of friends around all talking trash. The key word, though, isfriends. Friends know when enough is enough.

When a game mocks the player, it’s not jovial banter, it’s rude, like insulting a stranger. It’s really the designer mocking the player, and that’s not fair because the designer holds all the cards and the player can’t respond. Don’t mock the player for his failures. It’s juvenile and self-indulgent.

Essential but Unobtainable Items

The same Owen Clark also wrote, “Don’t make must-have items avoidable! If I need an item that I’m supposed to pick up in the early levels of a game which is then vital later on, then it should mandatory that I get this item. No ifs, no buts, no making the item optional but I have a huge disadvantage. There is almost nothing more annoying than having to restart a game from scratch after three to four levels because you missed something in one of the early levels… just give me the damn thing.”

If you fail to give the player something that she absolutely must have to win the game, then the game is unwinnable and that’s a bad design for sure. If the player has the option of leaving something critical behind when she passes through a one-way door, it also makes the game unwinnable – this is why many adventure games let you pick things up but don’t let you put them down again.

The (very) old game Monty on the Run required the player to choose some items to take with her before the game started. If she chose the wrong ones, the game was unwinnable at a later point, a truly severe design flaw.

There’s a fine line here, because Clark wants to be given things that are not technically essential but extremely valuable; he cites the sniper scope in Crysisas an example. The player is at a major disadvantage without it. I don’t know if I would really call hiding the sniper scope a Twinkie Denial Condition; I think it’s a problem in managing the game’s difficulty. If the game is nearly impossible without it and reasonably easy with it, then the sniper scope itself is more valuable than it should be (or the game is too hard without it).

Crysis

Grinding

Ben Matson wrote to me about this all the way back in 2004, and maybe it’s completely obvious by this time, but it needs to be in the No Twinkie Database, so here it is. He said, “Sinking hours and hours of your life killing gnoll smallfists just so you can spend twice as long on gnoll bigfists has always been a huge annoyance to me. I love MMORPGs, but eventually it seems to all reduce to filling experience meters. There has to be something better. Examples are EverQuest, Dark Age of Camelot, etc…”

It isn’t just MMORPGs, but single-player offline RPGs as well. The early RPGs had randomly-generated levels and there wasn’t much to do in them but grind. They get excused because they had to fit on a few floppy disks; but even then, the better games managed to avoid it.

A game can get away with being slow-moving if it provides variety in the gameplay (e.g. an adventure game); and it can get away with only offering one kind of gameplay if it’s exciting (e.g. Tetris). But if your game is both slow and dull, you’ve screwed up. And that’s grinding in a nutshell. Boring, outdated, unnecessary.

If players really want to grind, they can play Progress Quest.

Magic Perfect Cover in Shooter Games

We’ll go back to Pascal Luban for one last item. He writes, “Sometimes, you can see a section of an enemy’s body sticking out behind or above a cover and your bullet cannot hit it. That’s because the designers don’t want to you to be able to hit an enemy while he’s in cover. That’s OK when a few pixels stick out but when it is half of the skull, it gets very frustrating!”

Yes it does. Any soldier can tell you that it’s not a good idea to stick your head out of the trench even if the rest of your body is still in it. Either the designers have created some kind of magic perfect cover that works no matter how much of the target’s body is sticking out, or there’s something wrong with the relationship between the physics and the graphics engines.

If you can see something within range, you ought to be able to shoot it. (In the first Gulf War, an American tank destroyed an Iraqi tank that thought it was under cover by firing through a sand dune. There’s no such thing as perfect cover.)

Conclusion

Reading back over this, I see these Twinkie Denial Conditions aren’t all as funny as some have been in previous columns. Still, I think there are some valuable suggestions here – mistakes to watch out for, errors to avoid. Keep sending them in to notwinkie@designersnotebook.com! Be sure to check the No Twinkie Database first, though; after ten columns I have already covered many of the most egregious ones.(source:designersnotebook)