特效元素也很占用带宽，例如爆炸场景中的颗粒效果、关卡中的动态事件。后者属于地图动画效果，比如说起重机、电梯的移动，或者墙壁的爆炸。如果要与这些事件进行互动（ 游戏邦注：例如向电梯间扔一枚手榴弹或者让一名角色站在移动的物体上），那么地图上这些移动内容的精确位置就必须挨个衔接在一起。在此，我也深信未来多人游戏的地图会 包含更多特效和地图动画元素。
第二个技术局限性就是游戏事件的同步性。在动作类游戏中，如射击等关键事件的同步性，直接决定游戏质量的高低。同步性问题也是招致许多玩家不满的主要原因之一。当一名 高手级的玩家将光标指向其瞄准对象并扣动扳机时，他当然希望子弹准确无误地命中目标，稍有半秒钟的延时都会让他感到不快。资深玩家已经摸透了游戏特点，假如游戏系统并 未像他们预想的那样迅速作出反应，他们就会产生一种“受骗”之感。Xbox平台上的《命运战士》等一些游戏很巧妙地处理了这个问题。
因此，玩家很容易钻设计失误和漏洞的空子，在游戏中采取作弊手段，并与其他玩家交换这些信息。过度使用地图功能的另一个结果就是，假如地图设计缺乏丰富的策略，玩家很 快就会失去兴趣。多人游戏地图必须避免经得起玩家成百上千个小时的游戏体验，不可让他们心生厌倦。《分裂细胞2：潘朵拉计划》发布一年后，每天仍有成千上万玩家光顾其多 人游戏模式，它和《光晕2》都可以算是地图设计的成功典型。
以《细胞分裂：明日潘多拉》和《细胞分裂：混沌理论》多人版中发布的Deftech地图为例。虽然内庭院的设计简单，但是玩家的移动路径选择非常多。地图中包含3个主移动路径 ，分别是院子、人行桥和集装箱顶，还有2个次移动路径——地下网状隧道和庭院上空的电缆。这些不同的移动路径丰富了移动可能性，从而增加了可采用的战术数量。因而， Deftech庭院成为死亡竞赛粉丝最钟爱的地图之一。
游戏设计本身必须为地图的耐用性做出贡献，可以通过设定关卡设计中特别元素的功能来实现。在《孤岛惊魂》多人版的Assault模式中，工程师可以在预定地点构建防御工事或炮 塔。当关卡设计为这些战术性举措提供施展地点时，游戏设计就变得更有意义。炮塔可以防守路口，墙体可以阻挡进攻口，这样防御者就可以将注意力集中在敌人的其他进攻口上 。
玩家应当可以通过观察周围的环境来判断当前所处位置以及在地图中的方位。在《细胞分裂：明日潘多拉》中，Krauser Labs地图有3个藏匿任务目标的房间。这些区域的装饰颜色 各不相同。因而玩家很容易就可以判断出自己的当前位置并找到合适的通道。
第2种可以采用的技术是构建不对称地图或区域。我的团队中有个关卡设计师利用《细胞分裂：明日潘多拉》中的免费关卡编辑器制作了地图Long Run，地图平面倾斜，像是个巨大 的楼梯。通过自身位置与地图中其他楼层的对比，玩家就可以迅速明白自己所处的位置。
现在我们已经看到，户外游戏目标的设计相当简单。室内目标设计更为复杂，因为墙体会阻挡玩家的视线。这个问题的解决方案是，在地图布局和目标间创建显而易见的连接。比 如，地图分为3个区域，其中每个区域都含有一个目标。只要玩家掌握了这种规律，将其引向目标就变得更为容易。室内目标设计的第2个规则是，任务目标与周围环境有一定的差 别，这会直接将玩家引向目标。
目标导航还有个挑战：帮助玩家理解他可以通过哪些途径到达任务目标地点。最佳的解决方案是，同时向玩家展示目标和到达目标地点的方法。方法之一是设计大小中等的地图， 让攻击者可以看到地图全景。下图便是River Mall地图，这是《细胞分裂：明日潘多拉》Xbox版本的流行地图，攻击者从首个区域顶端进攻。这样，他们可以看到有图标标志的任 务目标和通向目标的所有路径，包括楼梯和人行桥等。
我的首个建议是，尽可能地让地图多样化。在《细胞分裂：混沌理论》中，我们将探索原创图像主题视为关键部分。Aquarius地图呈现的是海洋博物馆，Orphanage的场景是森林中 荒废的学校，Missile Strike的主题是古老的复杂地堡。
在Club House中，攻击者可以通过摧毁悬空式天花板或升降地板来开辟新路径，但是这么做也会让防御者发现他们的位置，防御者可能会向他们抛手榴弹。在Bank中，攻击者可以 攻击主机来引起照明故障，让位于任务目标所处房间的防御者处于弱势。因为这些动作只能在主房间内做出，所以防御者必须做出艰难的选择：是防守这些次级目标，削弱任务目标的防御还是专注于防御后者，不顾对手的行为。
基本上，《细胞分裂：混沌理论》的所有地图和那些可下载地图都包含此类事件。这种设计得到玩家的高度认可，《细胞分裂：明日潘多拉》和《细胞分裂：混沌理论》开发商 Ubisoft Annecy studio在多人Versus模式中展现出关卡设计的天赋。
但是在玩了几周的游戏后，我们发现攻击玩家找到了一个进入这个房间的技巧，即利用防御者走出房间的那个时刻。只要玩家能够进入房间，他们便能在防御者诞生时刻轻松地杀 掉他们。而这种漏洞会让游戏失去可玩性。幸运的是，很少玩家会这么做，因为地图上划分了不同区域，所以只要玩家完成了第一个区域的任务，他们便会自然地移动到下一个区 域。
能够影响游戏平衡性的首个关卡设计方案是关于地图的尺寸以及它可容纳的玩家数量。小地图更难维持游戏的平衡，因为地图中任何微小的细节都会因玩家活动的密度和速度而加 倍放大。相反地，如果地图尺寸过大，玩家也会很容易感到厌烦，因为他们能够遇到的目标实在太少了。所以玩家的数量以及地图的尺寸之间的比例非常重要。大部分情况下，我 们总是会选择较大的地图。因为它们能够提供更多战术机遇，并且让玩家难以从地图漏洞中占到便宜。
这个观点是指提供给玩家足够的“道具”，帮他们找到解决不平衡性的对策。致力于《细胞分裂2：明日潘朵拉》以及《混沌理论》的多人游戏版本的游戏设计师很好地控制着这种 游戏系统。即游戏既提供给玩家角色一些具有巨大潜能的装备，同时也提供给其对手一定的机遇。以下是一些例子：防御者所拥有的激光能够帮助他通过扫射周边区域而迅速找到 攻击者的藏身处；但同时攻击者也能够从远处明显地看到这个激光而发现防御者的地理位置，并观察他在寻找什么。攻击者通过隐形服掩饰能够减少暴露身份的风险，但是这么做同时也会限制他的行动速度。防御者在分布激光矿井时非常谨慎， 但是攻击者却可以通过激活电子视觉轻松地找到到它的射线。这种方法能够进一步约束任何拥有超强能量的特定装备。
一般来说，在游戏开发阶段进行游戏测试非常重要。特别是对于多人游戏来说。玩家，通常来说是指硬核游戏玩家，总是愿意花费许多时间去探索地图上的每一个细节内容，并利 用这种类型游戏中的各种策略：测试所有武器和装备，寻找关卡设计中的任何漏洞，并因此而获得竞争优势。如此，游戏或关卡设计的缺点便会够迅速暴露出来，而让游戏变得越 来越无趣。所以，适当的游戏测试能够帮助设计师更好地找到关卡设计中的缺陷，或者游戏参数中的糟糕设置，如武器的能量，生命级别等。
我们在游戏设置上下足了功夫。根据经验，我知道游戏特定功能（武器，装备以及行动等）的广泛使用也会根据玩家状态，玩家用于熟悉游戏的时间以及游戏设置发生巨大变化。 只有由经过挑选的玩家所进行的长期游戏测试，方能确保游戏设置在经过几个小时的游戏后还能保持准确性。《细胞分裂2：明日潘朵拉》中的烟雾弹设置便经过了多次的游戏测试 。事实上，这些烟不仅会模糊玩家的视野，如果停留时间过长，也会让防御者感到窒息。烟雾的影响范围以及持续时间便是游戏中的一些参数，而如果设置不合理的话，便会带来 很多负面影响。如果手榴弹的威力过大，它便会成为游戏中一种力量失衡的武器，即攻击者只要投射出一个手榴弹就有可能完全至防御者于死地。相反地，如果手榴弹的效率过低 ，这种战术也会变得不再有趣，且玩家也不会选择使用它了。我曾经提到过，玩家总是会不惜任何代价去获取胜利。所以为了胜利，他们会快速放弃那些没有用的装备，而这时候 我们投入开发这些装备的资源以及特效储存空间也就白白浪费了。
我们可以通过一道光或者一团烟掩蔽一个复杂的动画，而避免带宽出现超负荷的情况。我们可以在《细胞分裂2：明日潘朵拉》的工厂地图上最大限度地使用这种技巧，而工厂会因 为其中一名防御者引起的爆炸遭到破坏。整个房间里都是爆炸滚桶，如果一名防御者用子弹打击它们或者朝着它们发射手榴弹，这些滚桶便会爆炸。但是显然玩家对此并不感兴趣 ，因为房间的布局将会发生改变，而防御者的移动也会受到最大限度的约束。而如果不消耗带宽，便不能执行这些地图事件。负责地图设计的关卡设计师将能够成功处理这个事件 ，即设置让房屋被炸毁时，屋内的所有东西都会消失殆尽。因此，玩家不能够看到爆炸过程，而且如果玩家选择从房间外部发射弹药，烟雾也会阻挡他的视线而让他难以看到自己 行动的结果（如下图所示）。
创建一个多服务器架构。传统意义上讲，在多人游戏期间，其中一个游戏设备充当着服务器的角色，并同步所有因用户机器引起的交互行为。这种架构能够保证所有机器间的同步 性，但是却会因此减慢数据的转移速度，因为关于用户A和B的交互信息必须先通过服务器进行传输。在多服务器架构中，每台机器同时扮演着服务器和用户的角色。按照这种方法 ，当玩家A与玩家B进行互动时，并且其他玩家并未参与其中，那么数据将直接在A、B玩家之间进行交换。这种方法曾经用于《Soldier of Fortune》的Xbox版本游戏中，这款游戏 因为高精确度而大受第一人称射击游戏群体的赞赏。比起传统的架构，多服务器架构还有一大优点便是，不会因为服务器的连接失败而破坏整体游戏进程。在多服务器架构中，玩 家可以根据自己的想法随时开始并结束任何一段游戏过程。
增加任务目标的数量，并将其分散于地图上。《细胞分裂》和《战地》等系列游戏成功落实了这两大机制。在《战地》中，当玩家选择工程师角色时他便能够接近许多次要目标， 如摧毁雷达站等。另外一个能够让玩家分散开来的方法便是允许玩家使用某些武器，但是前提是他们必须与同伴保持一定的距离。《战地》同样也使用了这一机制，即让玩家驾驶 飞机或者控制炮台。
第一个解决方法很简单也特别有效。即在游戏中添加一些协作模式。玩家与玩家间不会进行真正的血肉之战，因为这是对待敌人（即受游戏AI控制的bots）的方式。这种解决方法 让各种级别的玩家能够一起游戏，并且不会因为某些玩家更厉害而备受打击，敌人就不再像人类的对手那样危险且难以预知了。同时，资深玩家还能够将自己的经验与游戏新手进 行分享。最后，这种协作游戏也能够给玩家带来一定的乐趣，因为朝着一个共同的目标相互合作是人类冒险的主要推动力。育碧加拿大工作室便创造了《分裂细胞3：混沌理论》的 “合作”多人游戏模式，并取得了巨大的成功。
第二个解决方法较为传统。创造一种游戏机制，即根据玩家的成绩将其进行分类，并允许他们选择与自己同级别的玩家进行游戏。这种机制常出现于多人游戏中，但它却存在着许 多不足之处。所以很多玩家常常会发现，尽管自己选择的是具有相同“级别”的对手，但是最后面对的其实是非常厉害的资深玩家。实际上，在一个不熟悉的地图里玩游戏自然意 味着最后的失败。创造一个能够正确评估玩家级别的分类系统其实很难。正是意识到了这个问题，微软才提出了“TrueRanking”这一创造性分类机制，其中利用了许多有效参数以 便有效区分玩家等级。
第三个解决方法就是提供给玩家新手教程。在《混沌理论》的“对抗”模式中，因为我们知道游戏较为复杂，所以我们便认真思考了这一问题。因此，包含有新手教程的游戏便能 够帮助玩家学习并理解如何控制角色。我们添加了一个模式让玩家只要循着一条光路以及屏幕下方的解释便能够轻松地访问游戏地图并寻找主要功能。除此之外我们也详细说明了 玩家可使用的任何装备的相关元素。并且在玩家真正进入多人游戏挑战前，我们还设置了地图考核机制，玩家通过测试之后才算是真正掌握游戏设置的基本内容。
而大量的辅助内容会带来何种结果？新手教程虽然能够让新手玩家更轻松地开始游戏，并让他们不会轻易迷失于游戏地图中，但是却不能直接帮助他们与资深玩家进行对抗。毕竟 ，只是阅读一本驾车指南并不意味着你马上就能开车。《战地2》中出现了更妙的解决方法，即提供一些具有前后关系的帮助内容。当玩家从一座建筑物跳下或者从飞机上跃下时， 他可以打开降落伞以避免受到重伤。但是如果玩家不能够打开降落伞而死亡后，系统就会提示他降落伞的存在及其控制方式，以便玩家重玩游戏时能够利用这一功能。如果能够考 虑到这点，那么新手教程便能够发挥更大作用。
第四个解决方法便是整合一个正面或负面的“差点系统”（游戏邦注：其目的是允许程度不同的所有业余高尔夫球员能在任何球场公平竞争，从而使高尔夫运动更加富于乐趣）。 根据玩家的分类，他能够受益于额外的生命值或者较少的弹药。这种机制能够让不同级别的玩家趋于部分平衡。然而，为了能够同时满足资深玩家，游戏同样也需要补偿给这些玩 家新弹药或者新装备。《孤岛危机》的设计师正在利用这一方法为这款游戏的多人游戏版本创造一个智能系统。
首先是用户界面。它的设计必须围绕一些容易理解的原则。我们都知道通过掌机上的两个模拟摇杆便能够控制游戏角色，但是对于新手来说这就不是一个简单的机制。通过实验性 的游戏测试你能够了解到初学者对于游戏界面的理解与看法。一大解决方法便是创造一个自动适配的用户界面，让新手能够执行一些基本行动，并随着级别的提高而给予他们更多 新功能。语音命令或者控制器，如Wii-mote的使用能够彻底改变我们与游戏间的互动。而如果你认为这些方法都过于理想化，那么你也可以选择单纯地简化用户界面。《光晕2》的 界面便是一个优秀的直觉型界面，因为它并未设置过多的控制内容。
接下来是地图。我先列举出几个能够帮助玩家理解地图的方法：选择大地图而不是复杂布局，使用一些容易识别的任务目标，通过提供清晰明了的结构而维系起任务目标和地图布 局间的联系，玩家能够自己定位目标，创造一个易识别的导航网络体系，提供给玩家一个地图全局布景或部分内容，或者选择非对称性地图。《战地》系列游戏中便提供给玩家一 副较大的地图，但同时也提供了简单的导航体系以及清晰明了的目标。所以不要再把地图当成是什么难以解决的大问题了！
第一种方法是技术条令。主要是指设立一个智能代理帮助玩家分析游戏过程并有针对性地提供建议。举个例子来说，如果第一人称射击游戏玩家长时间未有任何行动，那么智能代 理便会提醒他现在很容易遭到狙击手的攻击。而如果代理发现玩家总是在使用相同的方法，它也会帮助玩家寻找新的方法。但是所有的这些都是理论上可行的内容，真正实践起来 并没有那么容易。而就像我们在《战地2》中所看到的，提供给玩家一些前后关系的信息便是一种合理的方法。
如果从创造易用性多人游戏的角度来看，后面两个因素便特别重要。大规模的地图能够让玩家更容易注意到并避免远处敌人的攻击。例如在《战地》中，玩家经常因为不知道敌人 的所在位置而遭到攻击死亡。第二个元素是，如果游戏地图能够容纳更多玩家，那么便能够同时整合进更多休闲玩家了。实际上，当玩家是一个庞大群体的一份子时，他便能够加 入团队并跟随那些了解地图以及地图策略的人而行动。
《Campaign 2》、《Flawless Cowboy》和《Reunion Tour》
杀死Covenant。在Campaign 1中看到人类舰队和Pillar of Autumn被粉碎会提升玩家的仇恨，让他们愿意更长时间待在游戏中只为了杀死Covenant。
在许多其他关卡中，Ken Kong必须破坏一些墙体，关卡团队提议加入不同的McGuffin（游戏邦注：这是书、电影中用来推动情节发展的对象或事件）使他能做到，比如允许他使用 身边的一个不平衡的重物来破坏墙体。
案例：《Kung Fu Zombie Killer》
我们以幻想游戏《Kung Fu Zombie Killer》为例，详细地分析一下你所拯救的幸存者类型对它的玩法变化的影响。
虽然你可能以为《Kung Fu Zombie Killer》的基调可能被定义为“滑稽的”，但它的表述对整个开发过程具有重大影响。
幸运地是，《Kung Fu Zombie Killer》的关卡顺序是非常灵活的，但大部分游戏并不是如此。在某些情况下，答案是，反馈给关卡团队，指导他们如何把情绪和玩法更好地融合起 来。
Multiplayer Level Design In-Depth, Part 1: The Specific Constraints of Multiplayer Level Design
by Pascal Luban
The rules that govern single player level design are becoming more and more well known. They help make sure that the gamer’s experience is controlled in terms of difficulty, rhythm, renewal etc. But multiplayer level design does not follow the same constraints as those of single player level design. I will start by describing the specific constraints of multiplayer level design.
The first technical constraint is the infamous bandwidth bottleneck. A game machine may be high-powered and capable of processing a huge amount of information, but if the “pipe” that links it to other machines is too narrow, little information can be exchanged and the game is therefore slowed down or impoverished.
What are the main points of a multiplayer game that eats up bandwidth? First there is character movement and animations. In most multiplayer FPS games, character animation is very limited. What characters do most often is run, jump or crouch. But in games such as the multiplayer version of Splinter Cell, the wealth of animations is at the heart of the game.
Characters can grab each other, perform acrobatics, hit each other etc. This wealth of animations is very demanding in terms of bandwidth. I am convinced that such a high quality of animations will become more and more present in future multiplayer games, not only because they provide more realism, but also because they enlarge gameplay possibilities, as it may be noticed when playing Splinter Cell in versus mode.
One of the numerous complex animations available in the multiplayer version of Splinter Cell – Pandora Tomorrow and Chaos TheoryOther large bandwidth consumers are special effects, such as the explosions with their particle display, and the dynamic events in the levels. The latter are map animations, such as the movement of a crane or of an elevator or the destruction of a wall. If it is possible to interact with such events (by throwing a grenade into an elevator or by positioning a character on a moving object), the exact position of these moving parts of the map must be followed image by image. Once again, I am convinced that maps of future multiplayer games will contain more and more special effects and map animations.
Special effects in a game are not only used for cosmetic purposes. They may be used to disturb vision, darken or light up the environment, leave footprints etc. Their use in terms of gameplay is obvious.
The same is true for map events. We have widely used such events in the multiplayer maps of Splinter Cell – Chaos Theory. For example, in the Aquarius map, the level designer positioned a destructible ventilation grille near a locked entry, with one of the map’s mission objectives behind (see the illustration below). If a defender uses a grenade close to this grille to kill an opponent, he desroys the grille and thus provides the latter with a quick route to his objective.
In this way, the constructive use of map events helps bring a new dimension to the gameplay of the map by changing both its layout and the defenders’ tactics. The maps of Splinter Cell – Chaos Theory and certain maps of Splinter Cell – Pandora Tomorrow are full of such interactions and use of special effects for gameplay purposes.
The amount of information exchanged among machines during a game session is proportional to the number of players. One of the direct consequences of the bandwidth bottleneck is the decision that has to be made regarding the number of players and the richness of the game (animations, special effects, map events etc.).
A destructible ventilation grille in Aquarius, one of the multiplayer maps in
The second technical constraint is the need to synchronize the events of the game. In the case of action games, the synchronization of the key events, such as shooting, is essential for the quality of the game. Synchronization problems account for the main cause of dissatisfaction among gamers. When a good player places the cursor on a moving target and pulls the trigger, he expects the bullet to reach the target immediately and exactly where he aimed at. A half-second delay is unacceptable. Good players are very precise in their game and feel “cheated” if the game does not react as quickly as they do. Some games, such as Soldier of Fortune on Xbox, handle this problem very efficiently.
The third technical constraint is the lack of control on what the players will do. If too many players are found in the same place on the map and start generating explosions and causing many map events, all concentrated in the same area the amount of information exchanged between machines becomes too large and the refresh rate of the images plummets.
This problem does not occur in single player games, because the level designer would have made sure that the events which are likely to slow down the machine are evenly distributed. But in the multiplayer level, everything is possible. It is difficult to prevent the players from willingly “stuttering” their game session by overloading the CPU and the bandwidth, but good level design should minimize the risk of overload by encouraging players to spread out in the map.
Intensive Use of the Maps
I will deal now with one of the major differences between the maps designed for single player games and those for multiplayer games. In a single player game, the player goes through a level with a single objective in mind, finishes it and passes to the next. He only spends little time in each level. But in multiplayer games, the players will spend hundreds of hours on each map. All map weaknesses will then be found.
Thus, design errors or bugs that allow cheating are revealed and exchanged among players. A second consequence of this hyper-use of the maps is the risk of player boredom if the map is not tactically rich enough. Multiplayer maps must support thousands of hours of play without letting the player feel bored. One year after the marketing of Splinter Cell – Pandora Tomorrow, thousands of multiplayer sessions were still being played every day, this is the same for other tactically rich maps such as some Halo 2 maps.
The Search for Efficient Gaming
The third typical constraint of the multiplayer level design is the consequence of the highly competitive game style that is specific to this type of game (except for cooperative modes). Since the essence of the multiplayer game is to crush the opponents, the players search for the most efficient tactics, whereas in a single player game, the players tend to play at their own pace and explore all the possibilities provided by the game.
What are the consequences? First, players completely ignore many game features (weapons, animations, specific map functions etc.), even if they show a real potential. They will only use the most efficient features.
The second consequence is the strong incentive to cheat or to take advantage of the map’s weaknesses or bugs. This problem is so important that it renders the classification in many multiplayer games null and void.
The Difficulty in Getting Casual Gamers to Play Multiplayer Games
The fourth constraint is the difficulty in getting average or casual gamers to engage in multiplayer games. The reason for this is simple: nobody likes being humiliated by losing repeatedly to gamers that give you no chance. Playing against a human opponent generates a lot of tension and makes the game more exciting, but also increases the stress level of an inexperienced gamer.
It will then be really difficult for him to put up with the three challenges he must handle simultaneously: control of the interface, knowledge of the maps and tactical vision of the game. There are many classification systems that regroup the gamers by level, but the majority only provides an incomplete solution to the problem of integrating the beginners.
At the moment, multiplayer games are reserved for the hardcore gamers. If we want multiplayer games to get out of their niche, it is vital that we design them with this in mind and not simply adapt them.
The Weight of the Gamers’ Community
Finally, the last major constraint is the weight of the gamer community.
A multiplayer game exists thanks to its players, who are hungry for new content (new levels), improvements, competitions and possibilities to adapt the game to their own style of play. The creation of a community of gamers around a game may be a blessing for a developer and its publisher, but the development of the game must be prepared in view of this.
In subsequent installments of this series of articles devoted to the multiplayer design, I will tackle my suggestions regarding:
The level design
The challenge of fine-tuning the game
The design around technical constraints
The design of a mass-accessible multiplayer game.
In the first part of my series devoted to the design of multiplayer levels, I offered a detailed view of typical design constraints in multiplayer compared to that of a single player level. I would now like to give some suggestions to remedy these problems with intelligent map design.A good level design for a multiplayer map should respond to three hallenges:
Durability. A map should withstand thousands of game sessions without letting players feel bored. It must provide continuous tactical challenge.
Accessibility. Navigation in a map should be clear. Remember that complex map design is one of the main difficulties a new player is confronted with.
Entertainment. This need is obvious, but its rules are difficult to define.
Challenge 1: Durable Maps
Let’s begin by the durability of the map. What are the level design rules that I recommend to respond to this challenge?
1.) My first recommendation, and probably the most important, is to put the third dimension to good use. Use and exploit the vertical dimension in your maps and give the players reasons to use the volume of the map and not only its two-dimensional layout.The example below is taken from the Museum map, available in both Splinter Cell – Pandora Tomorrow and Chaos Theory. This medium sized room perfectly illustrates how a very rich gameplay, based on movement and dissimulation, can be created by applying this rule. Players have several partially overlapping circulation levels at their disposal. They can move vertically by using the stairs, climbing the beams or simply by jumping. Finally, the room includes enough objects to enable players to hide, but also to use these surfaces to make their grenades bounce.
(One of the rooms where the third dimension is well used in the Museum map (Splinter Cell – Pandora Tomorrow and Chaos Theory))
This rule may well be applied to exterior settings, too, such as in Battlefield maps, where the players can climb roofs, cranes or towers and can also take flying vehicles.
2.) My second recommendation is to build open maps to enable the creation of an infinite number of paths. The warehouse, plant or building site themes suit this kind of map perfectly.
Take for instance the Deftech map, published in the multiplayer version of Splinter Cell – Pandora Tomorrow and Chaos Theory. The inner courtyard, although a very simple design, provides a practically infinite number of movement possibilities. It contains three main levels of movement – the yard, the footbridge and the roof of the containers – as well as two secondary levels: a network of underground tunnels and overhead cables. By combining these different levels
of movement, a significant variety of movements — and therefore of tactical possibilities — is obtained. It’s not by luck that Deftech yard is one of the most appreciated maps by deathmatch fans.
(The yard of the Deftech map (Splinter Cell – Pandora Tomorrow) illustrates how vertical movement is created in an exterior setting)3.) Increase the number of events in the map, especially those that make the players change their tactics. The Aquarius map, available in Splinter Cell – Chaos Theory, is a good example of the use of events. In my previous article, I explained how certain ill-considered actions of the defenders open new possibilities of infiltration to the attackers in this map. But Aquarius also provides other map events that have a direct impact on players’ tactics.
Each time the attackers take over one of the five mission objectives of the map, they trigger an event in the map that handicaps the defenders: smoke release, unlocking of doors, lights turning off etc. All Splinter Cell – Chaos Theory maps, as well as the two maps available for download for Pandora Tomorrow, are full of interactions like these. Experience shows that gamers really appreciate this extra dimension of gameplay.
The game design itself must contribute to the map durability, by producing features that acquire their importance according to specific elements of level design. In the Assault mode of the multiplayer version of Far Cry, engineers can build fortifications or turrets in predetermined locations. This game design feature makes sense when the level design provides locations where these buildings offer a real tactical interest. Thus, a turret may cover an access path or
a wall may block an entry to allow the defenders to concentrate on other entries.
(A room in the Aquarius map (Splinter Cell – Chaos Theory) in its normal state. It is well-lit and provides few hiding places for the attackers. It is a “safe” room for the defenders.)
(Here is how the same room looks when the attackers reached one of their mission objectives. The darkness of the smoke makes the room very dangerous for the defenders.)
Challenge 2: Maps Where Navigation Is Clear
The second challenge a multiplayer map designer should respond to is accessibility. It’s a major problem for players who discover a new map, and especially for beginners. Designers should keep in mind that the stress and the game rhythm decrease the player’s capacity to properly analyze the setting.
The objective of the level designer is to design the map in such a way that the player can always answer three basic questions, regardless of his location: Where am I? Where should I go? How do I get there?
Where Am I?
By looking at the environment, the player should be able to determine his current position and locate it on the map. In Pandora Tomorrow, the Krauser Labs map contains three rooms that shelter the mission objectives. Each of these areas is characterized by a different colour. It is therefore easy for the player to determine his current position and to guess where the passage leads him, thanks to the color light that filters through the entries to the areas in question.
In an exterior map, it is still simple to enable the player to determine where he is, by adding setting elements that are visible from a distance, as is the case in this multiplayer map of Halo 2.
A second technique consists in building asymmetrical maps or areas. Long Run, a map designed by one of the level designers of my team with the free level editor of Pandora Tomorrow, is built on an inclined plane, like a gigantic staircase. Simply by noticing his position in relation to the other levels of the map, the player can immediately locate himself.
(The tower is visible from all points in this Halo 2 map and makes it easy for the players to get their bearing.)
(Long Run, a complex yet easily navigable map thanks to its asymmetrical design.)
A third technique consists in proving the map with a simple block plan, as shown below.
Where Should I Go?
We have just seen a few techniques meant to assist the player in determining his position in the map. Let’s see now how we can help him understand where he should head to achieve his mission objectives.
Many multiplayer games ask the player to reach such objectives as to capture a flag, plant a bomb or hack a computer terminal. The player should be capable of identifying and especially guessing their target’s location simply by analyzing the map layout.
Two rules should be applied:
- The mission objectives, or a related setting element, should be visible from far away
- The mission objective itself should be clearly distinguished from the surrounding environment.
The flag poles in Battlefield perfectly apply these two rules. If the game imposes more discrete mission objectives, such as planting a bomb, it is possible to associate a large object such a radio aerial to the objective itself.
(The location of game objectives cannot be made easier than in Battlefield.)
We have seen that it is pretty simple for outdoor game objectives. However, it is more complicated for indoors objectives because the players can’t see though the walls. The solution is to create an obvious link between the map layout and the objectives. Thus a map designed around three areas will contain one objective per area. As soon as the player understands that there is one objective per area, it will be easier to guide him to the objective, as soon as he gets to the right area. The second rule, which consists of mission objectives that are slightly different from the surrounding environment, will direct the player toward his target.
These rules were successfully applied in the Deftech map of Pandora Tomorrow. The mission objectives are distributed in three separate buildings. They are all located on the first floor. Although the map is huge, very few navigation problems were encountered during the playtests. While I was supervising the playtests, I noticed how quickly the players were learning to navigate.
I will finish with a comment on using overlay icons as an aid to navigation. We widely used them in Splinter Cell – Pandora Tomorrow and Chaos Theory, but their efficiency is questionable. In fact, when indoors, they often tell players to go straight through the walls, as they indicate the shortest route. These icons may be useful, but do not represent a miraculous solution to the navigation problems and could disturb the player by overloading the screen.
How Do I Get There?
There is still a challenge in terms of ease of navigation: to help the player understand what paths he can take to reach his mission objectives. The best solution is to show him both the objectives AND the means to get there at the same time. One way to do this is to design maps with average-size areas and give the attackers the possibility to have a panoramic view. In the example below taken from the River Mall map, a very popular map available for download for the Xbox version of Pandora Tomorrow, the attackers start their infiltration through the top of the first area. That way, they can see mission objectives, marked by overlay icons, and all the paths that lead to them: staircases, footbridges etc.
(In River Mall (Splinter Cell – Pandora Tomorrow and Chaos Theory), the attackers can see both their game objectives and the means to reach them.)
Challenge 3: Fun Maps
The biggest challenge for us is to create a fun map. If the rules described in the previous parts are applied, all maps would resemble each other, but all gamers like to be surprised and challenged. From the gamer’s point of view, having a large number of maps that all look alike is less satisfying than a smaller number of varied maps.
My first suggestion is to use diversity as much as possible. In Chaos Theory, we made it a key point to search for original graphic themes: the Aquarius map represents an oceanographic museum, Orphanage takes place in an old abandoned school in the middle of a forest, the theme of the Missile Strike is an old bunker complex, etc.
But diversifying the graphic theme is not enough. It is also necessary to differentiate the gameplay offered by each map. Thanks to the wealth in game design, we were able to bring diversity that is unusual for multiplayer maps. Each map forces the players to adapt their tactics in function. The table below summarizes the main features of the Chaos Theory maps from the gameplay perspective.
Aquarius. Open map. Various types of mission objectives are available. The taking over of one of them affects the defending of the map.
Clubhouse. Open map. Many destructible background elements.
Factory. Open map. Certain mission objectives are only available thanks to the concerted action of the two attackers.
Missile Strike. Linear map. Various types of mission objectives are available.
Orphanage. Linear map that provides a large outdoor area.
Station. Linear map that begins with an assault area.
A year after the release of the multiplayer version of Splinter Cell – Chaos Theory, all its maps are still being played.
My second suggestion is to provide the maps with secrets or actions that require complete mastery of the game. Such aspects of the maps are very rewarding for experienced gamers, who make up your target audience.
In this way, certain Far Cry maps include ideal places for snipers, whose positions are camouflaged by vegetation. In Chaos Theory, we included specifically designed locations for the spies to use when undertaking their most spectacular but also their most dangerous attacks: to catch a mercenary who crosses over a footbridge and knock him off into space. The Factory map contains mission objectives that are only reachable if the two attackers carry out an action in cooperation, a dangerous action, in the Versus multiplayer mode.
My third suggestion is to plan a number of map events such as moving elements or destructible background sections. These events must respond to a gameplay objective and multiply the tactical opportunities; otherwise they will only have a superficial contribution to enriching the map. I have already mentioned map events that modify the gameplay in the Aquarius map, here are a few more:
(Attacker getting ready to grab a defender and throw him over the guardrail in Club House, one of the multiplayer maps provided in Splinter Cell – Chaos Theory.)
In Factory, the attackers can turn on a digger and break down a wall to clear a path to a new mission objective (see the screenshots below). Besides being spectacular, this type of event is very interesting from the gameplay perspective. By hacking the digger, the attacker shows his presence and exposes himself to the defenders’ firing, but if his action ucceeds, he enlarges the perimeter to defend and therefore makes his team’s job easier.
In Club House, the attackers can make new paths by destroying suspended ceilings or raised floors, but by doing so, they also give the defenders their position and enable them to throw grenades. In Bank, the attackers can hack consoles and cause lighting breakdowns or a jamming that disadvantages the defenders in the room that shelters the mission bjectives. Because these operations can only be triggered away from the main room, the defenders must make a
difficult choice: to defend these secondary objectives and weaken the defense of the mission objectives, or to oncentrate the defense on the latter and bear the consequences of the hacking undertaken by the opponents.
(In Factory, one of the multiplayer maps of the Splinter Cell – Chaos Theory Versus mode, two mission objectives are not reachable at the beginning of the game. They are located behind a wall. To destroy it, the attackers must hack the digger.)
(As soon as the digger is activated, the wall breaks down, giving access to two new mission objectives and increasing the space to be defended by 30%.)
Practically all Chaos Theory maps, as well as those available for download contain this type of event. Highly appreciated by gamers, they are a tribute to the talent of the Ubisoft Annecy studio where the “versus” multiplayer modes of Splinter Cell – Pandora Tomorrow and Chaos Theory were developed.
In my next article, I will tackle the problems of map setting and game system, the design around the technical constraints and the design of a multiplayer game that is more accessible to a wider public.
My first paper dedicated to multiplayer level design tackled the specific constraints imposed by the multiplayer game mode compared with that of single player. Later, my second paper detailed the level design rules that I consider to be the most important to respond to these constraints. Today, I will tackle another equally important aspect of the development, balancing.
Balancing consists of ensuring that no player or group of players can keep the advantage systematically throughout the game, by making the most of a game parameters (the power of a weapon for example) or of a weakness in the map. This problem is particularly seen in multiplayer games, because their users have plenty of time to discover the faults of the game and exploit them to their full effect. As maps are played for tens of thousands of sessions and players easily swap tricks among themselves.
A fault in a map could potentially kill the entire map by enabling a player or a group of players to reach a highly destabilizing advantage. That very problem was raised in one of the multiplayer maps we developed for Splinter Cell – Pandora Tomorrow’s Warehouse. In this map, divided into three areas, the killed defenders spawn in a small room next to the first play area. This room is obviously reserved to the defenders and the attackers are not supposed to have access to it.
After a few weeks of use, we realized that attacking players had found a technique to enter this room by taking advantage of the moment when one of the defenders walked out of it. As soon as they were inside, they could easily kill the defenders as soon as they respawned! Such a fault could have made the map unplayable. Fortunately, this was not the case, thanks to the fact that the map was divided into areas, because as soon as the mission objective of the first
area was reached, the players move on to the next area.
A poorly balanced game ends up making the players lose their interest, because nobody likes fighting against an opponent who benefits from an unbalanced advantage. Note that balancing isn’t only about level design, but also the game system and the game design. Three directions must be considered to balance a multiplayer game: the level design itself the game design and the playtests.
The first level design decision that is likely to affect the balancing of a game is the map’s size and the number of players it can support. A small map generally makes balancing more difficult, because tiny details are amplified by the density and the speed of the action. Conversely, if the map is too large, the players will get bored because encounters will be rare.
The choice of the ratio between the number of players and the size of the map is therefore very important. In most cases, opt for relatively large maps. They offer more tactical opportunities, and it will therefore are more difficult for the players to take advantage of the faults of the map.
The map layout itself can favor the balancing of the game. An open map (outdoors, for example) and the use of the third dimension (see my paper dedicated to map design) will make it difficult for bottlenecks, which could create destabilizing situations, to occur. Such maps offer more tactical opportunities than “flat” indoor maps.Finally, the map should also offer various opportunities to use the game design features: weapons, equipment, moves, and so on. The maps of the multiplayer versions of Splinter Cell – Pandora Tomorrow and Chaos Theory include many places where an attacker can hide to prepare to ambush a defender, objects to hide behind, high footbridges to supervise a large area and accurately throw grenades, and pipes along the ceiling of rooms used by the defenders which allow the attackers to jump them.
The Game System, or The Balancing Of Opposing Forces
The idea is to provide the gamers with enough “tools” so they can find a counter-measure to a possible imbalance. The game designers who worked on the multiplayer versions of Splinter Cell – Pandora Tomorrow and Chaos Theory ontrolled this dimension of the game system very well. Each piece of equipment the players have at their disposal is characterized by the possibilities it offers to its user, but also by the opportunities it offers to the opponents.
Here are a few examples: the defenders’ laser enables them to inevitably find the opponents by scanning the urroundings, but it also allows attackers to spot the defender from a distance and to see what he is looking at. The attackers’ camouflage clothing enables them to greatly reduce the risk of being spotted by the opponents, but it also restricts speed. The laser mine is discreet, but the attacker can easily spot its ray by activating electronic vision.
This approach limits the risks of having any specific piece of equipment become too powerful.
Playtests, The Gameplay Quality Assurance
Regardless of the time you spend “planning” your game or level design in order to identify potential weaknesses, there is nothing like putting the game to the test in the hands of experienced gamers to see how badly they break it and take a malicious pleasure in exploiting its faults.
Generally, playtests are particularly useful during the development phase of a game. They have become essential for a multiplayer game. In fact, gamers – most often hardcore gamers – will spend hundreds of hours exploring every slight detail in the map, applying all the different tactics generally used in this type of game: testing all weapons and equipment, searching for any fault in the level design, and any bugs that will enable them to take advantage over
their opponents. Consequently, the weaknesses in the game or level design are quickly revealed and the game soon becomes less interesting. Properly conducted playtests allow the detection of faults in the level design, or poor settings of the game parameters such as the power of weapons, health levels, and so on.
In addition to my responsibilities as the lead level designer of the multiplayer versions of Splinter Cell – Pandora Tomorrow and Chaos Theory, I also implemented and supervised the playtest structure of the Ubisoft’s D’Annecy studio where these versions were being developed. The managers of the studio were so aware of the importance of playtesting that they wanted the testing to be done in the same building, so that the development team could be directly connected to the playtest team.How did we use the playtests?
In Splinter Cell – Pandora Tomorrow, the setting of smoke grenades gave rise to lots of playtesting.
We undertook systematic research of winning tactics – strategies that enable a player to win systematically and therefore maintain a steady interest for a game or a map. Among the most frequently encountered martingales are the “camp” points, which enable a player to cover one or more mission objectives with minimum exposure.
We put a lot of work into the game settings. Experience showed me that the intense use of certain features of a game (weapons, equipment, actions etc.) varies significantly according to a players’ profile, the time spent to get familiar with the game and, of course, the settings. Only long-term playtests that are conducted with a selected sample of gamers help ensure that the game settings remain correct after long hours of play. In Splinter Cell – Pandora Tomorrow, the setting of smoke grenades gave rise to lots of playtesting. In fact, this smoke not only blurs the view of the players, but also sphyxiates defenders if they remain inside it for too long. The size of the effect area and the duration of the asphyxiating effect are parameters which could have had an important impact if they had been set incorrectly. If the grenade had been too effective, it would have become a disproportionately powerful weapon, as it would have been enough for attackers to launch one into a passage to make it impassable for the defenders. Conversely, if the grenade had been too
ineffective, it would have become tactically uninteresting and players would not have used it. Remember the point egarding the player always looking to win at any cost in my previous article. To win, players quickly stop using useless equipment, but the development resources and the memory space of the special effects associated with this equipment are lost.
Finally, we tested the accessibility of the maps and the ease of gaining control of the game.
Conducting a playtest campaign is a particularly rewarding experience for a development team. To see how real gamers use the game and how they change the use an item from its original function (as I saw in the case of proximity mines that were often used as presence detectors by the defenders) to understand why they don’t use certain equipment that seemed so cool at the design meetings. Playtests are the tool that separate what looked great on paper in a design meeting from what is more important: what the gamers will actually use.
Design Solutions to Respond to Technical Constraints
In the first part of my series, which tackled the issue of level design for multiplayer games, I introduced three technical constraints that have a particularly significant impact on the design:
The bandwidth bottleneck
The need for event synchronization
The lack of control over the players’ actions
Let’s look at a few possible solutions to these constraints.
The Bandwidth Bottleneck
Previously, we saw that developers must maintain a balance between the number of players that can be supported during a session and the complexity of actions (animations, map events, special effects etc.) that can occur. Today, the general trend is to favor the number of players rather than the wealth of interactions in the map. I am convinced that this choice will evolve, because gamers want to have the same experience in multiplayer modes that they experienced in single player, such as map animations, destructible backgrounds, and physics management. Consequently, here are a few solutions for handling the bandwidth problem.
It is possible to hide a very complex animation by masking the animation behind a flash or a cloud of smoke, therefore avoiding overloading the bandwidth. We used this technique to its extreme in the Factory map that we developed for Splinter Cell – Chaos Theory, where a whole room can be destroyed following an explosion triggered by one of the defenders. The room is full of explosive barrels, which can go off if one of the defenders hits them with a bullet or
launches a grenade towards them. It is obviously not in his interest to do that, because the room’s layout would then be completely changed and the defenders’ movement would be severely limited. Such a map event would have been impossible to carry out without sacrificing bandwidth. The level designer in charge of the map succeeded in handling this event as follows: when the room blows up, all those inside it are instantly killed. Consequently, they cannot see the explosion and if some sly gamer has the idea to fire from outside the room, the smoke prevents him from seing the result of his action (see the screenshots below).
In this room of the Factory map (Splinter Cell – Chaos Theory), the defenders’ movement is easy: there are few ground obstacles and the footbridge goes around the room on a higher level…
…but if one of the defenders triggers the explosion of the explosive barrels, the room changes completely. Movement on the ground is slowed down because of collapsed wall sections and the footbridge is a pile of scrap metal. Defending the room then becomes much more complicated.
A second solution consists in scattering bandwidth consuming elements around the map. In this way, no two complex elements will ever occur simultaneously. It is essential to ensure that they will never interact with each other.
Another option is to try to mask the movement of certain mobile objects such as elevators, whose movement may be obscured by opaque walls. Finally, remember to include the possibility for a player to throw a grenade in an elevator box while the latter gets ready for movement. The explosion should not interfere with the movement.
Finally, one last solution is to work on compressing the data exchanged between the game machines.
The Need for Event Synchronization
Synchronization problems account for most of the dissatisfaction among gamers. When a good player places the cursor on a moving target and pushes the trigger, he expects the bullet to reach the target immediately and exactly where he aimed at. If you are working on an FPS, this problem should be at the core of the development process. I see two possible solutions to this problem:
To develop a multiple server architecture. Traditionally, in a multiplayer session, one of the game machines acts as a server and synchronizes all the interactions resulting from the actions of the client machines. This architecture guarantees the synchronization among all machines, but slows down the data transfer, because the information related to an interaction between clients A and B must pass through the server first. With multiple server architecture,
each machine acts as a server and a client at once. In this way if player A interacts with player B and the other players are not involved, data is exchanged directly between A and B. This solution was probably used in the Xbox version of Soldier of Fortune, a game appreciated by FPS “pros” for its precision. The multiple server architecture also offers another advantage compared with classical architecture, where a loss of connection with the server puts an end
to the entire session. In case of multiple server architecture, players may start and end a session as desired.
A less elegant solution from a technical standpoint consists in using only weapons with an area effect, such as a shotgun, a rocket-launcher, or a grenade- launcher.
The Lack of Control over Players’ Actions
The objective is to avoid that too many players find themselves in the same spot, so as to limit the number of interactions among them. Once again, the solutions are related both to the game and to the level design.
Increase the number of mission objectives and scatter them throughout the map. These two mechanisms were successfully implemented in Splinter Cell and Battlefield series of games. In the latter, players who select an engineer profile have access to many secondary objectives, such as the destruction of radar stations.
Another method to encourage the players to spread apart is to give them access to weapons that require them to preserve a certain distance from their foes. Battlefield also uses this mechanism by allowing the players to pilot a plane or control a turret.
Finally, my last recommendation is to avoid using small maps. However, the balancing between the size of the map and the number of players it can support is a delicate decision to make, because if the map is too large compared with the number of players, the player will soon get bored.
These “second best” solutions are far from being able to provide a long-lasting response to the multiplayer-specific technical problems. Other solutions exist. Essentially, my objective is to draw the attention to these problems so that they be taken into account very early in the development cycle of a game. I encourage my readers who have a solid technical experience to open a discussion thread and come up with additional solutions in the forum.
Getting Casual Gamers to Play
In my previous papers, I presented my suggestions to very specific challenges of multiplayer level design. I will end this series with what probably represents the main challenge: to make multiplayer games more accessible.
The very essence of a multiplayer game is to enable players of all levels to gather and play against each other. This is where the interest for this type of game lies, but this is also what makes it so difficult for the beginners. Playing against real human beings is intimidating, even if you are hiding behind a GamerTag. Yet, what happens when a casual gamer ventures into a multiplayer session is quite typical. Confronted with gamers who have mastered the game more
than him, he repeatedly suffers humiliating defeat. It’s therefore not surprising that multiplayer games are reserved for hardcore gamers. Nobody likes suffering defeat after defeat. If we want to make the multiplayer games accessible to the mass market, we have to handle this problem. The solutions lie both in the game and in the level design.
In my opinion, there are two solutions to this problem:
Add beginner-friendly features
Develop a game designed for casual gamers, while bringing enough depth to the game to satisfy experienced gamers as well
Features for Beginners
Let’s begin by reviewing features that may be added to a traditional multiplayer game to make it more accessible. This is something that we tried to do with the multiplayer mode of Splinter Cell – Chaos Theory.
The first solution is simple and particularly effective. It simply consists in adding cooperative modes. Gamers will not play against other gamers in flesh and bones, but against opponents, bots controlled by the game AI. This solution allows gamers of all levels to play together without being humiliated by other gamers, as bots are rarely as unpredictable and dangerous as their human counterparts. It allows experienced gamers to show themselves to best advantage by sharing their experience with the beginners. Finally, the cooperative game may be an extraordinary source of joy, since working together to reach a common goal is one of the driving forces of the human adventure. A “coop” multiplayer mode was developed for Splinter Cell – Chaos Theory by the Canadian studio Ubisoft. This mode was a huge success.
The second solution is just as traditional. It consists in developing a mechanism for classifying the players according to their victories and giving them the freedom to choose to play only with other players of the same level. This mechanism is present in many multiplayer games, but its efficiency often leaves much to be desired. It is therefore not unusual to find yourself playing against much more experienced players, even of the same “level”. In fact, playing on an unknown map is all it takes to ensure your defeat. To develop a classification system that is accurate enough to correctly evaluate a player’s level is much more difficult than it seems. Aware of the problem, Microsoft has propose ‘TrueRanking,’ an innovative classification mechanism that takes into account a very large number of parameters to make a player’s rank.
The third solution is to make the gamer learn the game by means of tutorials. Various types of tutorials may be created, outside the game and integrated in it. In the “versus” mode of Chaos Theory, we went deep into this matter, as we knew the game was hard to learn. Thus, the game includes a classic tutorial, made up of mini-sessions where the gamer learns how to handle his character. We added a mode that enabled the gamer to visit the game maps and discover the main features, in which all he had to do was follow a path marked by a light path and explanations (see the screenshot below). We added explanations to each element of equipment the gamers had at their disposal. We even made the player pass an examination map to make sure he understood the basics of the gameplay before giving him access to the multiplayer sessions.
The tutorial for map exploration in the multiplayer version of Splinter Cell – Chaos Theory. The path to follow is indicated by a light path and explanations are displayed at regular intervals.
What were the results of this abundance of help topics? The tutorials proved beneficial to get the new gamers started and prevent them from feeling completely lost in the map and in the game in general, but they were inadequate to give them a chance against the experienced gamers. After all, you cannot learn to drive just by reading a car’s manual. A better solution can be seen in Battlefield 2, where certain help topics are contextual. Thus, when the layer jumps off (or falls off?) a building or ejects himself from a plane, he can avoid a fatal fall by opening his parachute. But if the player fails to
open it and dies, a message reminds him of the existence of the parachute and how to control it when the player resumes the game. This approach offers significant potential as far as tutorials are concerned.
A fourth solution may be to integrate a positive or negative handicap system. Thus, according to the gamer’s classification, he can benefit from additional health points or from less ammunition. A mechanism such as this would allow a partial balance of the game among players of different levels. However, in order to be accepted by experienced gamers, the game would have to compensate them with new animations or new equipments. An intelligent system using this method is currently being designed for the multiplayer version of Crysis.
Finally, the last solution I propose is to provide a variable geometry controlled interface. Certain games, such as those of the Splinter Cell series, require the player to master a particularly complex interface. For such games one solution would be to offer two versions of the interface, a simple one for beginners and a full version for more experienced players.
This idea cannot be applied to all games, but it may be worth trying.
Games Designed to Be Accessible to All
Adding features that are meant to help the beginner face hardcore gamers may be useful to a certain extent, but I think that if we want to make the multiplayer game accessible for the majority of gamers, we must develop it in this direction from the design stage. Here are the three issues the new gamer is confronted with when he enters a multiplayer game:
The knowledge of the maps
The understanding and implementation of winning tactics
Let’s see how we can address these three problems.
Let’s begin with the interface. It should be designed around easy to access principles. We are all acquainted to controlling a character by means of the two analogue sticks on a pad, but is this mechanism easy to control by a beginner? Experimental playtests would probably provide a lot information on how the beginners comprehend and learn to use a game interface. One solution that should be tested is to develop an adaptive interface that would enable the beginners to carry out basic actions and which would provide them with new features as their level improves. The use of voice commands or of a controller such as the Wii-mote could revolutionize the way we interact with our games. And if these solutions seem too utopian, it is always possible to simplify the interface. The interface of Halo 2 is a great example of an intuitive one, because it is not overburdened with controls.
Let’s go on to the maps. In a previous paper dedicated to level design, I described various solutions to facilitate the understanding of a map. let me repeat some of them: favor the large maps rather than the complex layouts, use easy to identify mission objectives, create a strong link between the mission objectives and the layout in such a way that by simply understanding the structure, players can locate their objectives, develop an easy to identify navigation network, enable the players to have a global view of the map or a part of it, or favor asymmetrical maps. Note that the games of the Battlefield series offer very large maps, but simple navigation and understanding of the objectives. The map size is not the enemy!
Long Run, a complex yet easily navigable map thanks to its asymmetrical design.
Finally, there are the tactics. It’s the game dimension that is the most difficult to control. In a game such as Splinter Cell, it really is the one that makes the difference among gamers.
In my view, there are two possible ways to approach this problem.
The first is of technical order. It lies in developing an intelligent agent who analyzes the player’s game and makes recommendations accordingly. For instance, if a FPS gamer remains static for too long, the intelligent agent would remind him that he is too vulnerable to a sniper attack. The agent could also help the player discover new paths if it realizes that the player keeps using the same ones. Attractive as it may seem on paper, this approach would probably be complex to develop. However, the idea to provide the gamer with contextual information works, as we could see in Battlefield 2.
The second approach is conceptual. There are already multiplayer games that are relatively easy to pick up for casual gamers, such as Counter Strike and the games of the Battlefield series. This simplicity lies in several design choices: a game style that is known to almost all PC gamers, the FPS, easy to understand mission objectives, a layout that makes the map navigation easy (at least for Battlefield), large maps and sessions that are able to support many players.
I find the latter two factors particularly interesting from the perspective of making a multiplayer game accessible to everybody. The large map size provides the gamers with more opportunities to easily notice and avoid the remote attacks of the opponents. This can be seen in Battlefield, where gamers often lose their lives progressively, due to the lack of precision of the enemy fire. The second factor, the large number of players in a session, also seems favorable
to integrate the casual gamers. Actually, when a gamer is part of a large group, he can join the team and just follow a team member who knows the map and the map’s tactics.
I wanted this series of articles to be practical in showing that the design of multiplayer maps must follow its own specific structure, different to that of single player maps. The success of a map lies in the successful control of many parameters each equally important. Designers must be aware that their maps will be played hundreds of thousands of times (possibly by the same player), so the faults present will come out.
In closing I would like to remind you that there is no such thing as a perfect map, only those which follow certain points described here to their limits.
篇目2，Action Adventure Level Design, Part 1
by Toby gard
Intro – Delegation
Different people have different approaches to delegating design responsibilities.
I have seen creative directors who seem to have no vision of their own but merely act as filters through which their team’s ideas are strained.
I have also seen creative directors who form a rough image of what they want in their heads and then delegate the design to their team after loosely describing it to them. Inevitably the team then repeatedly fail to deliver his expected “right” solution.
A better approach than searching for mind-reading designers, is for the creative leads to express clearly both what they want and where the flexibility is, so that their team can know how to take ownership without getting lost in the creative wilds.
I believe that balance is achieved when an unwavering core vision is delivered to the team (based on the whole team’s input and feedback) and then responsibilities are delegated with clearly defined parameters for success.
This first article describes stage 1 of a process that does just that, based on the methods that I have found the most successful.
The process attempts to balance to a healthy amount of creative freedom and ownership for a level team, while keeping a structured vision in place by defining what details are essential to work out first and communicate to the team and what parts are better to be delegated with success criteria.
The steps that the entire process describes can be just as useful for an individual designer regardless of the level of delegation expected to occur.
Since every project has its own needs and team structure, this process is unlikely to translate exactly for you. However, many of the concepts can be adapted for just about any story-centric game.
Stage 1 Level Flow Diagrams
The first step in the clear communication of vision for level design is delivering the Level Flow Diagram.
There are four sources from which the high level design plan should be drawn:
Motivation – What am I doing here?
Like any good scene or chapter from a book, the conflict and resolution of a level should be born from the main character’s motivations. This is why the character’s motivations should always be clear to the player or they will feel lost and directionless.
These motivations translate into game objectives such as “find the man who killed your lover” or more simply, “kill Boss 5 of 10″. The strongest objectives are ones where character and player motivations are in alignment.
It is not enough to simply state the objective or motivation of a character if you want to create alignment. You also need to make it matter to the player if you want them to become invested in it.
For instance, showing through cutscenes that the main character hates a boss enemy, while letting the player know they must kill that boss to progress, results in a much weaker alignment than giving the player reason to hate that boss enemy.
If that boss enemy betrays the player after the player has come to trust him or if he takes something from the player (for instance by killing an NPC that the player has come to care about) then the player and the character will both have a real reason to hate him.
The time it takes to setup player motivation is why it is so hard to align player motivation and character motivation in an opening cutscene.
Often you have no choice but to state the character motivations right at the beginning, in which case the player will only have an intellectual rather than emotional alignment with him or her.
To strengthen that alignment through the game, the motivation “I want to bring my girlfriend back to life” must be completely linked to the player objective “Kill the Colossus.”
If the objectives are not directly related to the motivation (for example, if you spend most of your time being waylaid by endless rat killing quests) then the player will lose sight of the meaning behind their experience and their alignment with the main character’s motivation will erode along with their interest in continuing to play.
Emotional / Experiential themes
It is during this first phase of the level design that you must choose which of the powerful and interesting set pieces and emotional events that came from the whole team during preproduction brainstorms will make it into the game.
These are the high points around which you will fill in the rest of the level design. They are the moments that will define your game in the player’s mind and it is crucial that they support or drive your story.
The set pieces are high-concept action-oriented ideas such as “escape the burning building” or “find and defuse the four bombs.” Set pieces are the basic building blocks for an action heavy game, just as they are for action movies. The challenge is in creating set pieces that haven’t been done a dozen times before.
The emotionally charged events are the heart of your game — i.e. looking for survivors of a deserted village, only to find a shocking and disturbing answer to their fates as you enter the town hall.
Emotional events have the potential to be more memorable than a set pieces if handled well, but they too require the building of player and character alignment, which makes them harder to pull off.
The game pillars define the basic things the player can do, so to integrate the cool set pieces and emotional scenes into the level, they must be compatible with the player abilities or they will feel anachronous.
The most flexibility will come if the game pillars aren’t considered final until all the Level Flow Diagrams have been completed. It is only during the process of picking the things that will actually happen to the player, that you will learn what the player abilities really ought to be and how flexibly you will need to implement them.
For instance, if the game is about a jet skiing hacker, then it would be inappropriate to build a set piece around horseback crocheting. Doing so would have to rely heavily either on cutscenes and (shudder) quicktime events or would require specific controls, interface elements and abilities.
Apart from being inefficient from a development standpoint to create new abilities for each set piece, they would be also be un-ramped for the player unless you included several such horse riding and crocheting sections, in which case those abilities should have been in the pillars in the first place.
Regardless what sort of game you are making there is a story that is almost as important to consider as the main character’s; that of the level itself. Whether the player is experiencing an alien invasion, or trying to solve a murder mystery, their level of immersion is almost entirely dependent on your commitment to preserving fiction.
The most common mistake made in level design is defining a set of challenges loosely based on a manufactured set of parameters and then trying to set dress them to look like something. This inevitably results in unconvincing, bland and forgettable levels.
Despite many protestations from designers who feel shackled by a fiction-heavy approach, the reality is that when you resolve to respect the fiction of a level you inevitably find yourself designing spaces and events that surprise not just the player, but often yourself as well.
I will go into this in detail in the second stage of level development called “Building Through Fiction” but for now, all we need is the commitment to ensure that our overall level flow is being defined in a context that can be made fictionally consistent.
So no windsurfing on the moon — however much fun that may sound.
Level Flow Elements
Some people make full flow charts of their levels, but I tend to think that’s excessively restrictive and not informative at all regarding basic spacial layout.
I prefer a level flow that resembles hybrid between a schematic diagram and a simple beat sheet.
The goal is not to be exhaustive, but to define the skeleton of the level; the core of it.
On average I find that at least half of the final level goals will actually be added by the team during the next stage, so it’s important to keep these simple because the level will at least double in complexity from here. If you can’t fit the flow on one page, then it is probably too long.
The types of elements that you would include will be different depending on the type of game you are making, but the goal is always the same; keep it simple.
In this example I used the following:
I use these to call out the player’s arrival at an area. They serve as the locations on my schematic but also the critical information pieces given to player, during scripted events etc.
The things the player does. These are generally objectives that have been clearly communicated to the player.
Locks are the “hard gates” that restrict forward progress in the level until a certain set of criteria are met. (I’m lumping “soft gates” into Player Response for the purposes of this.)
These are status changes either of the world or of the player character that will lead to opening a ‘lock’ somewhere.
Example – Halo: Combat Evolved
Campaign 2, Flawless Cowboy and Reunion Tour
This single page schematic actually describes two levels (one campaign) that takes about an hour to complete.
Along with this diagram you would include notes that describe the intention behind each element and directly references the four sources from which they were derived. (This is how you define the success criteria for the level team.)
Kill the Covenant. Seeing the human fleet and the Pillar of Autumn being shredded in Campaign 1 gives the player enough animosity to last for a game’s worth of Covenant killing.
This would include the focus on introducing the player their first experience with the three-man driving / gunning Warthog gameplay, and the cooperation with AI troops.
Referencing films and other games is a good way to quickly communicate theme. Starship Troopers might be a good example to evoke the feeling of soldiers being overwhelmed by an alien enemy on an alien world.
The level is teaming with touches that infer a great deal about both the larger story and the smaller scale individual stories of the ongoing war:
Destroyed escape pods and the bodies of those that did not survive the landing litter the landscape, while debris from the space battle overhead fall through the sky. Each of the pod crash sites suggests the short desperate survival stories of the soldiers Master Chief meets there.
Once a Level Flow Diagram is done, you are still a long way from moving onto the next stage, the handoff to the team.
To evaluate a Level Flow Diagram you need to have done the whole game’s worth. Only when they are all side by side can you can see how well they fit with each other and how the ebb and flow of gameplay will move from the start to the end of the game.
Put them all up on a wall, and you will see where the player is being sidetracked, where a different order of events would make for a better rhythm and where emotional events are happening too early in a game for player and character alignment to have occurred.
The secret to making a great story based game is to make the actions of the player be the engine that drives the story, not the other way around.
Ico and Shadow of the Colossus are among the most successful stories in video games, yet many say the story elements were minimal. That’s not true. The story was everywhere, because the player lives it.
Ico was about escape and protection. Every time you managed to coax Yorda closer to escaping from the castle, the story of your struggle for freedom progressed. In Shadow of the Colossus, throughout the game the hero slowly sacrifices not just his own life but the lives of each colossi, in his mad quest to resurrect his love.Protecting a girl and Killing Colossi. The player actions are shaping the story taking the burden off the cutscenes and making the story matter to the player.
Level Flow Diagrams are the first key communication of Level Design intent to the team.
Build Level Flow Diagrams from:
Emotional and experiential set pieces
Player actions as defined in the game pillars
The environment’s own fiction
Use minimal elements to draw the diagram, and represent only the main events.
Keep it to one page.
Ensure you are driving story through player action
Action Adventure Level Design: Pacing, Content, and Mood
by Toby gard
By the end of the process described in the last article — building through fiction — you will most likely have a mixture of paper maps, written stories, detailed flowcharts, concept art and possibly some 3D mockup spaces, depending on how each level team prefers (or has been instructed) to represent their plan.
Those levels will have taken shape in surprising and unexpected ways. Levels that we had assumed to be straightforward action levels may have revealed rich veins for puzzles, and many levels are likely to have prompted ideas that fall outside of the current game mechanics.
Evaluating the Big Picture
To structure their feedback, the creative leads need to validate all level plans in relation to each other. Because the levels are likely to be pretty complex, it is useful to create a simplified representation of the whole game so that you can assess the pacing and emotional consistency of the experience.
Extraction of Mechanics
The first step we need to take is to identify all of these special case interactions and ideas that the level teams have come up with while fleshing out the level plans. Inevitably they will be some of the coolest in the game:
Ken Kong falls down a 30 story lift shaft, doing frantic mid-air kung-fu until there is a pile of zombie bodies beneath him thick enough for him to survive the drop.
It sounds awesome, but the fight system simply cannot accommodate this “fall fighting” mechanic, so the level team has suggested it as a cutscene.
In a couple of other levels, Ken Kong has to destroy some walls and the level teams have proposed different McGuffins to allow him to do this, such as a convenient, precariously balanced heavy object that will break through the wall if triggered.
It is this list of ideas that can produce the neat and original game mechanics that will set your project apart from everyone else’s. By promoting ideas that have the flexibility to be expanded into the core mechanics and peppering them throughout the game, we can create a richer more coherent overall experience.
How could destroying walls become a reusable mechanic? Would it require a consumable, or is it a readily available ability? How rich of a vein is it to be tapped for more applications? Does it have synergy with other player abilities?
Let’s say that we can integrate destroying walls with a new survivor type, a demolitions expert, who carries around explosives that can be put to all sorts of uses, but who also explodes when attacked by a zombie — potentially taking out a large proportion of your crowd. This could make for an interesting risk/reward mechanic and with some standard “explodable” barriers and/or enemies could be used in several levels.
Perhaps the “fall fighting” could also be used on several levels, but this seems more like a mini-game than a new mechanic. While the idea is interesting, the question is, could you make the gameplay deep enough to justify three or four “fall fighting” sequences throughout the game? It potentially seems like a large investment for too small a gain, but if we could make it work, it would be really cool.
These mechanics are generally gold, because they were not forced into the game design from a desire to tick boxes based on competitive products, but were discovered organically through an exploration of its unique themes and the thoughtful exploration of its world.
Once we have integrated the new mechanics and rejected or noted all the new set pieces, we will have adapted the character to live in this more clearly defined world and gathered a major part of the information needed to give feedback to the level teams.
Most games have a basic mixture of elements. For instance, an FPS might have 70 percent shooting on foot and 30 percent vehicle combat.
If every level in the game had exactly that mixture of gameplay, it would get dull for the player pretty quickly. But if you have levels that are entirely on foot, interspersed with a few levels that are predominantly or entirely involving vehicles, then they will act as palate cleansers, changing up the experience enough to keep players interested.
By looking at the mix of gameplay types over the course of the game, you can isolate points where the experience might be too flat.
A great example of a game that keeps the player constantly interested is Half-Life 2. Almost every level has a new central theme, whether it’s a new weapon, a new vehicle or a new type of enemy, your experience changes dramatically every thirty minutes or so.
Let’s carry on with the imaginary game Kung Fu Zombie Killer, discussed in depth the last installment. The variety of gameplay in that design comes from the types of survivors that you rescue.
With doctors, you could have a level where your goal is to heal injured survivors.
With forklift truck drivers, you could have a level where heavy equipment has to be taken to a particular location in order to progress.
With engineers, you could have levels that included traditional puzzle elements.
With soldiers, you could have a level where your crowd actually does most of the fighting for you.
And so on.
Let’s assume these were the locations we settled on for the levels:
We know from the story that the game has to start in Ken’s Dojo and that it has to end with camera men filming Ken as he rescues jenna126xyz.
We have goal mix of 80 percent fighting, 20 percent puzzles for the whole game and we had ordered things like this:
But during the detailing phase two things happened. (More likely a massive number of things would have changed, but let’s keep it relatively simple.)
First, someone came up with a really cool teacher survivor who can put zombies to sleep by lecturing them, which changes the gameplay mix at the college to involve more puzzles.
Second, someone has proposed changing the cinema into a film studio, whereby the zombies and the survivors can be based on clichés like Wild West or Godzilla films. People are very excited about this idea and enough crazy mechanics have come from it to justify potentially splitting it into two levels.
Consequently things are now looking a little less balanced and we have one too many levels:
(For full chart, please click on image)
We have found enough new mechanics that we can nearly introduce a new mechanic every level. By cutting the supermarket and moving the power station a bit earlier we can adjust the level order to create a better gameplay rhythm:
(For full chart, please click on image)
This can still be improved; we can look to either find a new survivor type that can be added to the town hall level, or we can try to replace it with something else that gives us more opportunities to do so.
There are potentially a host of emotions you will want the player to experience over the course of the game. The main character may experience things like unrequited love, revenge, sadness, and anger. These sorts of emotional events are important to track but they are not as important as the overall emotional tone or mood that you want the player to experience.
By “mood”, I mean a basic emotional concept that can be passed to the audience. So panic, fear, trepidation, awe, and excitement would be considered moods, while higher order conceptual emotional themes such as revenge, jealousy, or nihilism would not be.
Generating the mood map has two purposes. It is used to assess that the level order and content will not interfere with the emotional journey of the player but more critically it is a fundamental tool for aligning the whole development team towards creating a holistic experience.
For instance, let’s say that the story of Ken Kong will go like this:
Ken fights his way across the city saving the loved ones of his crush, but it takes him so long that by the end when he reaches her, she has been bitten and become a zombie herself.
If I define the mood map like this:
Kick-arse awesomeness – farcical chaos – mounting triumph – dark comedy
Art will keep things bright and well lit.
Animation will tend towards outrageous over the top stylized action.
Music and sound effects will tend towards fast-paced and comical.
Designers will feel free to be more game-y in UI game design decisions.
By defining the moods specifically over time you will guide the whole team more precisely than you might imagine. For instance “mounting triumph” implies a growing crescendo. It is likely to encourage a ratcheting up of music intensity, increasingly outrageous level end victory animations, and a general tendency to try to up the pacing each level.
While you probably assumed that the tone of KFZK would be defined as something like “zany”, the act of stating it over time has a dramatic impact on the whole development.
For instance, if I instead define the mood map for the whole game like this:
Panic – horror – increasing trepidation – tragedy
Every aspect of the game will be completely changed by this mood map:
Art will create darker dirtier spaces; they will light the levels with flickering pools of light and dress it with increasingly disturbing stories.
Animation will tend towards realism and will avoid any movements at might be construed as funny.
Music and sound effects will be disturbing.
Designers will try to keep UI and other design elements realistic and invisible.
With exactly the same game design, these two mood maps would generate utterly different gaming experiences. When the whole team embraces the mood map and diligently tries to express it in all the assets and creative decisions they make, the mood will be successfully instilled into the player.
What normally happens, though, is that every team member has a slightly different idea of what mood or tone the game should be creating, and rarely any idea at all of what mood the player should be experiencing at any given point in the game. Is it any surprise that most games fail to move people, when the development team are all communicating slightly different messages?
The mood map can be as simple as the above four stage progressions, or it can be as detailed as putting several mood chunks into each level. It is worth bearing in mind that literally no story-based game has only one mood. Even horror games oscillate between building tension and outright terror.
Once you have the gameplay types laid out and the moods defined you can see how the current level plans fit together.
(For full chart, please click on image)
In our case we have puzzle levels late in the game that are clearly going to slow the pace where we want people to be experiencing “mounting triumph.” By reordering levels, or shifting ideas from one level to another, we can better support the emotional goals:
(For full chart, please click on image)
Luckily KFZK’s level order is very flexible, but most games are not. In most cases the answer is to give feedback to the individual level teams to try to reach the desired mood and gameplay mix.
While the above example is probably not the best order, or even the best mood map, the point of the exercise is to try to force yourself into examining the entirety of the plan so that feedback on each level is given relative to its place in the whole experience.
Block Mesh and Prototype
The next step is to start building the levels in 3D, and I argue that the best people to do that are artists, not designers, if you want believable and interesting spaces. Block mesh should validate whether the level as planned will fit into the technical and production limitations while demonstrating that they can be compelling enough spaces.
As these levels are prototyped, inevitably things will end up being slightly different than planned. Designers will adapt their plans based on the art, so throughout the block mesh and prototype phase, the leads have to continually update the game rhythm chart and validate the levels within the context of the mood map.
By continuing to extract new mechanics that arise from the block mesh phase and staying open to level re-ordering you can continue towards a balanced game plan without restricting the creative process of the level builders.
All the information gained by building the block mesh should have refined the game design significantly.
A final Mood Map has been created that will inform all asset creation.
New mechanics have been defined and inserted into all relevant levels.
Levels have been reordered and massaged to create the desired pace and mood.
Memory budgets have been validated.
Weak level plans have been cut.
Player abilities have all been prototyped and final metrics defined.
Once all the levels are prototyped and one level has been polished to act as a vertical slice, production can begin from a very solid basis
篇目3，Portal 2 Level Design: From Initial Idea to Finished Level
In a previous article I discussed what goes into making a strong level in Portal 2 and what you need to consider as a level designer. In this article I am going to take a more hands-on approach to help you understand those concepts by building a level, to show you the process I go through and how to apply the ideas I discussed earlier.
Before We Begin
In the last article I spent a lot of time discussing the elements of a Portal Test Chamber. However, I know from personal experience working on Portal levels that creating a level can be much more challenging than just understanding the ideas and applying them. So in this article I’ll explain in more detail how to develop a level, with a concrete example you can follow from start to finish to help you understand what problems you are going to encounter and how to handle them.
You may remember from the previous article that I also showed some concept art of the level idea I was working on for this article. It looked like this:
I’ve been working on this concept more since the last article was posted and, although it has potential, I found the idea to be much more complex than I originally envisioned. With that in mind I thought it was best to focus on a simpler idea in this article .
My goal here is to give clear examples of what I’ve already discussed in the previous article, and; although there are good examples in the level above, it would be beyond the scope of this article to go through every problem I would face while developing it and you would end up losing out on the chance to see the whole development process.
Developing an Idea and Concept
I’ve decided to go with a level where the player has to get a cube and bring it to the end of the puzzle so they can open the exit door. I also decided that I was going to work with tractor beams
because they are one of my favorite puzzle mechanics. From this starting point, I began considering what sort of puzzle I could make with these constraints.
A tractor beam in Portal 2.With tractor beams the player needs to be in a situation where they are trying to get an item which is out of reach, or trying to go somewhere they cannot go with portals alone. I decided I wanted the player to use the tractor beam to move around the level and to use it as a means to attain the cube. This information helped me decide to put the tractor beam on the ground since the player needs to get into it, and to put a lot of water within the level to make walking around difficult for the player.
From here I decided I had enough to start coming up with simple concepts. I threw around a couple different ideas but the one I went with was fairly simple: the room is divided into four sections by two lines of water which cross in the middle of the room, like so:
The player enters the room in section A and leaves in section D.
To leave the room the player needs to use a button, which is next to the exit, and to use that button they will have to use a box which starts on platform B.
There will be a wall which prevents them from getting from B to D and forces them to go from B to A to C to D. To get between sections the player will use a tractor beam.
At this point I needed to determine where the tractor beam would go. I knew the Tractor beam would probably be at either A or B and decided it should be at B because I wanted the player to use the Tractor beam to get the cube.
If I put the tractor beam at A then I would need to make it face B since I want the player to look at B before C, and having the tractor beam facing B means that its possible for the player to accidentally get to the cube if they step into the beam before processing what is going on. I didn’t like this option because it meant they could complete the first step accidentally, so I put the tractor beam at B.
Since the tractor beam is located at B there also needs to be portalable walls around A that allow the player to use the Tractor beam to go from A to B and B to C.
There also need to be portalable walls at C which allow the player to use the tractor beam to move from C to D.
While looking over my puzzle I realized that it was possible for the player to go past the C platform without stopping and just continue using the tractor beam to go across to D if they placed the portals correctly. To prevent this I decided there should be a fizzler on the empty edge of D and put the button which disables the fizzler on C. This forces the player to get out of the tractor
beam, and determine how to turn the fizzler off before proceeding from C to D.
I chose to use a button that has to have something on it to keep the fizzler disabled. This means that the player has to put the cube through the Tractor beam while they keep the fizzler off so
that the cube doesn’t get destroyed by the fizzler. Then, once the cube is on the other side the player can go to D with the tractor beam, pick up the cube, and open the door.
At this point I knew that even though my puzzle wasn’t particularly challenging it was complete enough that I could take it into the editor and test it, so that’s what I did.
Analyzing Your First Draft
Here is an image of what the map looked like in the editor:
This video shows me playing through the puzzle, and narrating a few of my thoughts on it:
In case you can’t view the video, it shouldn’t surprise you that I found the level to be incredibly simple. The problem is that there is no real challenge to completing this level since every step is obvious and requires little forethought on the part of the player.
This is not an uncommon problem to encounter early in the level design process for a Portal map. To solve it I like to list the actions the player has to take to complete my puzzle and then find places I can make things more difficult for them.
These are the current steps the player must take to complete the puzzle:
1.Use portals with tractor beam to go from A to B.
2.Pick up cube
3.Take cube from B to A with tractor beam.
4.Use tractor beam or portals to go from A to C.
5.Turn off fizzler by standing on Button at C.
6.Set up tractor beam so it goes from C to D.
7.Put cube in tractor beam while fizzler is off to move it from C to D without destroying it.
8.Once cube is past fizzler, step off Button and into tractor beam to move yourself from C to D.
9.Once on D, use cube to open exit door.
The problem I noticed after listing the actions the player takes was how easy it is to get the cube, and then how easy it is to get the cube from A to C. Those two actions are very important to solving the puzzle and yet they can both be boiled down to a single statement action. Contrast this with how the player gets from C to D with the cube, which is half the listed actions alone, and you can see why this is such a simple puzzle. Clearly, this is where the puzzle needs to be more complex.
Getting the cube should be the first challenge for the player. To effectively make this part of the puzzle more complex, I needed to find a way for the player to use the tractor beam to get the cube. This would introduce the tractor beam as a complex puzzle element earlier, and make the act of getting the cube more interesting.
The easiest way I found to introduce the tractor beam at this stage of the puzzle was to move the cube dispenser into the middle of the map. Doing this made it so that the cube will continue to spawn and fall into the water until the player does something to prevent it. This forces the player to catch and move the cube with the tractor beam before they can pick the cube up, and effectively makes the task of getting the cube involve active participation on the part of the player.
(From this point on, I start implementing ideas directly in the editor without sketching them out first. I try to start on paper or in Photoshop so that I can think through the major aspects of the puzzle such as the player’s goals and a general idea of how they may accomplish them. However, once I move into the editor, the iterative process is so fast that it’s not worth going back and forth unless I’m making a huge change like adding a new room or re-designing a large section.)
After moving the dispenser I also realized that to catch the cube the Player will need a few more portalable walls so I added them in these locations.
This video shows me solving the puzzle after the newest changes:
Now, what I’ve just done has made the test slightly more difficult since the player has to determine how to retrieve the cube and it did add more steps to the puzzle as a whole, but it hasn’t had
a huge impact on the overall difficulty since a larger portion of the puzzle – getting the cube from A to C – is still very simple.
At this point I need to find a way to add an element to the puzzle which the player will truly have to ponder before they can take action. Generally when I get to a point like this, where I have
very few ideas about how to complicate my puzzle but don’t want to add any major new elements, I find a good method is to make the puzzle impossible and then find an interesting way for the player to solve the puzzle.
What I mean is, I am going to add an element to the puzzle which in its current state will make it impossible to complete and I’m then going to find a way to modify that element’s impact on the puzzle which introduces a new challenge to the player and makes the puzzle possible to complete once again. In this scenario I am going to add a fizzler as shown in the image below so that it is
impossible for the player to actually move the box from A to C without destroying it.
As you can see my puzzle is now impossible — primarily because the fizzler is also preventing the player from getting the cube in the first place.
To change this I am going to put a pillar in the corner of the C platform which will end the area the fizzler affects and give player access to the white wall they use to catch the cube again.
As you can see I also made the pillar two spaces long rather than just one. I did this because after testing my map I found that it’s possible for the player to go to the edge of the B section that faces the D section and put a portal into the C section if they are fast enough. Making the pillar two squares wide prevents this workaround.
To find a new solution for the puzzle I spent some time in the editor and in the level trying to figure out what I might be inclined to do as the player. I determined that if I added white portalable walls to B it would allow the player to place a portal at B from C when you are standing on the edge of C that faces D. This would effectively create a way for the player to get around
the fizzler and get their cube back so they could complete the puzzle.
I implemented this idea and then went back into the level to try and use the solution:
I actually really like this solution as it is simple but not overly so, and because it subverts the players expectations by relying less on the tractor beam than previous parts of the puzzle.
After some testing I also found that many of my friends did find this final step sufficiently challenging. If I were building a larger-scale puzzle I would probably continue developing and find another use for the tractor beam, or a place to integrate a new puzzle element, but since this is supposed to be a relatively quick puzzle I think this is a good solution to continue with.
Finishing the Puzzle and Finding Exploits
While the puzzle looks like it’s complete, it’s actually not. At this point we still need to do some testing and see where the puzzle can be exploited. To find the exploits, you should play your level as much as you can in as many ways as you can and get lots of others to play it too. In my testing, and in having my friends test the level, I found two solutions that I didn’t like and one
area I wanted to consider changing.
This is a video demonstration of how the player could exploit the level in its current state and the two solutions my friends came up with that I felt went against the intended solution too much:
The first exploit was that they could place the tractor beam in the column of white walls directly next to the open edge of platform C and then simply jump from the tractor beam onto platform C.
This avoided my intended solution for the puzzle and required timing and accuracy to accomplish, not thought or understanding of the environment. I eliminated this solution by making that column of white spaces on the wall black so that the player could not portal there:
The second solution was that a player portaled to the top corner of the white area between C and D and then jumped down on to C and again avoided the solution I had intended in a very similar way.
I accounted this by stretching the level, pushing everything from the white wall onwards one space farther from the C platform. This makes the gap too far to jump and eliminates the exploit.
If I continued testing with more people I would probably find some other solutions I didn’t like, but you have to be careful during this step that you are only eliminating solutions which go against the intent of the puzzle and are not eliminating every solution that isn’t yours. Remember, you want the player to have the restrictions to find the solution you intended, but the freedom to do it in their own way.
The other thing I found was that if the player got to D without the box, they would be unable to return to C because of the positioning of the fizzler on the edge of D. To adjust for this I added an extra row of standing area in front of the fizzler on D so the player would be able to make their way back to the important areas of the puzzle and wouldn’t get stuck.
I also had to make sure at this point that the white walls on the CD side which allow the player to get back to the other areas of the level were not going to allow the player to drop the cube on the D platform without using the tractor beam, but found nothing except that they could accidentally destroy the cube. I thought this would be okay to leave because it would lead the player in the direction I wanted.
I did some more testing and couldn’t find any other major issues so at this point I decided to consider the puzzle finished. Like I said, I am sure if I wanted to I could do more testing and explore the puzzle even more deeply, but you have to know when to stop and at least take some time away from the puzzle. I may revisit it at a later date if I get feedback saying it can be improved, but for now I decided to move on.
Calling It a Day
I hope this article helped you understand the process of developing a level from start to finish. While some things you do will be meticulously planned and thought out, others come up without you realizing it while you were focused on something else. Really, you just need to go with the flow and consider how your actions and any new solutions will impact what the player can and cannot do.
It’s also important to know what you want the player to do so that every change can be considered in how it affects the player’s ability or inability to accomplish the goals you want.
Also, take a lesson from this article and how I tried starting with something much more complex than it needed to be. An idea doesn’t have to start huge and ambitious to become good, you just have to put in the time and energy to make all the elements work.
篇目4，Game Design Theory: Multiplayer Level Design
Game Design Theory
For budding game designers it often comes as a shock that there is more to designing games than coming up with a few ideas. The basic idea for a game is merely a seed that has to be developed to include detailed game mechanics and a complete schematic for how the game will actually work. You can learn a great deal about game design theory by playing the top games and considering the decisions the developers made about key aspects of how the game would play. There are plenty of books on the subject; there are even game design courses but the best way to learn about, and develop your game design knowledge, is to dive in and start making games.
This article will be the first in a series on game design theory and we’re going to start off with multiplayer map design for the first-person shooter genre. The FPS genre is extremely well supported by the modding community. And, it has a lively and demanding base of online players addicted to the kind of depth you can only enjoy by playing games with other real people. All of the top FPS series which support a large online community conform, to a large extent, to a particular set of rules about how to lay out FPS multiplayer maps.
In this article we’ll lay out and discuss some of those multiplayer map rules and provide a few examples to illustrate. There is an awful lot to game design theory and you’ll find many different opinions in the games development community. This article only scratches the surface and is intended as a general overview. Since so many modders start off by designing multiplayer maps for their favourite games this seems like an ideal beginning.
All multiplayer maps need spawn points but there are many different ways of dealing with player respawn. Early problems with multiplayer maps included frequent spawn kills where players learned spawn points and camped nearby to kill off opponents before they could get going. There are few things more off putting than being killed before you’ve moved from your starting spot.
For team based games like Counter Strike players are often spawned at opposing ends of a map in a kind of safe zone. This works perfectly for Counter Strike because you never respawn, once you’re dead you are out of the round. The Call of Duty series developed a respawn system so it would spawn you close to your team mates but away from enemies and this works better in most game modes.
The map designer has to specify the location of the potential spawn points and where possible these should be in areas where the player spawning in has some cover. They also need to allow the player to instantly reorient themselves to the map so they shouldn’t spawn in facing a wall for example.
While the Counter Strike system can be used for multiplayer games where the players respawn after death, if the map is big this can involve a long and frustrating journey for the player to get back into the action. The best system is for the designer to place multiple spawn points and then the game code needs to check for enemy players and only spawn when there are none covering the spawn point. In team based games you want to spawn the player as close as possible to his team mates without placing him directly in the line of fire.
All good multiplayer maps have a number of choke or collision points in them. These are bottleneck areas where encounters are likely to occur. In a team based game like Counter Strike it is vital that both teams are spawned an equal distance from objectives and choke points play a huge part in that particular title. Every game of Counter Strike I’ve ever played starts with both teams rushing to a choke point and throwing flash bangs before wading into a fire fight.
It is a good idea to provide multiple routes in FPS multiplayer maps and open areas, especially with a vertical aspect, are always fun, but choke points are essential to focus the gameplay and ensure plenty of dangerous encounters.
The simplest layout you can use for a fun multiplayer map is a figure of eight. This gives you two loops with a major choke point in the middle. Unreal Tournament 2003 actually had a map like this called Training Day. The result was a ridiculously fast paced and chaotic map. It suited the gameplay, but the lack of breathing space soon got tiresome.
Every multiplayer map should include alternate routes to create a bit of interest and encourage people to loop around. You don’t want the player getting too comfortable in any one place so multiple vantage spots onto each area are very effective. If the player can’t sit and cover all positions without constantly moving their view then you are actively discouraging camping (although there are other ways).
Long runs to dead ends are generally a bad idea and if you place something very valuable such as a map mechanism or pick up at the end: you’ll find gameplay focussed there very heavily. Map designers often create terrific areas in their maps, but because of the flow or the choke points the gameplay ends up being focussed in a corridor. If you want your impressive three storey room to be the focus, then think about making it the hub for routes in and out.
A multiplayer map does not have to make architectural sense and it does not have to be laid out like a real building, although conforming to some architectural rules will help players understand your map and navigate it intuitively. The trick is to make individual component parts in your map look like the real deal architecturally, but you can put them together in a way that would be highly unlikely in a real building. The gameplay is always more important than the sense of reality. For example if your chosen environment would have incredibly narrow corridors or low ceilings, that does not mean you should build it that way for multiplayer gamers.
One of the most important things to consider is helping the players not get lost. Landmarks are a fantastic way of doing this. A solitary statue which appears nowhere else in the map or a red house in a village of white ones can be enough to allow the player to figure out where they are quickly and easily. If you use a large landmark where it is visible to the player from multiple spots in the map, then they can always use it to navigate.
Although it may be attractive as an idea, symmetry in maps is usually horrible and can often lead to confusion amongst players. It can work well for Capture the Flag games and you can always colour code the two halves, but for the most part it is better to avoid making your map symmetrical.
This issue of identical areas in maps is a big problem for games set in real buildings because they tend to be several floors of rooms laid out in exactly the same pattern. This is something that Left 4 Dead 2 has handled nicely by blocking routes and adding in the odd landmark so you can quickly identify where you are and in which direction you should be going. Of course, adding a feature that allows you to see your team mates through walls makes this a non-issue, and the game is much more accessible as a result.
Any multiplayer game with an objective also has to make sure to highlight that objective clearly so players can see it. The most obvious way is to resort to using a mini-map on the HUD which can be used to highlight a location. However, it is also worth adding visual clues into the actual map. A tall flag pole, rising smoke, or a tall aerial mast are all visible from a distance, and all can be used to orient players.
It is good to provide more than one route to each location. Players should be able to see their objective and navigate there without having to think about it too much. This is another reason dead ends are bad: if the player goes towards a landmark which takes them in the right direction and the route turns out to be blocked they will become frustrated at having to double back. Players will always naturally take the route that looks the most direct. Once they become more comfortable with the map they might start to use the lesser travelled alternate routes which can be harder to find and less intuitive.
There is a reason that you see so many crates in first-person shooters. They are ideal as cover and are often used as makeshift staircases as well. You can make the cover in your map something more interesting than a crate, but if you don’t provide some hiding spots then the gameplay will be immediate, shoot on sight and probably not very satisfying. Cover prolongs fire fights and allows people vital time to perform actions such as reloading, switching weapons or boosting health.
In the old classic multiplayer deathmatch games pick ups were the key draw around the map and in some games they still are. Players would end up focussed on an antechamber, camped out waiting for the BFG to spawn in. I’m not a big fan of this but it is a very effective way of focussing gameplay in an area. Unfortunately it reinforces camping and it makes it easier for the more experienced players to gain even more advantage over newcomers.
There is another way to reward experienced players and to give your maps an extra replay draw and a surprise factor. Secret areas are great; players love to discover a hidden area. It doesn’t even have to have much in it because it is the sense of exploration and secret knowledge that makes secret areas in FPS maps so satisfying.
You can use secret areas as shortcut routes and even allow them as new vantage points on a familiar area of map. The simplest thing to do is to put a fairly low value pick up in there. This ensures the experienced players feel like they have an extra level of knowledge but doesn’t over reward them, unbalancing the game further.
That brings us not so neatly to the final issue which is balance. There are so many different types of multiplayer game that balance can be achieved in a myriad of different ways. It is, however, extremely tough to find a genuinely fair balance in any multiplayer FPS map. There are always advantageous starting spots, areas of the map which are easier to attack or defend, and areas or features in a map that just get ignored because they are not part of the winning strategy.
Experienced multiplayer gamers will figure out the winning strategy very quickly and everyone will copy it. Whether it involves using a specific weapon, using an exploit in the map, or being first to command an area of the map, you can be sure the winning strategy will be quickly disseminated and adopted. Since players spend hours and hours on multiplayer maps they will find all possible ways of achieving their goal and this will often include exploiting bugs or dodgy level design.
The only real way to balance a map is to play on it and make tweaks. You have to play test multiplayer maps for a long time before you can be certain they work and then you need a beta test with experienced gamers. Even after that when you release someone will inevitably find an exploit. Thanks to patching or automatic updates these maps can be fixed after release nowadays; in the past they would have been consigned to the scrap heap.
A great way of understanding what makes a great multiplayer map is quite simply to check out some of the most popular maps out there. Have a look at the most played Team Fortress 2 maps for example and you’ll see the use of landmarks, color coded areas, asymmetry, respawn safe rooms and architectural structure which looks believable but is stuck together quite unnaturally.
It is also worth remembering the basic rules don’t apply to every type of multiplayer game, maps have to be tailored for the specific game and they have be designed with a specific number of players in mind. If you have any questions or comments please post.