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

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

发布时间:2012-01-06 18:02:58 Tags:,,,

作者:Ernest Adams

我曾经写过游戏设计瑕疵的相关文章,下文将阐述分析我发现的5个设计瑕疵。需要澄清的是,有些错误并非设计上的过错,而是编程上的问题。(请点击此处阅读本系列第13、4、56、7、89、10、11、1213

游戏运行过快

我知道这听起来显得很诡异,运行过快难道也算是问题?我喜欢玩古老的游戏,这些游戏是针对较老的硬件设备来设计的,因此在新机器运行时速度要快得多。显然,对主机游戏来说,这并不算是个问题,但PC游戏的情况有所不同。

当然,从商业的角度上看,发行商不会关心这种问题。对他们来说,5年或10年前的游戏已经没有商业价值了。玩家更愿意将金钱花在新游戏上,旧款游戏的盈利能力已不复存在。但是从游戏编程的角度来看,这就是是编程方面出现了偏差。如果你的游戏运行速度过快,影响到游戏体验,那么就意味着你在设计时没有考虑到游戏运行速度的问题。更糟糕的是,你浪费了最宝贵的资源——CPU周期。利用额外的CPU时间,你可以实现许多目标,比如:

1、生成更多动画帧,从而使动画效果更为流畅。上述情况只有能够在各帧间生成的动画系统才能实现,现今这种类型的动画系统越来越多了。

2、将更多时间花在AI上。让寻径范围扩大,或让游戏中的怪物更加聪明。可扩展AI并非毫无意义,但是如果其中任意部分(游戏邦注:比如寻径)牵涉到重复和无限计算,那么这个部分显然需要占用更多的CPU时间。

3、生成更多多边形。许多游戏为了能在较慢的机器上运行,选择削减3D引擎生成的多边形总数,这样势必会影响到画面质量。选择相反方向的做法会如何呢?以高端机器为目标硬件设计游戏,然后通过内置缩放程序来适应现今使用的硬件。随着硬件的升级,游戏的视觉效果会变得越来越好。当然,除CPU时间外的内存及其他硬件资源可能会带来问题,但这种技术依然值得研究和尝试。

我负责编程的首款游戏需要在4.77 MHz 8086到25 MHz 80386间的硬件上运行,因为这是款多人游戏,所以必须保证在各种设备上的运行速度是相同的。为实现这个目标,我将游戏中所有内容的基础都设定为计时器。主循环以尽量快的速度运行,使游戏对键盘和鼠标的反应速度达到最大化,但所有的显示程序都与计时器绑定,它们只在计时器有盈余能力时运行。尽管我没有尝试过,但是我认为这款游戏在我的400 MHz Pentium II上将会以同样的速度运行。

无法随时保存游戏和暂停游戏

许多设计师不喜欢“保存游戏”选项,因为这样玩家任何时候都可以通过读档来纠正自己犯下的任何小错误,这意味着玩家会更快地通关,失败的可能性也会变小。简单地说,玩家会跳过设计师打算让他们体验到的痛苦和失意。这种想法真得很糟糕。仅仅因为在临近结束时犯个错误而不得不重玩整个关卡,这会让人感到愤怒和乏味。难道游戏设计师制作游戏只是为了让玩家体验挫败感吗?

我个人觉得,最少需要让玩家可以自行掌控游戏。如果玩家仅仅因为去洗手间或接电话而在游戏中受到惩罚,这是不公平的。玩家应当可以随时随地暂停游戏,也应当可以随时随地结束游戏,同时不会失去他们已经获得的东西。如果游戏的暂停会影响到游戏玩法,那么可以在选择游戏暂停时关闭屏幕显示内容,比如《俄罗斯方块》。

显然,多人游戏不可参照这项标准。

僵局

当两个过程都在等待对方做出动作,从而导致两个过程都没有继续下去,这便是所谓的僵局。对多任务系统而言,僵局防范是个典型的电脑科学问题:过程A获得资源X,仍需要资源Y才能继续;过程B获得资源Y,仍需要资源X才能继续,因此两个过程都会无限期地拖延下去。

工人物语(from blog.lillarosin.com)

工人物语(from blog.lillarosin.com)

在游戏领域中,僵局指你需要某种资源来构建生产机制,以创造出更多的同种资源。我最早在玩《工人物语3》时发现了这个问题。我没有足够的石头来建造采石者小屋,但是没有采石者小屋我无法获得更多的石头。事实上,出现这种情况并非《工人物语》游戏本身的错,因为游戏之前给了我足够的石头,只是我把这些资源用在其他的建筑上了。当然,某些情况下,僵局可以作为游戏的失败条件。比如在战争游戏中,如果玩家失去了所有的建筑单位和惟一能够生产建筑单位的建筑物,那么系统会在察觉到这种情况后告知玩家他失败了。

游戏的经济模型越复杂,产生僵局的可能性就越高。《工人物语3》有着非同寻常的复杂模型。当我面临僵局时,我的社区依然繁荣发展而且并未受到攻击,所以不能算是游戏失败,只是在游戏中犯了经济错误而已。幸运的是,游戏提供了一个工作区,我可以通过摧毁其他建筑物来回收原始材料。最终,我摧毁建筑物获得足够建造采石者小屋的石头,于是游戏就又可以继续进展下去。

避免僵局的另一个方法丰富资源的来源途径,即便这些新途径所提供的资源极为稀少。比如,在《大富翁》中路过起点可以获得200美元。即便你没有任何可收取租金的地盘,依然可以确保每圈获得200美元。

出现僵局并非总是设计上的错误,但是你需要提供打破僵局的方法(游戏邦注:比如路过起点和摧毁建筑等),或者设定察觉僵局并结束游戏的方法。如果无限期停留在僵局状态,这样的游戏确实让人相当反感。

违背现实常理

当我开始玩《印第安纳琼斯与恶魔机器》测试版时,我走不出游戏中的首个房间。这种类型的游戏我玩得很少,因为它们往往需要高频率按动键盘和鼠标,但是我觉得自己可以尝试下LucasArts的作品,他们可能不会要求玩家在游戏中展现良好的手眼协调能力。在首个房间中,我尝试了所有可能的解决方案,依然一无所获。我连第1个房间都出不去,难道不算个失败者吗?最终我放弃了,去网上查找攻略。

答案就是,将房间中那个巨大的石头搬开!

indiana(from news.softpedia.com)

印第安纳琼斯与恶魔机器(from news.softpedia.com)

石头的密度约为30磅/立方英尺,这块石头有125立方英尺左右,那么它的重量约为21.25吨,几乎与巨石阵中的石块相当。琼斯可以拉动石块?这简直难以想象,因而我之前没有尝试过这么做。

我知道电子游戏中的物理学并不同于现实世界,或许拖动巨型石块是个可以接受的概念。但是,我总是认为关于印第安纳·琼斯的游戏中的元素应当会类似于现实世界。解谜游戏确实涉及到横向思维,但是横向思维本身需要一定的限制条件。对我来说,我会排斥显然违背物理学的内容。我认为横向思维的扩展程度取决于游戏题材,但是在我无法容忍上述游戏的设计方法。印第安纳·琼斯是人类,不是超人。

低级趣味和幼稚的幽默

数年之前,EA的美术人员为《疯狂美式橄榄球》中的啦啦队制作了动画。但是,他们将所有注意力放在了如何体现啦啦队员的性感上,而不是制作游戏真正需要的东西,他们完全是在浪费我们的时间和金钱。

我曾经收到过邮件,有些人坚持要在电脑游戏中突出展现某些低级趣味和性感女性。

我花大量时间说服设计师不要在游戏中添加此类内容。如果制作出的结果不错,尽管玩家可以忍受,但你要制作的产品是游戏,而不是色情媒体。这些内容显得愚蠢且极具冒犯性,丝毫无性感和趣味性可言。令我感到欣慰的是,随着市场的成熟,此类游戏将会逐渐离开我们的视野。

游戏邦注:本文发稿于2000年3月31日,所涉时间、事件和数据均以此为准。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Bad Game Designer, No Twinkie! II

Ernest Adams

Just two years ago I wrote a column called “Bad Game Designer, No Twinkie!” filled with what I saw as design flaws – things that annoyed me about computer games. It elicited a fair amount of E-mail, most of it saying “Yeah! Me, too!” but some of it pointing out that I was occasionally being unfair. In any case, it was clearly a popular (and potentially controversial) topic, and so I started keeping a list of additional things that annoy me. I’ve got five here, and more that I don’t have room for, so it’s time for Bad Game Designer, No Twinkie! II. Some of these are programming faults, not design faults, but you get the idea.

Games That Run Too Fast

I know this sounds weird – since when is running too fast a problem? But I like to play old games, and old games, designed for old hardware, often run much too fast when played on newer machines. Obviously this isn’t an issue for console games, but for PC games it’s a major problem.

From a business perspective, of course, publishers are unlikely to care. To them, a five- or ten-year-old game is ancient history. They’ve made all the money they can from it; it’s no longer supported; the customers are supposed to be plunking down money for new games, not playing old ones. But from an engineering perspective, there isn’t any excuse for it. It’s sloppy programming. If your game is running unplayably fast, that means you’re not really keeping track of how fast it should run, and worse, you’re wasting one of your most precious resources, CPU cycles. There are all kinds of things you could be doing with extra CPU time, as well you know:

Generate additional animation frames and therefore smoother animation. This is only possible if your animation system is capable of generating in-between frames, but more and more of them are nowadays.

Spend the time on extra AI. Calculate further down the game tree; let your pathfinding algorithm look farther ahead; give your monsters a bigger brain. Scalable AI isn’t trivial, but if any part of it, like pathfinding, involves repetitive and indefinite calculations, that part is an obvious candidate for making use of extra CPU time.

Generate extra polygons. A fair number of games compensate for slow machines by cutting down the total number of polygons their 3D engines generate, with predictably ugly results. How about going in the opposite direction? Design a game that would look amazingly fantastic on a hypothetical 3 gigahertz machine, then build in scaling routines to accommodate today’s hardware. As hardware advances, your game will just keep looking better and better. Obviously there are issues about memory and other resources besides CPU time, but this is a technique that seems worth the research effort.

The first game I ever programmed professionally had to run on hardware that ranged from a 4.77 MHz 8086 to a 25 MHz 80386 — and because it was multiplayer, it had to run at the same speed on all of them. I managed this by basing everything on timers. The main loop ran as fast as it could to provide maximum responsiveness to the keyboard and mouse, but all the display routines were tied to timers, and they only ran when the timer expired. I haven’t tried it, but I suspect it would still run at the same speed on my 400 MHz Pentium II.

No On-Demand Save Game and/or No Pause Game

The “save game” issue has been the subject of arguments among game designers since day one, but I know where I come down on this issue: on the side of the player. A lot of designers don’t like “save game”, because it makes it possible for the players to restart any time any little thing goes wrong, which means that they get through the game quicker and lose less frequently. In short, they don’t get to experience the full amount of suffering and disappointment that the designer has planned for them. Too bad. Replaying an entire level because you made a mistake right near the end is frustrating and boring. As a designer, is that really your goal?

To me, the bottom line is that it’s the player’s machine. It’s not fair to penalize him just because he has to go to the bathroom or answer the phone. Players should be able to pause when and where they want, and they should be able to stop when and where they want, without losing all that they have accomplished. If pausing the game would substantially affect the gameplay as in, say, Tetris, then black out the screen while the game is paused.

Obviously this doesn’t apply to multiplayer games.

Deadlocks

A deadlock, or in rather romantic British terminology a “deadly embrace,” occurs when two processes are each waiting for the other to do something, and so neither goes anywhere. Deadlock prevention is a classic computer science problem for multi-tasking systems: process A has allocated resource X but still needs resource Y; process B has allocated resource Y but needs resource X, so each waits indefinitely for the other to finish and release its needed resource.

In game terms a deadlock can occur when you need a resource to construct a production mechanism to produce more of the same resource. I first noticed this problem playing Settlers 3. I didn’t have enough stone to build a stonecutter’s hut, but without a stonecutter’s hut I couldn’t get any more, either. This wasn’t really Settlers’ fault, because the game had given me enough stone to start with, but I had allocated it all to other things. Of course, in some cases you may want a deadlock to be a loss condition: in a wargame, if the player loses all her construction units and she loses the only building that produces construction units, the system can detect this and tell her that she’s lost.

The more complicated your economic model is, the more likely deadlock situations become. Settlers 3 has an unusually complicated model. When I created my deadlock, my community was thriving and I wasn’t under attack at that point, so I couldn’t really be said to be losing the game; I simply made an economic mistake. Fortunately, the game provided a workaround: I could demolish other buildings and regain some of the raw materials. Eventually I demolished enough to get the stone needed to build a stonecutter’s hut, and I was back in business.

Another way to avoid deadlocks is to provide an alternate source for the resource, even if its value is minimal. This is the function of collecting $200 when you pass “GO” in Monopoly. Even if you don’t have any properties earning rents, you’re still guaranteed to get that $200.

Deadlocks aren’t always design errors, but you need either to provide a way to break the deadlock (pass “GO,” demolish buildings, etc.) or a way of detecting it and ending the game. Games that go into deadlock conditions and sit there indefinitely (and I’ve played one or two) are annoying.

Moving Impossibly Large Chunks of Stone

So here I am, playing the demo of Indiana Jones and the Infernal Machine, and I can’t get out of the very first room. I haven’t played a lot of these kinds of games, because they’re generally too twitchy for me, but I figure I can trust LucasArts not to demand too much hand-eye coordination. I try everything I can think of, with no luck. Can’t even get out of the first room… boy, am I a loser! Eventually I break down and go find a walkthrough.

Oh, here’s the answer! There’s a cube of stone, about five feet on a side, that I’m supposed to drag someplace… WHAT?

Let’s see, the density of rock is about 340 pounds per cubic foot, the block is about 125 cubic feet, so it weighs on the order of 21.25 tons. That’s about how much the giant uprights at Stonehenge weigh. And Indy’s supposed to drag this around just by pulling on it, is he? Gosh, I wonder why I didn’t think to try that.

OK, I know the physics in video games is mostly ludicrous – the first time I saw Sonic the Hedgehog change direction in midair I heard a strange whizzing noise: Isaac Newton spinning in his grave. Maybe this dragging-huge-rocks-around concept is such an accepted convention by now that I should just put up with it. Still, I always thought of the Indiana Jones games as set in something resembling the real world. Puzzle games involve lateral thinking, but lateral thinking itself has to be bounded by some limitations on what it’s reasonable to consider — otherwise you’d never stop thinking. For me, I tend to rule out obvious physical impossibilities. I suppose it depends to some extent on the genre, but in this case, it annoyed me. Indiana Jones is a human being, not Superman.

Huge Breasts and Other Juvenilia

Some years ago, EA had a couple of artists create animations of cheerleaders for a cartridge edition of Madden NFL Football. What they turned in was a feeble little 4-step cycle of women with completely improbable breasts jumping up and down. We fired them and had someone else do it over. We didn’t fire them just because they had done a poor job; we fired them because they were morons who were more interested in indulging their own snickering voyeurism than in delivering what the company needed, and they had wasted our time and our money.

I’ve got a message for the no-talent clods who insist on putting puerile humor and outrageously-breasted women into computer games. How to put it diplomatically? Oh, I’ve got it: Grow up.

You’re an embarrassment and a disgrace. It’s because of the example you set that the rest of us have to explain to our in-laws, friends, and for that matter, Congressmen, that we’re not all tasteless money-grubbing louts, only you guys are. I have spent a lot of time trying to convince non-gamers (but people who vote) that you drooling peep-show habitués are actually a minority whose imbecile products and total lack of judgment unfairly tarnish the rest of the industry. Of course, if you actually cared about what effect your self-indulgent display of adolescent lubriciousness has on the reputation of the business or its possible consequences for the political debate over regulating video games, you wouldn’t do it, but no, you’re too wrapped up in your own infantile fantasies to pay attention to anything beyond the ends of your priapic phalluses.

It might be tolerable if you were actually any good at it, but your products aren’t even decent erotica. They’re stupid, they’re offensive, and they’re not sexy or even funny. I take some comfort in the knowledge that as the market matures, you will eventually be forced out, or at least reduced to irrelevancy. In the end the porno kings stopped trying to pretend that they were legitimate moviemakers and went off to form their own industry with its own low standards of quality. Why don’t you do the same? Then you can have your own trade shows, your own awards, and hang around with your own kind: sweaty-palmed, heavy-breathing sloped-forehead gonad-brains. Grow up or get out. (Source: Gamasutra)


上一篇:

下一篇: