“7”原则
策略游戏通常让玩家扮演如军队指挥官这样的角色。但想一想现实世界的指挥官是怎么工作的。他不会一边观察地图，一边命令战场上的每一辆坦克。在真实的战争中，他手下有 几个直接听从他的命令的人。在美军中，1个小队长和2名火力小队长一起带领约9名士兵。1个排长通常指挥4个小队长再加上3-4名参谋。1个连长通常对4个排长和参谋直接发号施令。1个中校可能指挥4个连的部队加参谋，等等，形成一个完整的指挥系统。
没有意外。这是使长官得以有效地管理有限数量的下级的军事组织的基本原则。由长官直接指挥的下级数量就是该长官的指挥范围。无论是排长还是战区司令，最有效的指挥范围 都是一样的。19世纪欧洲军队确定的指挥范围的最大值是7，这个数字自那以后就没有变过。
这个原则也应该运用于策略游戏设计。控制数量超过7的玩家不可能有效地管理所有单位。（这是推论，如果一个回合历时一分钟，玩家每10秒钟执行移动约一次，那么玩家可能无 法专心致志且没有机会进行深入、策略性的思考，而这本应该是策略游戏的乐趣来源。要求玩家每秒一点击的游戏是街机游戏，无论它的复杂度是多少。）
一个战区司令指挥的7个下级通常有一两个不直接参与战斗而是负责转达信息。这意味着不同的信息显示器计数达到7.
这个原则存在使情况复杂化的因素。以国际象棋为例—-各个玩家控制16个棋子，且同时必须注意16个敌方棋子。这就是为什么国际象棋对初学者来说这么困难。但国际象棋专家却 能应付得了。国际象棋的玩法违背了“7”原则吗？
是的，但也不是。国际象棋的专业知识不包括学习用头脑跟进越来越多的棋子；而是学习把棋盘位置拆分成单独的、熟悉的结构——士兵、国王、三个士兵、骑士、一组对中心区 域有影响的棋子——为了把概念的数量压缩成人类可控的数量7。
美军的指挥范围目的是，指挥官可以命令和监督第一层级（他的下属），同时跟进第二层级的情况（他的下属的下属）。国际象棋的玩家掌握两个层级的控制：第一，选择这些结 构体各自的子目标（比如，“控制中心”或“打破对方的防御结构”）；第二，选择执行各个子目标的步法且选择其中一个步法。这样，玩家就不是跟进所有棋子，而是选择每一 个步法，这就破坏了“7”原则。如果你希望你的游戏进展得比国际象棋快，且仍然保持策略性，那么你就必须遵守“7”原则。
鱼与熊掌不可兼得
游戏设计师可能会认为，如果允许玩家控制所有单位，但不是必须控制所有单位，那么游戏世界就完美了。不幸的是，事实并非如此。在经济学中有一条法则叫作“Gresham’s Law of Money”，也叫作“劣币逐良币法则”。Gresham解释道，当一个国家使用两种货币，即具有固有价值的金属货币和不具有固有价值的纸币时，纸币会把金属货币驱逐出市场 ，直到所有人都只使用纸币。
在游戏中，恶劣的玩家驱逐优秀的玩家。在RPG中，糟糕的角色扮演（注重财富积累和控制权的玩法）升级更快，最终把优秀的角色扮演驱逐出游戏世界。在允许控制各个独立单位 的游戏中，每秒可以执行3次点击的14岁男性玩家会打败依赖电脑执行其计划的思考型玩家，因为我们距离电脑可以比人类玩家更好地控制单位的时代还很遥远。
有些玩家喜欢快速点击和微观管理，他们也许就是游戏杂志、广告和推广渠道所针对的上述14岁男性玩家。越出这个熟悉的玩家类型的范围总是危险的。任何制作人都不愿意损失 这个市场份额，所以游戏最好能够包含独立单位控制的选项。
然而，现在的游戏市场却没有充分考虑害怕患上腕道症候群的玩家（我想这个市场会比14岁少年玩家的市场更大）。如果游戏允许控制独立单位，那么它必定是一个独立的游戏选 项，玩家应试能够设置不允许独立单位控制的多人游戏。
现在，你可能会质疑我的神智是否清楚，发布本文的编辑是否有脑子。我是说策略游戏应该只允许玩家控制7个单位？不是的。我是说，玩家不应该直接控制它们。我们必须概念化 控制的中间层。这做起来并不困难，只是被常见的对象导向型程序的误解所阻碍。
对于《文明3》的单位导向的界面，这需要点击各个工人单位，把他们分配到的铁路线路的各个路段。各个工人必须分配到线路的某个短的路段，因为如果你让一个单位从南端作业 到北端，让另一个单位从北端作业到南端，那么完的路段就会从他们的任务的开头部分计算，而不会计算另一个单位同时作业的部分——导致大量非重叠的平等铁路线路，以及军 队将无法越过你的边界来击退罗马军团的侵略。
为了在被侵略以前完成，我必须分配约一百个工人去建造铁路线。对于各个工人，选中必须点击一次；然后输入“g”开始移动，滚动到铁路线的起点，再点击。之后，当它到达那 个点，我必须输入“ctrl-r”以开始建筑铁路和，滚动到那个单位的铁路部分的末端，再点击。每个单位都经过这三次移动，三次按键，和三次鼠标点击。我尝试过把工人组成三 人小组，尽管这不是任何时候都可行的。所以我大约执行了600次点击、按鼠标和滚动才完成那条铁路。
想象一下，如果我只要点击铁路的开端和末端，电脑就会指挥工人却建筑他们各自的路段。这整个铁路就会在我指挥各个单位所需的同样的管理工作量下建造完成。
这条铁路的作用是把军队运到边界去抗击罗马军团。另外，每个新建造的单位都必须各自沿着线路运送到边界沿线的某些地点抗击敌人。想象一下，如果我只要简单地确认边界、 城市或防御点，电脑就会操作剩下的军队移动，那么我的手腕该省下多少力。但为了清楚地执行，程序员必须把铁路和边界作为第一类对象。
离线vs在线控制
指挥官之所以能够命令7名下属的一部分原因是预先准备。他事先设定好了任何行动的情节，并通过在他的军队行动中命令不同情节间的转变而实现快速且巨大的改变。他的服务分 支带有一个标准的战术库，即基于团队水平区别他可以在行动过程中用于向下属解释自己的目的。他的下属面对着交战规则去判断如何对各种类型的敌人以及非战斗式行动作出回 应。他可以事先将这些规则带进战斗中。他带有许多野外演习，在每次演习后，他会告诉下属他们哪些做对了而哪些则做错了，而他的长官也将对他的表现做出分析。这便减少了 战斗中所需要的直接监管的分量。
如果你使用统一的形式去设计游戏AI，如基于规则的系统或有限状态自动装置，你便可以将其作为指导玩家单位的另一种方式而面向他们开启。在真正的军事野战游戏模拟器（如 JSAF或OneSAF）中，面向半自动单位创造交战规则是必要的。实际上，SAF可以代表“半自动化兵力，”这是能够提供非常复杂的任务和交战规则的单位，所以操作员便能够监管它 们并且不会过多进行干涉，同时还能为真正控制每个对立单位提供现实的培训环境。
有些游戏，像《Quake》便允许玩家访问AI去设计敌人；或者像在《Robotwar》中，玩家所获得的单位必须是经过完整规划的，而不是在游戏过程中进行引导。没有人会为半自动化 兵力提供一个界面。提供两个用户界面（游戏邦注：一个是提供交战规则的离线界面，另一个是用于在线过程中）将减少处理个体单位的压力。
用户界面性能分析
为了检测哪一部分用户界面是无效率的，你可以使用用户界面分析器进行测试。UI分析器就像代码分析器，但比起报告CPU循环，它报告的是用户界面事件。它将直接呈现出玩家在 你的每部分代码中进行了多少次点击，按键以及鼠标移动。用户界面分析器可以呈现出更复杂的信息，如表示用户所落实的行动序列的图像。
你也许可以使用你的IDE分析器去计算I/0事件或函数调用，但这通常都不能告诉你玩家将最多时间花在哪些内容上。如果你让代码调用一个程序去报告UI事件而启动自己的UI分析 器，你便可以因此获取更多信息。
就像如果《文明III》的开发者能够使用一个UI分析器，他们便能够发现在游戏的谈判部分中出现了过度点击与按键次数。这也揭示了游戏中存在漏洞（游戏邦注：即城市选择菜单 中缺少滚动条），并需要游戏明确交易中的最低限度金币数量，而不是让用户使用二进位检索去找到它。根据我的估算，这两个任务占据了100个以上的UI事件。
为了比较不同的潜在UI，你需要保持分数的方法。回到我的《文明III》UI中，我可以通过将点值分配到每种UI行动类型中而获得整体的UI分数。你是如何基于想要策略的内容去分 配点数。对于一款街机游戏，速度便是主要衡量标准，所以你可能会基于按键速度去计算鼠标的点击速度。
估算
你可以计算玩家必须做的W操作去明确使用你的用户界面的一次移动。如果你基于游戏的变量衡量W，如游戏区域的规模以及玩家单位的数量，你便可以比较不同的用户界面，即使 你只能够估算W。
例如，为塑造一个虚拟粘土考虑一个UI。你有大小n n n的体素数组，每个体素是可以打开或关闭的。我们将考虑四个可能的用户界面。在第一个界面中，用户想要打开每个体素坐 标轴中的用户类型。用于明确从1到n的按键次数是与log2(n)成比例的，所以这让操作与3log2(n)成正比去明确每个打开的体素。（从现在起，我将不再使用“成比例”这一短语并 编写W=f(x)，即它意味着W=O(f(x))。）如果我们假设美术人员将明确一个界面，并且不填满整个雕塑，那么整体的操作将变成W=3n2log(n)。（界面的大小与n2成正比。）
在第二个用户界面中，用户在三维空间中使用三维鼠标（如3DConnexion的Spacebaoll）选择一个点，并点击鼠标去切换打开/关闭状态。操作需要前进到三维空间的一个特殊点上 ，然后结合三次移动；每次移动是基于1到n的坐标轴范围，并伴随着平均n/2值似乎它将利用操作W=n5/8去创造一个雕塑。然而，让我们假设在打开一个体素后，用户会移动到26 个相邻体素中的一个。我们会说这与明确26个选择中的一个（即log2(26)）所需要的信息成正比。我们将其粗略估算为log2(33=27)，因为在这里以及我们之前关于W的值中的常数3 是源自雕塑的三维属性。之后整体的操作是W=3n2log2(3)。这一界面看起来就像是对于第一个界面的完善。
在第三个界面中，我们将让用户从一个与预期雕塑同样大小的球体粘土开始，用户将使用一个普通的2D鼠标绕着粘土的表面移动光标，并点击左键在光标下推动左键（垂直于界面 ），并按压右键将其往上拉。我们将使用一个加速推/拉界面（声明体素的数量）粘土朝着同样方向移动时传达双倍推或拉的体素数量，并在朝相反方向移动时减半数量，所以我们 可以通过二进位检索让时间与log2(n)成正比而发现适当的位置。再次假设用户只需要在界面上面向每个点进行一次操作。那么操作需要移动到下一个体素便是2log2(3)，因为这一 移动是二维的。然后总体的操作便是W = n2 ′ 2log2(3) ′ log2(n) = 2n2log2(n)log2(3)。尽管我们将移动限制在一个界面上，但这却比之前的UI还糟糕，这主要归咎于用于推 并拉动虚拟粘土的点击数。
在第四个界面中，用户将基于2D鼠标绕着界面移动，并像之前那样推/拉进/出点数。然而，粘土的界面将会有张力，所以推进/出一个点数将同时拖曳所有邻近的体素。结果便是界 面将基于与你使用控制点和齿条定义曲线的方式那样进行雕刻。然后在W = 2c2log2(n)log2(3)中，控制点数c便成为了雕塑的不规则函数，而不是体素的数量。对于高分辨率建模 ，n>>c，并且W=O(log2(n))。这是非常优秀的用户界面。
为了将认知工效学整合到W中，你也要计算玩家用于记住每个键盘快捷键和可点击图标的含义，并整合操作的衡量将显示信息转换到相关可用信息所需要的内存量。你同样也可以为 内存检索时间添加一个条件。面向不同内存类型的内存检索时间是明确的；为了记住一列选择汇总的一个，时间便是K+an，这里的n是选择的数量而K和a则是常数。如果你不知道如 何按比例分配认知条件让它们能够与非认知条件成比例，你可能会对它们进行分开概括。
策略游戏通常让玩家扮演如军队指挥官这样的角色。但想一想现实世界的指挥官是怎么工作的。他不会一边观察地图，一边命令战场上的每一辆坦克。在真实的战争中，他手下有 几个直接听从他的命令的人。在美军中，1个小队长和2名火力小队长一起带领约9名士兵。1个排长通常指挥4个小队长再加上3-4名参谋。1个连长通常对4个排长和参谋直接发号施令。1个中校可能指挥4个连的部队加参谋，等等，形成一个完整的指挥系统。
没有意外。这是使长官得以有效地管理有限数量的下级的军事组织的基本原则。由长官直接指挥的下级数量就是该长官的指挥范围。无论是排长还是战区司令，最有效的指挥范围 都是一样的。19世纪欧洲军队确定的指挥范围的最大值是7，这个数字自那以后就没有变过。
这个原则也应该运用于策略游戏设计。控制数量超过7的玩家不可能有效地管理所有单位。（这是推论，如果一个回合历时一分钟，玩家每10秒钟执行移动约一次，那么玩家可能无 法专心致志且没有机会进行深入、策略性的思考，而这本应该是策略游戏的乐趣来源。要求玩家每秒一点击的游戏是街机游戏，无论它的复杂度是多少。）
一个战区司令指挥的7个下级通常有一两个不直接参与战斗而是负责转达信息。这意味着不同的信息显示器计数达到7.
这个原则存在使情况复杂化的因素。以国际象棋为例—-各个玩家控制16个棋子，且同时必须注意16个敌方棋子。这就是为什么国际象棋对初学者来说这么困难。但国际象棋专家却 能应付得了。国际象棋的玩法违背了“7”原则吗？
是的，但也不是。国际象棋的专业知识不包括学习用头脑跟进越来越多的棋子；而是学习把棋盘位置拆分成单独的、熟悉的结构——士兵、国王、三个士兵、骑士、一组对中心区 域有影响的棋子——为了把概念的数量压缩成人类可控的数量7。
美军的指挥范围目的是，指挥官可以命令和监督第一层级（他的下属），同时跟进第二层级的情况（他的下属的下属）。国际象棋的玩家掌握两个层级的控制：第一，选择这些结 构体各自的子目标（比如，“控制中心”或“打破对方的防御结构”）；第二，选择执行各个子目标的步法且选择其中一个步法。这样，玩家就不是跟进所有棋子，而是选择每一 个步法，这就破坏了“7”原则。如果你希望你的游戏进展得比国际象棋快，且仍然保持策略性，那么你就必须遵守“7”原则。
鱼与熊掌不可兼得
游戏设计师可能会认为，如果允许玩家控制所有单位，但不是必须控制所有单位，那么游戏世界就完美了。不幸的是，事实并非如此。在经济学中有一条法则叫作“Gresham’s Law of Money”，也叫作“劣币逐良币法则”。Gresham解释道，当一个国家使用两种货币，即具有固有价值的金属货币和不具有固有价值的纸币时，纸币会把金属货币驱逐出市场 ，直到所有人都只使用纸币。
在游戏中，恶劣的玩家驱逐优秀的玩家。在RPG中，糟糕的角色扮演（注重财富积累和控制权的玩法）升级更快，最终把优秀的角色扮演驱逐出游戏世界。在允许控制各个独立单位 的游戏中，每秒可以执行3次点击的14岁男性玩家会打败依赖电脑执行其计划的思考型玩家，因为我们距离电脑可以比人类玩家更好地控制单位的时代还很遥远。
有些玩家喜欢快速点击和微观管理，他们也许就是游戏杂志、广告和推广渠道所针对的上述14岁男性玩家。越出这个熟悉的玩家类型的范围总是危险的。任何制作人都不愿意损失 这个市场份额，所以游戏最好能够包含独立单位控制的选项。
然而，现在的游戏市场却没有充分考虑害怕患上腕道症候群的玩家（我想这个市场会比14岁少年玩家的市场更大）。如果游戏允许控制独立单位，那么它必定是一个独立的游戏选 项，玩家应试能够设置不允许独立单位控制的多人游戏。
现在，你可能会质疑我的神智是否清楚，发布本文的编辑是否有脑子。我是说策略游戏应该只允许玩家控制7个单位？不是的。我是说，玩家不应该直接控制它们。我们必须概念化 控制的中间层。这做起来并不困难，只是被常见的对象导向型程序的误解所阻碍。
对于《文明3》的单位导向的界面，这需要点击各个工人单位，把他们分配到的铁路线路的各个路段。各个工人必须分配到线路的某个短的路段，因为如果你让一个单位从南端作业 到北端，让另一个单位从北端作业到南端，那么完的路段就会从他们的任务的开头部分计算，而不会计算另一个单位同时作业的部分——导致大量非重叠的平等铁路线路，以及军 队将无法越过你的边界来击退罗马军团的侵略。
为了在被侵略以前完成，我必须分配约一百个工人去建造铁路线。对于各个工人，选中必须点击一次；然后输入“g”开始移动，滚动到铁路线的起点，再点击。之后，当它到达那 个点，我必须输入“ctrl-r”以开始建筑铁路和，滚动到那个单位的铁路部分的末端，再点击。每个单位都经过这三次移动，三次按键，和三次鼠标点击。我尝试过把工人组成三 人小组，尽管这不是任何时候都可行的。所以我大约执行了600次点击、按鼠标和滚动才完成那条铁路。
想象一下，如果我只要点击铁路的开端和末端，电脑就会指挥工人却建筑他们各自的路段。这整个铁路就会在我指挥各个单位所需的同样的管理工作量下建造完成。
这条铁路的作用是把军队运到边界去抗击罗马军团。另外，每个新建造的单位都必须各自沿着线路运送到边界沿线的某些地点抗击敌人。想象一下，如果我只要简单地确认边界、 城市或防御点，电脑就会操作剩下的军队移动，那么我的手腕该省下多少力。但为了清楚地执行，程序员必须把铁路和边界作为第一类对象。
离线vs在线控制
指挥官之所以能够命令7名下属的一部分原因是预先准备。他事先设定好了任何行动的情节，并通过在他的军队行动中命令不同情节间的转变而实现快速且巨大的改变。他的服务分 支带有一个标准的战术库，即基于团队水平区别他可以在行动过程中用于向下属解释自己的目的。他的下属面对着交战规则去判断如何对各种类型的敌人以及非战斗式行动作出回 应。他可以事先将这些规则带进战斗中。他带有许多野外演习，在每次演习后，他会告诉下属他们哪些做对了而哪些则做错了，而他的长官也将对他的表现做出分析。这便减少了 战斗中所需要的直接监管的分量。
如果你使用统一的形式去设计游戏AI，如基于规则的系统或有限状态自动装置，你便可以将其作为指导玩家单位的另一种方式而面向他们开启。在真正的军事野战游戏模拟器（如 JSAF或OneSAF）中，面向半自动单位创造交战规则是必要的。实际上，SAF可以代表“半自动化兵力，”这是能够提供非常复杂的任务和交战规则的单位，所以操作员便能够监管它 们并且不会过多进行干涉，同时还能为真正控制每个对立单位提供现实的培训环境。
有些游戏，像《Quake》便允许玩家访问AI去设计敌人；或者像在《Robotwar》中，玩家所获得的单位必须是经过完整规划的，而不是在游戏过程中进行引导。没有人会为半自动化 兵力提供一个界面。提供两个用户界面（游戏邦注：一个是提供交战规则的离线界面，另一个是用于在线过程中）将减少处理个体单位的压力。
用户界面性能分析
为了检测哪一部分用户界面是无效率的，你可以使用用户界面分析器进行测试。UI分析器就像代码分析器，但比起报告CPU循环，它报告的是用户界面事件。它将直接呈现出玩家在 你的每部分代码中进行了多少次点击，按键以及鼠标移动。用户界面分析器可以呈现出更复杂的信息，如表示用户所落实的行动序列的图像。
你也许可以使用你的IDE分析器去计算I/0事件或函数调用，但这通常都不能告诉你玩家将最多时间花在哪些内容上。如果你让代码调用一个程序去报告UI事件而启动自己的UI分析 器，你便可以因此获取更多信息。
就像如果《文明III》的开发者能够使用一个UI分析器，他们便能够发现在游戏的谈判部分中出现了过度点击与按键次数。这也揭示了游戏中存在漏洞（游戏邦注：即城市选择菜单 中缺少滚动条），并需要游戏明确交易中的最低限度金币数量，而不是让用户使用二进位检索去找到它。根据我的估算，这两个任务占据了100个以上的UI事件。
为了比较不同的潜在UI，你需要保持分数的方法。回到我的《文明III》UI中，我可以通过将点值分配到每种UI行动类型中而获得整体的UI分数。你是如何基于想要策略的内容去分 配点数。对于一款街机游戏，速度便是主要衡量标准，所以你可能会基于按键速度去计算鼠标的点击速度。
估算
你可以计算玩家必须做的W操作去明确使用你的用户界面的一次移动。如果你基于游戏的变量衡量W，如游戏区域的规模以及玩家单位的数量，你便可以比较不同的用户界面，即使 你只能够估算W。
例如，为塑造一个虚拟粘土考虑一个UI。你有大小n n n的体素数组，每个体素是可以打开或关闭的。我们将考虑四个可能的用户界面。在第一个界面中，用户想要打开每个体素坐 标轴中的用户类型。用于明确从1到n的按键次数是与log2(n)成比例的，所以这让操作与3log2(n)成正比去明确每个打开的体素。（从现在起，我将不再使用“成比例”这一短语并 编写W=f(x)，即它意味着W=O(f(x))。）如果我们假设美术人员将明确一个界面，并且不填满整个雕塑，那么整体的操作将变成W=3n2log(n)。（界面的大小与n2成正比。）
在第二个用户界面中，用户在三维空间中使用三维鼠标（如3DConnexion的Spacebaoll）选择一个点，并点击鼠标去切换打开/关闭状态。操作需要前进到三维空间的一个特殊点上 ，然后结合三次移动；每次移动是基于1到n的坐标轴范围，并伴随着平均n/2值似乎它将利用操作W=n5/8去创造一个雕塑。然而，让我们假设在打开一个体素后，用户会移动到26 个相邻体素中的一个。我们会说这与明确26个选择中的一个（即log2(26)）所需要的信息成正比。我们将其粗略估算为log2(33=27)，因为在这里以及我们之前关于W的值中的常数3 是源自雕塑的三维属性。之后整体的操作是W=3n2log2(3)。这一界面看起来就像是对于第一个界面的完善。
在第三个界面中，我们将让用户从一个与预期雕塑同样大小的球体粘土开始，用户将使用一个普通的2D鼠标绕着粘土的表面移动光标，并点击左键在光标下推动左键（垂直于界面 ），并按压右键将其往上拉。我们将使用一个加速推/拉界面（声明体素的数量）粘土朝着同样方向移动时传达双倍推或拉的体素数量，并在朝相反方向移动时减半数量，所以我们 可以通过二进位检索让时间与log2(n)成正比而发现适当的位置。再次假设用户只需要在界面上面向每个点进行一次操作。那么操作需要移动到下一个体素便是2log2(3)，因为这一 移动是二维的。然后总体的操作便是W = n2 ′ 2log2(3) ′ log2(n) = 2n2log2(n)log2(3)。尽管我们将移动限制在一个界面上，但这却比之前的UI还糟糕，这主要归咎于用于推 并拉动虚拟粘土的点击数。
在第四个界面中，用户将基于2D鼠标绕着界面移动，并像之前那样推/拉进/出点数。然而，粘土的界面将会有张力，所以推进/出一个点数将同时拖曳所有邻近的体素。结果便是界 面将基于与你使用控制点和齿条定义曲线的方式那样进行雕刻。然后在W = 2c2log2(n)log2(3)中，控制点数c便成为了雕塑的不规则函数，而不是体素的数量。对于高分辨率建模 ，n>>c，并且W=O(log2(n))。这是非常优秀的用户界面。
为了将认知工效学整合到W中，你也要计算玩家用于记住每个键盘快捷键和可点击图标的含义，并整合操作的衡量将显示信息转换到相关可用信息所需要的内存量。你同样也可以为 内存检索时间添加一个条件。面向不同内存类型的内存检索时间是明确的；为了记住一列选择汇总的一个，时间便是K+an，这里的n是选择的数量而K和a则是常数。如果你不知道如 何按比例分配认知条件让它们能够与非认知条件成比例，你可能会对它们进行分开概括。
