作者：Ernest Adams

在上个世纪50年代，我外公是美国俄克拉荷马州塔尔萨城一橦名为Philtower的摩天大厦负责人。而我妈妈则是“电梯小姐”——即该建筑中管理电梯的工作人员。Philtower大厦中的电梯仍然是手工控制，所以她得学习如何在正确的时间令电梯停在对应的楼层。

Philtower_Building(from gamasutra)

在这种家族背景下，当看到Maxis推出《Sim Tower》项目时，我就跃跃欲试了。我一直立志成为像外公一样经营整个摩天大厦，或者至少是像我妈一样管理电梯的人。但不幸的是，我没有如愿。《Sim Tower》并不是一款经营摩天大厦的游戏，它更多的是涉及出售办公楼的主题。在这样一个三维庞然大物面前，我很失望自己只创造了一个二维建筑。但这还不是最糟的情况，真正的问题出现在电梯上。

我妈妈的工作颇具技术性，但却很简单，也极其无聊。我的工作则更困难。《Sim Tower》成功的关键在于自动化电梯的编程，当时我对此毫无指望。它并不像听起来那么简单，因为电梯一楼的编程是一个特殊情况。人们在早上8点为了上班会成群涌现，他们从一楼开始就会分头奔向大厦中不同的地方。在下午5点，又会从大厦的各个方向奔到电梯前，并且所有人都要坐电梯到一楼。你必须解决的一个问题是，当无人使用电梯时，哪个位置才是电梯的最佳等待地点？

我反复阅读了使用手册，自己捣鼓试验了一番，并进行了调整，但却无所收获。我游戏中的小人足足站了数个小时，越来越愤怒，不耐烦地等待着似乎永远无法到达的电梯。我为他们提供了自动扶梯这一选择，他们不屑地嘲笑这一选择，并继续等待电梯。租客们成群撤出了我的大厦，结果我就破产了。电梯管理显然是该游戏的核心。

数年之后，我以这一经历为例在一次演讲中谈到了如何创造伪人工智能的问题：为玩家分配一项不熟悉的任务，不要告诉他们如何成功实现目标。让玩家产生AI的错觉而无需创造真正的AI。我无法吃透电梯的问题，所以我认为那款游戏一定比我更聪明。

在演讲之后，有名Maxis成员告诉我，“你猜得对，《Sim Tower》就是根据真正的电梯模拟程序来创建的，我们是从一个日本人那里买到的程序。”

这总算解释了我的许多疑惑。《Sim Tower》就是我称之为自下而上游戏设计的一个典型。

sim tower(from gamasutra)

自下而上游戏设计，通常发生于模拟类游戏，它会采用一个特定机制，并在此基础上创造游戏。这就是其运行原理。你一开始要处理一些有趣而复杂的过程——例如，一群好友间的社交互动，或者优化一橦大楼中的电梯行为。如果你是软件工程师，你的自然反应就是想知道如何为其编程，并看看运行结果。该模拟游戏的核心机制是什么？其内部经济是什么？电梯是否应该智能到足以认知电梯内已经满员，因此无需再等待他人的地步？人们等电梯的时间一般是多久？等等。

我为自己而感到内疚，当时我还是一名年轻程序员时，仍然认为制作电脑游戏就只是编写很棒的软件而已。你的脑中充斥着代表各种东西的数据结构，以及计算各种东西的算法，而你最想做的事情就是赶紧编写完看看运行效果。但本文宗旨并非让你“在编程之前先设计代码”。即使你已经有好几个月没有编写一行代码，也该知道自下而上游戏设计的问题在于，它只是一个模拟游戏，你并不知道它会不会有趣。

这是《黑与白》的一个弱点，我想Peter Molyneux本人也会承认这一点。Molyneux因创造极富创意的游戏引擎，并在之后再将其转化为游戏而得名。如果这种传言属实，那么他在《Populous》、《Dungeon Keeper》以及之后的《黑与白》中也可能采用了这一做法。尽管这些游戏很成功，但一切迹象均表明它们是先写出模拟机制，之后才转变为游戏。

如果你是Peter Molyneux，或者你身边就有许多天才，并且你会疯狂地创新和卖力地工作，那么你可以对此无所谓。但很少人会这么幸运。如果你先从一个模拟机制入手，并指望在之后才将其转变为游戏，那么你很可能要冒数个月投入制作的风险，最终只能自问：“为什么这么不好玩？”此时你就真的麻烦了。

自下而上游戏设计的前提是，任何微妙或有趣的编程，玩起来也要有趣味。但也未必要遵循这一规律。有几年时间我对一款交通模拟游戏的编程挑战很好奇。玩家在游戏中可以扩大道路，装置交通灯，以此查看在不同条件下的交通流量有何变化。我向好友Anne Westfall提到了这个想法，她礼貌地答道：“谁会想这么做呢？”这个问题让我一愣。没有太多人会想捣鼓道路交通灯的计时问题。更重要的是，我自己都不是很想做这种事情，当然也不会为此花太多钱。我为软件编程问题而兴奋不已，忽略了它应该令人快乐的这个事实。

自下而上游戏设计的另一个危险在于，它通常易于令模拟游戏看起来比实际需要的程度更具真实感。我们都很熟悉“功能累赘”——即开发者试图通过添加更多功能来“优化”软件这个问题。在消费者软件中，这种做法的结果通常是过犹不及，导致软件臃肿不堪，例如Microsoft Office。在电子游戏领域，这类游戏就会充斥过多细节，但没有一者玩起来令人愉快。我玩过许多提供了大量选项的游戏，但最后仅使用了其中一些选项，因为这些选项才是驱动游戏的关键。其他有些选项只是刚刚好，还有一些甚至会带来编程上的麻烦，但却并没有令玩法有多大改观。

事实上，你在模拟游戏中植入的变量越多，游戏就越有可能只有一种最佳玩法——即游戏理论中所谓的优势策略。原因在于，在多数情况下，有些变量会比其他变量更易于对游戏内部经济产生重要影响。而玩家为了最大化自己的成功机率，当然就会考虑最有效的方法，从而忽略其余选项。设计有意义的模拟游戏的关键在于确保所以变量都具有让玩家使用的意义——这意味着要将平衡变量的数量。虽然象棋并非一种模拟游戏，但它却也能够说明我的观点：它只有6种单位类型，再增加6种并不会改善游戏。最后只会让玩家忽略多数的单位。

添加过多变量还会令游戏难以测试和平衡，并且更易于产生漏洞。你最好花时间平衡一小部分真正有趣的选择，而不是去测试数量庞大而无意义的选项。

自下而上游戏设计是一个基本错误，程序员和其他想创造游戏世界的人通常易犯此类错误。它犯了诸多设计和开发问题的一个通病——没有将玩家置于第一位。电子游戏的目的是通过玩法为玩家创造乐趣，因此优秀的游戏设计都是从玩家入手的，而不是以谜题、美术、故事，或者像电梯模拟机制这种具体元素为基础。

原文发表于2004年10月18日，所涉事件及数据以当时为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The Designer’s Notebook: The Perils of Bottom-up Game Design

by Ernest Adams

October 18, 2004

Back in the 1950′s, my grandfather was the superintendent of a skyscraper in Tulsa, Oklahoma called the Philtower. (That’s Phil as in Phillips 66 Petroleum. Mr. Phillips was an oil baron, and he named a lot of things after himself.) At the same time, my mother was an “elevator girl” – she operated elevators in the building. The elevators in the Philtower were still controlled by hand, and she had to learn to stop them at exactly the right time to get the floor of the elevator to line up with the floor of the building.

With this kind of family history, I didn’t hesitate when Maxis brought out Sim Tower. I was looking forward to running a whole skyscraper like my grandpa, and operating, or at least managing, elevators like my mother. Alas, it was not to be. Sim Tower wasn’t really about running a skyscraper; it was more about selling office space in one. And for such a three-dimensional object, it was a big disappointment to find myself constructing a two-dimensional building. That wasn’t the worst of it, though. The real problem was the elevators.

Philtower in Tulsa, Oklahoma

My mother’s job was skilled but simple, and deadly dull. My job was significantly harder. The key to success at Sim Tower was programming the automated elevators, and I was hopeless at it. It isn’t as simple as it sounds, because in elevator programming the ground floor is a special case. People arrive for work in huge numbers at 8 AM, and they need to go all over the building starting at the ground floor. At 5 PM, the reverse happens; they come from all over the building, and all need to be transferred to the ground floor. One of the things you have to figure out is, where’s the most efficient place for the elevators to wait when no one is using them?

I read the manual repeatedly, fiddled, experimented, and tweaked. No go. My little people stood for hours of game time, getting more and more angry, waiting for elevators that never seemed to go where I needed them to. I gave the people escalators as an alternative; they sneered at them and continued to wait for the elevator. Tenants moved out of my building in droves, and I went bankrupt.

Elevator management was clearly the heart of the game.

A few years later I used this experience as an example in a lecture about how to create fake artificial intelligence: impose an unfamiliar task on the player, and don’t tell him how to succeed at it. Give the player the illusion of AI without having to do real AI. I couldn’t figure the elevators out, so I assumed that the game must be smarter than I was.

After my lecture, a Maxis employee who shall remain nameless buttonholed me. “You guessed right,” she said. “Sim Tower was built around a real elevator simulation program we bought from a Japanese guy.”

That explained a lot. Sim Tower was an example of something I call bottom-up game design, and even though this isn’t a No Twinkie column, I’m here to tell you now that it’s a Twinkie Denial Condition if there ever was one.

Bottom-up game design – which most often happens with simulations – consists of taking a mechanism of some kind and trying to tack a game onto it. Here’s how it usually happens. You begin with some interesting and complicated process – social interactions among a group of friends, for example, or optimizing elevator behavior in a crowded building. If you’re a software engineer, your natural temptation is to figure out how to program it and see how it works. What are the core mechanics of the simulation? What is its internal economy? Should an elevator be smart enough to know that it’s full, so it doesn’t stop for people any longer until some get out? How long are people prepared to wait for an elevator, anyway? And so on.

I’ve been guilty of it myself, back when I was a young programmer and still thought that making computer games was about writing cool software. Your head is fizzing along with data structures for representing this and that, and algorithms for computing this and that, and the very first thing you want to do is code it up and watch it go. But this isn’t a column to tell you “design your code before you write it” – that’s been said a million times already. The problem with bottom-up game design, even if you don’t write a line of code for months, is that you don’t know if it’s any fun while it’s just a simulation.

This was one of the weaknesses of Black and White, as I think Peter Molyneux himself would admit. Molyneux is famous for creating amazing, hugely innovative game engines, and only then figuring out how to turn them into a game. If the gossip is right, he did it with Populous, then with Dungeon Keeper, and again with Black and White. Despite their success, all show signs of having been written as a simulation first, and only then having been turned into games.

You can get away with this if you’re Peter Molyneux, and you surround yourself with brilliant talent and you innovate like crazy and work like a dog (and are able to face down – or fake out – the publisher when you’re six months late). Lesser mortals are seldom so fortunate. If you start with a simulation and count on turning it into a game later, you run a serious risk that a few months before gold master, you’ll suddenly be asking yourself the dreaded question: “Why isn’t this more fun?” And then you’re in real trouble.

Bottom-up game design is based on an assumption that any process that is subtle or interesting to program is also going to be interesting to play with. That doesn’t necessarily follow. For years I was intrigued by the challenge of programming a traffic simulation. The player could widen roads, install traffic lights, and all sorts of things to see how the flow of traffic changed under different conditions. I mentioned this idea to my friend Anne Westfall, and she said politely, “And who would want to do this?” The question brought me up short. Not many people have a dream of fiddling around with traffic-light timings. What’s more, even I wouldn’t want to do it for very long, and I certainly wouldn’t pay much money for the privilege. I had gotten all excited about the software engineering problems and ignored the fact that it needed to be enjoyable.

The dreaded elevators of Sim Tower.

Another danger of bottom-up game design is the tendency to make the simulation more realistic than it actually needs to be for the game. We’re all familiar with the problem of “creeping featurism” – the temptation to “improve” your software with one more feature, and then one more still, just because you can. In consumer software, the result is usually a bloated, awkward mess like Microsoft Office. In videogames, it’s a game with far too much detail, none of which is really that enjoyable to play with. I’ve played a number of games that offered me tons of options, but I ended up only using a few because those were the options that drove the engine of the game. The others were legitimate enough, and someone had taken the trouble to code them properly, but they didn’t make sufficient difference to the gameplay to bother with.

In fact, the more variables you include in a simulation, the greater the chances are that there’s only one best way to play the game – a dominant strategy, as it’s called in game theory. The reason is that in almost all cases, some of those variables are going to have a greater effect on the internal economy of the game than others. The player, trying to optimize her chances of success, is going to concentrate on the most effective ones and ignore the rest. The key to designing a meaningful simulation is to make sure that all the variables matter enough for the player to use them – and that means restricting the numbers to a carefully-balanced few. Even though chess isn’t a simulation, it’s a good example of what I mean: it’s played with only six unit types. Adding half a dozen more wouldn’t improve it any. You would probably end up ignoring most of them anyway.

Including too many variables also makes the game harder to test and balance, and it’s more prone to bugs. You’re better off spending your time balancing a small number of really interesting choices than you are testing a large number of meaningless ones.

Bottom-up game design is an elementary mistake, usually made by programmers and other people who like to build worlds and fiddle with them. It is one of a large class of design and development errors that is characterized by one common fault: failing to put the player first. A videogame’s purpose is to create enjoyment for the player through gameplay, so good game design always begins with the player. It doesn’t begin with the puzzles, or the art, or the story, or – in this particular instance – an elevator simulation. （source：gamedevelopment）