分析自下而上游戏设计所存在的问题
在上个世纪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种并不会改善游戏。最后只会让玩家忽略多数的单位。 添加过多变量还会令游戏难以测试和平衡，并且更易于产生漏洞。你最好花时间平衡一小部分真正有趣的选择，而不是去测试数量庞大而无意义的选项。
自下而上游戏设计是一个基本错误，程序员和其他想创造游戏世界的人通常易犯此类错误。它犯了诸多设计和开发问题的一个通病——没有将玩家置于第一位。电子游戏的目的是通过玩法为玩家创造乐趣，因此优秀的游戏设计都是从玩家入手的，而不是以谜题、美术、故事，或者像电梯模拟机制这种具体元素为基础。