作者：Ernest Adams

当10多年前我写本系列的第一篇文章时，我以为它只是我的个人吐槽日志——今天发表了，明天就忘记了。我没有料到会有这么多人这么认真的看待它，甚至热情地提供自己的案例。

去年的专栏结束后，我又收到了大量来自沮丧的玩家和开发者的新建议，所以我继续整理写下了这篇文章。（请点击此处阅读本系列第1、2、3、4、5、6、7、8、10、11、12、13篇）

没有说明胜利和失败条件

这太糟糕了，最糟糕的情况之一。除非这款游戏是开放沙盒游戏如《模拟人生》，否则玩家必须知道自己做什么能达到胜利条件，以及甚至更重要的，必须避免什么——失败条件。

Tim Elder of Blue Alto写道：“我玩《Dawn of War：Winter Assault》中的单人任务“Eldar”时，任务要求我炸掉兽人的能量发生器以分散他们的注意力。第一次做这个任务时，我阅读了任务概要，得知我们没有足够的军队消失所有兽人，所以我们得引爆发生器把兽人吸引过去，然后再绕过他们。”

“我的军队逼近发生器，沿路杀死了一小部分兽人，突然间跳出一个窗口告诉我‘任务失败’。哈？怎么回事？”

所以他尝试了其他方法，还是得到相同的回应。一次又一次。“重新加载了一次又一次，我仍然不知道我为什么任务失败，甚至摧毁那该死的发生器后我也仍然不懂。明确的胜利和失败条件清楚地写出来，这样玩家才知道必须做什么，禁止做什么。”确实是这样。这是最基本的设计原则之一。糟糕的游戏设计师！

有时间限制的试玩版

我吐槽的大部分与拙劣的玩法、操作、平衡性或内容有关，而这一条稍稍特殊——它可能是一个营销决定而不是一个游戏设计的问题。Rob Allen写道：“以《Harry Potter and the Order of the Phoenix》的试玩版为例。我正在欣赏学院的美丽风光时，突然看到‘你还有1分钟！’我只好匆匆忙忙地做我应该做的事，然后，游戏弹出一个屏幕叫我购买。我现在还会想买吗？”

“叫我恼火的是，通过假设我非常想要游戏来消耗我的宽带，让我看到引入画面，然后就叫我购买……甚至没有让我玩到我不可能在那好不容易挤出来的10分钟里玩完的迷你游戏。”

现在，你可能会说：“混蛋！免费的东西你还嫌弃什么？”但我可不敢苟同。许多网页游戏都是免费的；不要为糟糕的体验找借口。Bob说的宽带切中要点了。美国Comcast电信公司宣布，它正在严格限制用户的数据传输，我们必须好好计算我们准备下载的试玩版有多少字节。如果它们占用了我们付费购买的下载流量，那么它们就不是免费的了。

假设《毁灭战士》的试玩版只允许玩家一直玩到第一关的中间，然后就告诉玩家“时间到了，请购买游戏。”玩家肯定会气得恨不得烧了驱动。肯定不会有那么多玩家购买的。

明显的“换汤不换药”

Patrick Perrault写道：“把老引擎（或整个游戏）重复利用做成新的游戏，这在手机游戏领域是惯例了。”

“虽然有些公司（比如Gameloft对《Splinter Cell》、《波斯王子》以及所有它的平台游戏所做的）每一次重制都添加了新功能，确实做得不错，但有些发行公司只不过是增加了不同的图像和稍稍修改了旧关卡。有些非常非常无耻的发行商甚至只修改了游戏的名称和启动画面。”

“你无耻，至少不要表现得那么明显！如果你对一款游戏换汤不换药，保证你换掉了旧标题和制作人员名单才是明智之举。另外还要保证原版游戏中的角色不会在新游戏中出现。这几点都做不到的话，就不要指望玩家再买你的游戏了。”

让旧角色和制作人员出现在新游戏中，是我听过的最可笑的失误之一。没有比这更粗心马虎的了吧。唉，如果这只是一个新问题的话。

90年代早期的某些公司就因制作Genesis和SNES的“换皮”游戏而招徕恶名。现在，这个举动也不仅限于手机游戏；到处都是山寨射击游戏。我认为FPS的换皮游戏也实在太多了。

保存游戏时崩溃？玩完了！

有个自称Ilya的人写道：“如果你正在保存游戏时遇到电脑崩溃，那么你的游戏也完了。既然有一个.sav的文件，当你完成时就删除它，为什么不能多一个.sa2文件？”

Ilya说的没错——这是一年级学的电脑科学。除非储存空间有限，否则应该有一个基本的警告告诉你，不要覆盖某人的旧数据除非你知道他们的新数据已经被安全地保存起来了。（如果有储存空间，你可以提醒玩家他们的旧存档正在被覆盖—-还要有一个“不再提醒”的选项框。）这执行起来太简单了，所以把它做好吧。

帮倒忙的AI同伴

在格斗模拟游戏，我经常抱怨愚蠢的AI同伴——他们本应该看着你的后面，但相反地，他们在战斗开始的前十秒就被干掉了。Steven Taylor指出，这个问题在护送任务中普遍存在，在护送任务中，你护送的根本就是一傻逼。事实上，我认为所有AI控制的同盟角色都是这样。

他写道：“如果被护送的人老实地跟在主角后面，或者呆在一个地方，也不会出现问题。但是，被护送的角色总是乱跑，导致玩家掌控不了局面，不得不时时提防AI又做出什么蠢事。当被护送的角色冲到枪林弹雨中去，什么策略都不管用了。”

Shawn Lucas举了一个《上古卷轴：湮灭》的例子：“我记得有一个任务是叫玩家救一个被狂热教徒绑架的姑娘。到了教徒的窝点，把姑娘从笼子里放出来，我正要与姑娘一起逃走。然而，比起逃出虎口，这个姑娘似乎对攻击恶棍们更感兴趣。她一见到其中一个教徒就打他，还把其他敌人吸引到我们的位置。结果是，她对付不了歹徒，我也不是他们的对手。数次死亡和重新载入后，我才一个一个地收拾掉敌人，通过最简单的战术，但这让我再也不想玩这款游戏了。”

他又举了一个例子：“在《GTA：San Andreas》中，有一个任务要求玩家一边开越野车一边射击火车上的敌人。越野车由玩家开，敌人由坐在车后座的AI同伴攻击。然而，AI同伴经常不瞄准敌人，而是乱打一气。这个任务还有时间限制，同伴的恶劣表现使任务更加困难。”

在电影中，你偶尔可以看到这种为了搞笑而出现的情景：主角因为一个帮倒忙的同伴而陷入麻烦。（《Indiana Jones and the Temple of Doom》中的Indiana Jones的同伴Wilhelmina就是一个例子）但电影是不同的——无论这个同伴如何帮倒忙，剧情仍然可以进展。

作为玩家，如果我不断地因为我那猪一样的队友而被耽误或被杀死，那么我会很有冲动自己把这个同伴解决掉。我拒绝对抗愚蠢的AI敌人（这也是糟糕的设计师的失误），但我更加拒绝与猪一样的AI同伴合作和替它收拾烂摊子。如果你不能把AI NPC变得聪明，至少让他们警觉和可预测。

虚假的交互性

这是另一个大问题：一个非常非常错误而糟糕的问题毁了原本应该不错的游戏。我借用Jessica的话来解释它：“我觉得这破坏了《Shadow of the Colossus》的结局——在其他游戏中也有这个问题：游戏设计师允许玩家在某个事件中控制自己的角色，但无论玩家做什么，事件的结果只有一个。因为这个结果会发生并没有那么明显，所以当它发生时，不想要这种结果的玩家就会重玩这个事件，但结果还是一样。”

“如果结局只有一个，那么就做成过场动画吧。如果玩家可以控制角色，那就让玩家的行动发挥作用，导致不同的结果。如果让玩家‘玩’事实上是过场动画的过程就是游戏的‘玩法’的一部分，那么就把它贯彻到整个游戏中吧，这样我们就知道游戏将会这样，不要在结尾让我们惊讶。”

John Funderburk补充道：“我也讨厌《古墓丽影》和《生化危机4》的‘交互’过场动画。‘当我要求你时你就按下按键’——这是什么玩意儿？”人们玩游戏是为了克服挑战、做出有意义的选择和展现自我的。不能满足这三种需求的体验就不是交互性的。我们希望当我们操作玩家角色时，玩家角色的活动会多多少少影响游戏世界。如果不能影响游戏世界，那么假装具有交互性就没有任何意义了。

但提醒一句——这么说并不是反对游戏中的线性剧情。对于线性故事，克服挑战使玩家进展剧情（通常以过场动画的形式），即使玩家不可能改变故事的内容。那无所谓——克服挑战的行为本身解锁了故事的下一章节，玩家知道也理解这一点。

当我们让玩家相信自己的行为是有影响的，然后结果却非如此，但玩家已经浪费了那么多时间做尝试，那么问题就产生了。如果你想叙述一个悲剧故事——注定死亡的主角或无法克服的困境，那么你就不要对玩家说谎，告诉玩家主角可以摆脱这样的命运如果他够努力的话。

为了让悲剧真正成为悲剧，观众必须提前知道主角必死，或至少不需要耗费那么长的时间逃避命运后才意识到。我们仍然可以制作关于拿破仑或越战中的美国人的游戏，即使玩家知道最终结局就是失败。

手柄-鼠标/键盘的转换问题

这是一个典型的错误，而且最令人惊讶的是，人们还是坚持犯这个错误。Jacek Wesolowski写道：“破坏我兴致的一个因素是，有些开发者把鼠标和键盘当成次级装置。它们和手柄之间的差别很大，因为使用方法不同。”

“例如，键盘更合适‘面板’界面，因为可以把键赋给各个活动；而手柄依赖‘深刻的’多样性—-按键组合和序列。简单地把按键映射给键盘或相反地，通常是不够用的。但这正是许多开发者所做的。”

“《刺客信条》就是一个好例子。当用手柄玩时，它的操作方式非常合理，但键盘/鼠标映射就非常不灵便和不直观了。甚至更糟，开发者给鼠标的灵敏度强加了一个人为的、严格的限制，也许是为了把它与手柄的最大转向率匹配起来。这不是手柄的问题，因为瞬间的180度转向是可行的，在玩家角色的背后看也是可以的。换句话说，更高的鼠标灵敏度不会给我任何真正的优势，只是能够玩得舒服。在玩时，我觉得我偏好的操作设备被故意破坏了。”

Jacek指出了我是PC玩家而不是游戏机玩家的原因之一：“我不太会协调连击，我更喜欢分离的按键，每个按键代表一个事物（或更好地，智能键）。虽然不能因为我的个人偏好就说是设计师的失误，但糟糕的恍如鼠标/操作杆转换确实是。

鼠标型界面不适用于操作杆，操作杆型界面也不适用于鼠标。它们的操作是不一样的。鼠标是指示点击设备。操作杆是操纵设备。

鼠标不能像操作杆那样自动返回中心区，操作杆不能像鼠标那样无限地朝同一个方向移动。如果你要做一个适用于这两种设备的系统，那么就不要让其中一种的特权压过另一种或者不要让一种适应另一种。要分别为两种设备设计UI，就好像它们是唯一支持的输入设备，尽量把各种做到最好。

如果你发现这让操作杆的玩家获得超过鼠标玩家的优势，或反之，就不要通过怠慢一方的操作系统来解决问题！设置一种玩家可以自己修改和达成一致的均等系统。它适用于高尔夫球；我不知道为什么游戏不能也这样。

另外，本着“如果你不能做好就不要做”的原则，放弃支持你不能好好执行的设备。这总比卖给玩家恶劣的体验来得好。

破坏既定原则

有个自称“One Man Science Team”的人写道：“我认为可以称得上糟糕的设计师的‘恶行’的一个设计缺陷是，为了达到目标，关卡设计师无理由地要求玩家破坏之前确定下来的规则和风险相关的后果。甚至有时候这么做的游戏还被认为是‘好的’——为了找到原版《Donkey Kong Country》中的所有秘密，你必须跳进每一个关卡中的每一个洞。”

“如果你不先看FAQ，你会失败很多次。另一个例子出现在许多RPG中，有一种不可能的战斗，你努力争取胜利不仅会浪费匹治疗药水还会受到惩罚，而输了反而得到奖励，因为那正是故事希望你做的。”

他继续说道，他不介意关卡设计师时不时地改变规则，但他们必须给点要改变的暗示——如果有视觉上的暗示，事情就大不一样了。

“但如果完成开发者预料/期望玩家可能会争取的目标（找出所有秘密）包括破坏设计师之前告诉玩家的游戏规则（玩家因此屡受惩罚！），那么存在于玩家和设计师之间的契约就被破坏了。”

确实。不像桌面游戏，电子游戏玩家一开始并不知道规则——他们发觉通过尝试-犯错来学习，这意味着他们必须信任设计师不会骗自己。

死前最后一刻才能保存

我们把这个简单的问题放在最后。Nathan Sturtevant在Alberta大学教授计算机科学，他写道：“许多允许储存的游戏让我困扰的是，它们在你的角色死亡的时候让你保存游戏。我想我最后见到这个问题是在《无冬之夜》中，我很肯定我在其他游戏中也见过。在《无冬之夜》中，这种事可能发生在战斗中，也可能发生在你掉进陷阱里的时候。加载完游戏后发现自己已经死了，真是让人沮丧啊。”

我自己也被这个问题折磨过。现在，我坚决主张允许玩家随时保存。如果玩家仍然有几点生命值，让电脑预测死亡是不可避免的可能非常困难。（如果已经死了，那当然不应该保存）

但我也认为应该让玩家做多个存档。是的，玩家在必然死亡的最后瞬间保存—-然后他可以恢复更早之前的存档。问题解决了。如果你的储存空间只允许保留一份存档，那么保存点可能是个更好的选择—-但要确保玩家保存时命值绝对是安全的。

总结

以上。我总是欢迎更多建议，尽管去年我没能指名帮助我的读者，但我还是要感谢他们，并保证做得更好！（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Bad Game Designer, No Twinkie! IX

By Ernest Adams

When I wrote the first Bad Game Designer, No Twinkie column over 10 years ago, I thought of it as nothing more than a personal list of gripes — published today, forgotten tomorrow. I didn’t expect so many people to take it seriously, and to be so eager to offer examples of their own.

After last year’s column I got a flood of new suggestions from frustrated players and developers, so here are nine new Twinkie Denial Conditions for the ninth installment of Bad Game Designer, No Twinkie!

Failure to Explain Victory and Loss Conditions

This is a bad one — one of the worst. Unless the game is an open-ended sandbox toy like The Sims, the player must know what he’s working towards — the victory condition — and, even more importantly, what he must avoid — the loss condition.

Tim Elder of Blue Alto (big up for using your real details, Tim) writes, “I was playing through the single player missions in the Dawn of War expansion Winter Assault when I got to an Eldar mission that involved blowing up an Ork power generator to cause a distraction. My first time through the mission, I read the mission briefing, which stated that we didn’t have enough troops for a full assault, so we had to blow up the generator to bring the Orks to it, and we could go around them.”

“My troops approached the generator, killing the small numbers of Orks along the way, and all of a sudden the screen faded out and a message popped up saying ‘You have failed the mission.’ Huh? Why?”

So he tried something else, and got the same response. And again, and again. “Reload after reload and I still have no idea why I failed the mission, even after once having destroyed the stupid generator. Surely win and loss conditions should be well spelt out, so that the player knows what they need to do, and avoid doing.” You’re damn right they should. It’s one of the most basic principles of design. Bad Game Designer! No Twinkie!

Time-Constrained Demos

Most of the Twinkie Denial Conditions I write about have to do with poor gameplay, controls, balancing, or content. This one’s a bit unusual — it may even be a marketing decision rather than a game design issue. Rob Allen writes, “Take the Harry Potter and the Order of the Phoenix demo, for example. I was admiring the tasteful surrounding of the academy when, lo and behold, ‘You have one minute remaining.’ I dashed all over the place to find what I was supposed to do and, again, got the screens telling me to buy the game. Why would I want to now?”

EA Games’ Harry Potter and the Order of the Phoenix

“The thing just annoyed me by presuming that I wanted the game bad enough to eat up my bandwidth to get the intro screen, and that would make me buy it… Don’t even get me started on the pointless mini-game that I could not finish that sapped up 10 minutes.”

Now, you might say, “Tough! You can’t complain about something that was free.” I would disagree, though. Lots of web-based games are free; that’s no excuse for delivering a crummy experience. And Rob’s got a point about bandwidth. With Comcast announcing that it is placing a hard limit on users’ data transfers, we’re going to have to think carefully about how many gigabyte-sized demos we’re prepared to download. If they eat up the download allocation we have to pay cash for, demos are no longer free.

We already know the demo is going to be limited anyway — it’ll only include part of the content and part of the gameplay. Why force us to quit after a fixed amount of time? The longer we play, the more likely we are to get involved and want to see more. Compare this with Doom. Id gave you the first ten levels, which you could play as much as you wanted.

It was brilliant and made them a fortune. Suppose the Doom demo had stopped in the middle of the first level with the words, “You’re out of time. Go buy the game.” People would have yanked the floppy disk out of the drive and set fire to it. They certainly wouldn’t have bought it in such numbers.

Obvious and Cheap Reskins (also known as Cookie-Cutter Games)

Patrick Perrault of Airborne Entertainment writes, “It’s common practice in the mobile space [i.e. cell phone games] to take an existing engine (or entire game) and reuse it to do another, usually branded, game.”

“While some companies (like Gameloft with games like Splinter Cell, Prince of Persia, and all its platformers) do a good job at adding new functionalities to each iteration, other publishers will stop at loading different graphics and modifying existing levels. Some really, really greedy publishers will even stop at changing only the game’s title and splash screen.”

“But if you want to be greedy, at least be smart! If you are reskinning a game, making sure you remove all mentions of the old title in the credits is smart. And so is making sure the characters from the original game do not appear in the new game. Failure to be smart is sure to result in players not buying any more of your games.”

Leaving old characters and credits to turn up in the new game is one of the funniest screwups I’ve ever heard about. It doesn’t get much more sloppy than that. Alas, if this were only a new problem.

Certain companies in the early ’90s were infamous for turning out cookie-cutter platform games on the Genesis and SNES. And it’s hardly confined to the mobile space these days; there are plenty of clone shooters around. I think the FPS is the side-scroller of this generation: there are way too many of them.

Computer Crashed While Saving? Game Over!

Someone named Ilya writes, “If you save and the game crashes while it’s saving, your game’s corrupt. Why not save a file with a .sa2 extension if there’s one with a .sav one and delete the .sav when you’re done?”

Ilya’s right — this is freshman year computer science. Unless storage space is limited, basic caution says you don’t overwrite someone’s old data until you know their new data has been safely stored away. (If there is a shortage of space, you can warn the user that their old save is being overwritten — along with a “don’t show this warning again” checkbox, of course.) The implementation is trivial, so get it right.

Friendly AI Characters Who Do More Harm Than Good

I’ve often complained about stupid AI wingmen in flight simulators — they’re supposed to be watching your back, and instead they get killed in the first ten seconds of battle. Steven Taylor points out that this can be generalized to include escort missions in which the character you’re escorting is an idiot, and in fact I think it really applies to any AI-controlled ally character.

He writes, “If the person being escorted simply followed the main character, or stayed in one place, this wouldn’t be a problem. Instead, the escorted character runs around unpredictably in such a way that the player loses control over the situation and instead has to react to whatever nonsensical move the AI makes. Tactics are thrown out the window as the escorted character runs into the next source of gunfire.”

Shawn Lucas independently offers a good example from The Elder Scrolls IV: Oblivion: “I remember a quest where the player was tasked with rescuing a peasant girl who had been kidnapped by a group of cultists. After journeying to their hideout and freeing the girl from her cell, I attempted to flee with the prisoner. However, it seemed that the girl was more interested in attacking the hostile cultists than she was in getting to safety. The second she spotted one of the cultists she attacked him and drew other enemies to our position. As it turned out, she was no match for them , nor was I. After numerous deaths and reloads, I was able to take out the cultists one by one, by means of cheap tactics, but it put me off from playing the game.”

Rockstar Games’ Grand Theft Auto: San Andreas

And he had another example as well: “There was one mission in Grand Theft Auto: San Andreas that required the player to follow alongside a train on a dirt bike while shooting enemies who were riding the train. The dirt bike was driven by the player and the friendly AI sat on the back and had to shoot the enemies. However, the friendly AI would often choose not to shoot at the enemies, despite having a clear shot. There was also a time limit for this mission, which made my partner’s lackluster performance all the more aggravating.”

You occasionally see this played for laughs in movies, where our hero is stuck with an ally who is more trouble than he’s worth. (Indiana Jones’s sidekick Wilhelmina “Willy” Scott from Indiana Jones and the Temple of Doom is a good example.) But a movie is different — it goes forward no matter what.

As a player, if I’m constantly being held up or killed on account of my moronic companion, I’m strongly tempted to shoot him myself. I object to confronting stupid enemy AI (Stupid Opponents is a Twinkie Denial Condition too), but I really object to having to cooperate with, and compensate for, bad AI that’s supposed to be on my side. If you can’t make your AI NPCs smart, at least make them cautious and predictable.

Fake Interactivity

This is another biggie: a very, very wrong and bad TDC in an otherwise good game. I’ll let a lady named Jessica explain it: “This damaged the ending of Shadow of the Colossus for me — and it happens in other games too. You allow the player to control their character during a sequence, but no matter what the player does, the sequence can only go one way. Since it’s not clear that it would ever happen, when it does happen, it makes you want to try the sequence again, but that only gives you the same result.”

“If it can only go one way, make it a cut scene. If the player has control of the character, let the player’s actions make a difference, and affect the outcome. If it’s a part of the game’s ‘style’ to let the player ‘play’ through what are essentially cut scenes, then make it that way throughout the game so that we know the game is going to be this way, and don’t just surprise us with it at the end.”

John Funderburk adds, “I also hated Tomb Raider Legend’s and Resident Evil 4′s ‘interactive’ cut scenes. ‘Push the button when I tell you to’ — what game is that?” People play games in order to overcome challenges, make interesting choices, and generally express themselves. Game sequences that don’t provide any of those experiences shouldn’t be interactive. We expect that when we have control of the avatar, the avatar’s actions will affect the game world in some way. If it affects the game world in no way at all, then there’s no point in pretending that it’s interactive.

A word of caution, though — this is not an argument against linear stories in games. With a linear story, overcoming challenges earns the player more story (usually in the form of a cut scene), even though the player can’t change its content. That’s OK — the very act of overcoming the challenge unlocks the next phase of the story, and the player knows and understands this.

Capcom’s Resident Evil 4

The problem arises when we lead the player to believe her actions do matter, and then it turns out that they don’t, but the player wastes hours and hours trying. If you want to tell a tragic story — the doomed hero or the hopeless cause — you must not lie to the player and tell him that he can escape his fate if he just tries hard enough.

For tragedy to really work, the audience must know in advance that the hero is doomed, or at least come to realize it without spending fruitless hours trying to avoid it. We can still make games about Napoleon, or the Americans in the Vietnam war, even though the player knows the ultimate outcome will be failure.

Bad Gamepad-to-Mouse/Keyboard Conversions (and vice versa)

This is a classic mistake and once again, what’s most surprising about it is that people persist in making it. Jacek Wesolowski writes, “One factor that harms my entertainment is that some developers treat mouse and keyboard as secondary setup. The difference between those and gamepads is significant, because usage patterns differ.”

“For instance, keyboard is better suited for ‘broad’ interfaces, assigning a key to each action, whereas gamepads rely on the ‘deep’ variety, in this case — button combinations and sequences. Simply mapping buttons onto keys, or vice versa, is often insufficient. But that is exactly what many developers do.”

“A good example of this is Assassin’s Creed. Its controls make a fairly good sense when playing with gamepad, but the keyboard/mouse mapping is unwieldy and counter-intuitive. Even worse, the developer has imposed an artificial, and very severe limit on mouse sensitivity, probably to match it with the maximum turn rate available with gamepad. There is no gameplay reason for this, because instant 180-degrees turns are available anyway, as well as looking behind avatar’s back. In other words, higher mouse sensitivity would not give me any real advantage, other than being able to play comfortably. While playing, I felt as if my preferred control device was sabotaged deliberately.”

Jacek has put his finger on one of the reasons I’m a PC gamer rather than a console gamer: I’m not coordinated enough to manage combos, and I prefer to have separate buttons that each do one thing (or better yet, a smart button that does what I mean). However, my preference doesn’t make it a Twinkie Denial Condition. The bad mouse/joystick adaptation is one, though.

Mouse-based interfaces work poorly on joysticks, and usually joystick-based interfaces work poorly with the mouse too. They don’t do the same thing. A mouse is a pointing device. A joystick is a steering device.

A mouse doesn’t automatically return to center the way a joystick does, and a joystick can’t move indefinitely in the same direction the way a mouse can. If you’re going to make a system for both, don’t privilege one over the other or kludge one to fit the other. Design the user interface for each separately as if it were the only input device you will be supporting, and make each as good as it can be.

If you discover that this gives the joystick player a big advantage over the mouse player, or vice versa, don’t solve the problem by sabotaging one player’s control system! Build in a handicapping system that the players can manipulate themselves and mutually agree upon. It works for golf; I see no reason why it shouldn’t work for video games.

Alternatively, under the principle if you can’t do it well, don’t do it at all, drop support for the device that you can’t implement properly. That’s better than selling the player an inferior experience.

Setting the Player Up to Fail

Someone who calls himself “One Man Science Team” wrote, “One design flaw I think definitely calls for Twinkie denial is level designers unreasonably demanding the player break previously established rules and risk associated consequences in order to meet goals. Even games considered ‘good’ do this sometimes — in order to find every secret in the original Donkey Kong Country you have to try jumping into every pit on every level.”

“You will get Game Over many times if you don’t go to a FAQ first. Another example is in many RPGs, with impossible battles where you’re punished for actually trying to win through the wasting of healing items but rewarded for losing because that’s what the story wants you to do.”

He goes on to say that he doesn’t mind level designers changing up the rules now and then, but they have to give hints that they have done so — some kind of visual indicator that things are different.

“But if accomplishing a goal that the developer can expect/predict a player might go for (finding all the secrets) involves violating the very rules of play the designers put forth (and the player getting punished repeatedly for it!) then the trust that exists between the player and designer is eroded.”

Yes it is. Unlike with board games, video game players don’t know the rules when they start out — they have to learn them by trial and error, and that means they have to trust that you’re not going to lie to them.

Your Only Save is Immediately Before Your Death

We’ll end on a simple one. Nathan Sturtevant teaches computer science at the University of Alberta, and he writes, “What has bugged me in a number of games that do allow saving, is that they let you save your game as you die. I think I last saw this in Neverwinter Nights, but I’m fairly certain I’ve seen it in other games as well. In NWN it can happen either in battle, or if you’re about to walk over a trap. It’s quite frustrating to discover that you are reliably killed 0.2 milliseconds after loading your game.”

I’ve been bitten by this one myself. Now, I’m a big believer in letting the player save whenever he wants, and it can be difficult for the computer to predict that death is truly inevitable if the player still has a few hit points left. (It certainly shouldn’t save if he already is dead.)

But I also believe in letting the player make multiple saves. OK, the player saved in the last instant before an inevitable death — so let him restore an earlier save. Problem solved. If you only have storage space for one save, then checkpoints might be a better option — just make sure they’re placed in such a way that the player is definitely healthy when he saves.

Conclusion

That’s it for this year. I’m always interested in more suggestions, although last year I was rather bad at getting back to people and thanking them. I promise to do better!(source:designersnotebook)