作者：Stephen Dewhurst

卡内基梅隆大学（CMU）的娱乐科技中心（ETU）启动了一个实验项目，研究如何才能把赛车、第一人称射击以及益智等游戏类型融为一体，并使其兼具社交性和竞争性。本文内容即是这个项目的研究结果。

如今的游戏不仅具备较强的社交性，而且更有大众基础。但是因为越来越多不同类型游戏的出现，导致不少社交群体（包括好友和亲人们）深受困扰，因为人们喜欢与他人分享游戏体验，所以常因想和好友一起玩游戏而放弃自己喜欢的游戏。

卡内基梅隆大学（CMU）将此次开展的这一实验项目名称为Asymmetrical Cooperative Gaming (ACG)，这项长达半年的研究项目旨在将赛车，益智和第一人称射击等游戏机制融合成一款社交竞技类游戏，使玩家既能与好友一起游戏，也能享受自己喜欢的游戏机制。

本文将重点讨论这项研究的可行性及局限性，以供那些有此想法的开发者参考和借鉴。

我们将以《Fusion》这款游戏为例，描述其设计原理，并以此引申出一些特殊的设计选择和结果，希望这种游戏设计既能够娱乐玩家，也不会为难我们的开发者。

ACG项目坚信几乎所有游戏类型都能够融合在一起，融合成一款能让玩家共享的游戏。本文将重点强调“模式”这个词，而在《Fusion》这款游戏中，“模式”是指玩家进入游戏并参与竞赛的方式。

从本质上来说，“模式”可以理解成一个较大的游戏集合中的一种风格。为了证实《Fusion》这类游戏并非虚有其表，我们列举了它能够取得成功的四大设计理念。

1.每一名玩家都可以独立选择游戏模式，而不受其它玩家的限制。为了使玩家能够自由选择喜欢的游戏类型，开发者最好能够平衡每一款游戏中的小组配置，即让玩家不会因为担心影响到小组成绩而不敢选择其他模式。

2.不同模式不局限于特定的游戏角色，即玩家在不同游戏中都能够担当攻击者，防卫者或维护者。因为不同模式的游戏会吸引不同类型的玩家，所以我们赞成让玩家在游戏小组中扮演任何一个角色，这样玩家就不会受到小组影响而不敢选择其它模式了。我们同样也在尝试转变《Fusion》这款单人游戏的一些策略，就像在游戏中的某些阶段玩家为了增强小组的实力并打败敌人而进行角色转换。

3.与传统风格类似的游戏模式。我们设计《Fusion》的目的并不是为了创造出一款新型游戏，而是为了把不同的游戏结合在一起为玩家创造不一样的游戏体验。把不同游戏模式整合在一起时，需要注意的一点就是不能摒弃这些游戏的本质属性。我们希望《Fusion》中不同模式玩家能够真正喜欢上这款“综合”游戏，并从中获得一些亲切感。

4.所有游戏模式都必须具有较强的交互性。任何模式的游戏玩家都应该与其他玩家进行交流，包括竞争或协助等。不论是否配置合理，任何一个小组都应该保持战略平衡，除此之外，每一个单独的玩家也必须能在游戏中与他人进行直接合作或对抗。

为了证明这四大设计理念的合理性，ACG选择了三种不同的游戏模式（游戏邦注：包括第一人称射击游戏，赛车游戏和益智游戏）进行了深入研究。我们之所以会选择这3种类型的游戏，是因为它们各不相同，彼此之间的交集也并不明显。而如果这三种完全不同的游戏模式能够集合在一起，那么其他游戏模式，例如即时战略游戏，塔防游戏，《料理妈妈》这类休闲游戏以及角色扮演游戏等也都能够结合在一起创造出一种新型游戏。

在《Fusion》这款游戏的三种角色中，战士（Soldiers）采用的是第一人称射击游戏机制，驾驶员（Pilots）则从属于赛车游戏，而黑客（Hackers）体验的则是益智游戏。因为时间的限制，我们仅借用了《宝石迷阵》中的游戏机制，而实际上黑客这一角色的设计适用于其它多种不同的益智游戏。

游戏等级设计：合并空间

如果开发者试图把不同的游戏结合成一款游戏，他们就必须给游戏玩家提供一个适当的游戏空间。不能只是将游戏作为一个反复传播信息和资源的工具，而应该让玩家切身感受到大家在一起玩游戏的共同体验。

但是如果每一款游戏都有属于自己的游戏空间，那就很可能出现两个问题。一个就是玩家很难在同一个时间点一起玩游戏。而如果为了创造这样的游戏体验，就必须让每一个玩家看到并理解同一个事件。

另外一个问题就是，不同区域的玩家虽然可能很容易获得彼此支持的感觉，但却很难产生相互对立之感。而黑客游戏模式所存在的一些弊端就可以说是个很典型的例子，因为黑客这个形象很难融入这个共享的游戏空间，而这个空间却要求必须做到角色共享，这一点我们将在后面的游戏反馈环节进一步讨论。

从《Fusion》这类游戏的设计来看，创造一个共享空间对开发者来说是一个很大的挑战。因为不同模式的游戏空间也不同。第一人称射击游戏的空间较为狭窄且相对紧凑，因为比起赛车游戏所侧重的“赛程”，这类游戏更强调打斗任务，所以不需要太过广阔的游戏空间。而赛车游戏则不然，它们需要铺设大量的赛车轨道，所以对游戏空间的要求更高。再者便是益智游戏，比起前两类游戏，这类游戏中很少出现3D游戏空间。所以针对不同的游戏，设定不同的游戏级别也是一件非常困难的任务，我们也还未找到有助于克服这些困难的捷径。

在《Fusion》中，针对第一人称射击游戏等级和赛车道的不同范围，我们使用了3种不同的解决方法。第一种是把原有的车道转变成一个八字形的跑道。这样做我们便能够在一个相对紧凑的游戏空间中安放更多的跑道。这种方法能够让玩家获得更有趣的游戏体验，就像《零式赛车》（游戏邦注：F-Zero，任天堂随GBA掌机同期首发的一款赛车竞速类游戏）所表现的那样。

我们使用的第二种方法是在游戏过程中使用跳垫和传送点等工具帮助玩家进行游戏，但是在使用这些工具前都必须做好适当的衡量，因为如果游戏中的战士与驾驶员的移动速度相当，那么游戏场面将很可能会失控。游戏级别必须符合各种游戏模式，但是也不能剥夺了任何一款游戏的本质属性和特点。我们通过在《Fusion》中安置跳垫这个工具，帮助玩家加速进入某个特定区域，并在游戏中设置了一些有趣的竞争关卡，使得第一人称射击游戏和赛车游戏玩家都会对之感兴趣。

第三种方法是把每一种游戏模式中的一些重要区域结合在一起，这么做能够推动玩家尽可能地在这些区域进行游戏。以《Fusion》为例，在这款游戏中，虽然有些跑道对于战士来说很难跨越，但是能够轻易进入这些跑道的驾驶员却并不能直接由此获得积分。所有模式规定必须在相同区域才能赢取积分，这些区域就会变成冲突之地，因为所有的模式只有在此地产生交集，玩家才有望共同获得成功。游戏目标和机制支持玩家进入一个共享空间，每个模式也都有仅支持特定玩家进入的区域。

游戏测试表明，这款游戏设计的很多机制都合乎情理。唯一的缺陷是游戏中的跑道对于战士却没有任何作用。虽然我们在游戏设置了大量的冲突点，但是战士却需要不时停下来观察驾驶员的所在位置，因为这两者在游戏中碰面的机会实在很少。如果我们能够重新设计游戏等级，我们将更好地使用跳垫，并且为战士在跑道周围设置更多的冲突点，使这两种模式能够共享更广阔的游戏空间。

益智玩家的定位则是合并游戏空间遇到的一个较为棘手的问题，因为益智游戏通常情况下并不采用3D空间。但为了真正融入游戏中，就不可忽视黑客这一角色的存在。因为对于战士来讲，他们在游戏世界中存在一个无法对其采取实际打击行动的敌人，也实在是一件很诡异的事情。

同时，由于益智玩家并不能驾驭3D空间，所以我们也不打算让这些益智玩家接触他们并不熟悉的游戏机制。我们的解决方法则是在游戏中设立黑客节点，即黑客可以不需要驾驭3D空间而可直接进入或退出的实际位置。

当黑客进入了一个新的节点时，他们可以选择在这个节点附近进行活动，而无需与周围的环境直接打交道，其他模式的玩家则可轻易发现黑客并对其发动袭击。虽然登陆或退出一个新的节点对于益智玩家来说是个全新的任务，但这种机制较为简单，也不需要耗费太多时间，有助于他们集中精力体验益智游戏。

关于《Fusion》的关卡设计的最后一个挑战便是游戏的对称性问题了。游戏关卡的对称性问题对于游戏中的团队合作来说很重要，但是不同类型的游戏的对称性问题也各有不同。赛车游戏并不需要担心对称性问题，因为其玩家都是在相同的跑道上进行比赛。

在《Fusion》中，每一个小组都有一个专属基地以及一条贯穿同一个游戏空间的跑道，如果驾驶员与其他模式玩家在同一个起跑线起航，他们将最先到达某个团队所属的领域。

游戏开发者将由此发现两种不同的选择。首先是移除玩家团队的基地或所属领域，使得原本对称的游戏世界或者不对称的跑道之间的互异性变得无关紧要，因为在游戏中每一个小组都会受到相同程度的影响。而另外一种选择则是，规定驾驶员的起航点必须设定在跑道的不同位置（因为驾驶员有速度优势）。虽然这样做能够平衡游戏级别，但是却会让玩家失去传统竞赛游戏的那种氛围。

我们选择第二种做法是因为它能够创造更多领域，让不同模式玩家更容易与其他玩家共享游戏目标。但是这种方法会使驾驶员会失去传统赛车游戏的那种竞赛感。这个解决方案还不尽完美，还有些问题需深入探讨。深入研究可以发现，如果每一个小组的驾驶员都在同一个起跑线起航，那么所有小组的都无法独享相对竞争优势。

玩家目的与技巧转换

在多人模式的社交游戏体验中，每一名玩家都必须清楚其他玩家的“两样东西”，即游戏目的和技巧。在游戏中，比起了解同盟以及敌人的武器装备和健康值等问题，玩家更需要知道他们正在做什么，以及他们擅长于做什么。

基于这一点，ACG的主要目标是在游戏中排除一些玩家个人兴趣因素的同时，保持他们的游戏目的与技巧，使每一个玩家都能向其他玩家够炫耀自己的天赋与战略，且不需要为了适应不同的游戏风格而隐藏这些技巧。

所以，掌握在不同模式间转换游戏目的和技巧，对制作一款《Fusion》风格的游戏来说十分重要。开发者必须确保他们的游戏框架支持玩家按照自己所处的模式环境，充分展现出自己的游戏目的和技巧，这样做还能使其他模式的玩家从中受益。

《Fusion》中黑客所表现出来的侵略性转变就是个很典型的例子。当第一人称射击游戏的玩家向其他玩家开火时，他们的目的就是在游戏中杀掉对手。而他们在游戏中表现出来的技巧就是能够快速杀掉对方以保住自己的性命。

一般来说这种机制也会涉及到玩家的健康值问题。在游戏中，玩家可以采取闪避等动作避开炮火。但是在益智游戏中却很少出现“健康”这一概念，所以如果在黑客角色的设计中引入这个概念将使黑客模式和益智风格极不搭调。

更重要的是，黑客知道自己什么时候被袭击，也因此会做出一定的反击。所以，如果黑客节点被炮击了，这个益智游戏就会变得更加困难。如果黑客因此而输掉了比赛，他也将被踢出游戏，这与其它模式中玩家被杀或被摧毁的情形类似。

但是尽管益智游戏变得更加困难，但是如果黑客能够成功完成游戏，便能有力地反击这些攻击，安全地逃出困境。如果战士对黑客发动袭击，黑客便按照他在益智游戏中的做法展开反击。而他们所具备的游戏技巧正是在如此反复的对抗中表现出来，也并不会因为他们不熟悉游戏机制而发生改变。

在游戏中，黑客不应该只是躲避袭击，同时也应该做出反击。对于战士和驾驶员来说，侵略常常是以武器炮轰的形式出现，或者对于驾驶员来说，道路上的障碍物也算得上是一种侵略行为。因为益智玩家并不擅长在3D游戏世界中的行动，所以他们常常很难直接回应其他玩家发动的袭击。但是却有一个办法能够帮助这些益智玩家把他们的益智型技巧转变成有效的反击，即他们能够使用自动炮塔对进攻者发起反击。

黑客擅长在自己所属节点中制造大量的炮塔，而这些炮塔能够帮助黑客自动反击节点附近的敌人。黑客隔多久能制造出炮塔完全取决于他们的团队基础，即如果黑客能够创造出很多炮塔，那就说明黑客之间拥有很和谐的团队合作，而对于黑客来说，这种团队力量比技巧更重要。

当黑客创造出炮塔时，他们可以运用一些游戏战略，选择将这些炮塔安置在最适合的节点。而且更重要的是，如果黑客能够应用益智游戏中的一些元素把炮塔设置在敌人猜不到的隐秘处，那么这些炮塔便能发挥出最大的功效，而黑客才算是真正完美地进行了游戏任务。

《Fusion》这款游戏设计的最独到之处在于，它能在不同游戏模式间穿插转换不同玩家的游戏目的和技巧，使玩家能够在游戏环境下更好地理解游戏。这种做法不仅有利于游戏平衡和凝聚力，也有助于不同模式的玩家尊重其他玩家的策略和技巧。

较为直观的共同目标

“胜利”的定义取决于我们对不同游戏模式的理解。虽然这一点并非必需品，而且游戏中已经设有一些特定的目标，但是我们仍建议游戏开发者能够在游戏中设置一些较为抽象的进程任务。像屠杀，解决问题或者完成赛车等游戏中的行动通常难以整合成一个共同的小组目标，如果每一名玩家都能知道对方模式的胜利目标，他们便能够相互帮助或者妨碍对方取得成功了。

如果玩家可能以一种传统方式在一个共享的系统中获得成功，那么每一名玩家便能够按照自己所熟悉的游戏机制而努力获得胜利，而其他玩家的胜利也会在相同的游戏系统中显现出来了。

在《Fusion》中，因为游戏范围的问题，我们所设置的系统较为抽象。我们在游戏中设置了一些较小的游戏目标，使任何模式的玩家都能够攻破这些目标而走向胜利。例如，在游戏中设置一扇封闭门，战士能够击毁它，驾驶员能够绕过它，而黑客能够打开它，并且完成这项任务后他们便能近一步接近敌人的巢穴了。

虽然因为范围的问题，我们摒弃了一些较为复杂的创意而采取较为简单的任务设计，但是我们仍然相信在更复杂的游戏级别中设置一些较小的共享目标，有助于增加《Fusion》这类游戏的多样性和互动元素。

游戏小组的平衡性

经常会有人质疑在《Fusion》这类游戏中，开发者如何在不考虑小组配置的情况下解决游戏平衡问题，把不同游戏模式结合在一起。不要说是让一个含有三名黑客的小组与其他模式的小组取得战略平衡，就算是让拥有三个模式的同个小组取得内部平衡就已是个不小的挑战。

保持游戏平衡对于任何一款游戏设计来说都是个大难题，对于《Fusion》这类型的游戏来说更是如此，但也绝非难以突破的障碍。一般来说，只要不同游戏中的行动都能适用于每一款游戏，那么开发者便能按照相同的方法测试并调整这些游戏的平衡问题。也就是时候，如果开发者能够在在每一款游戏模式中，都设置三种角色，包括袭击者，防御者和支持者，而只要每一种不同的模式都能够很好地处理这三种不同的游戏角色，那么把这三种角色混合在一个小组中将不再是个难题。

除了因为不同游戏的不同优势导致游戏难以取得平衡之外，我们还发现了两个制约因素。一个是游戏模式的交互性因素，另一个则是不同模式间不平衡的游戏机遇。

举个例子来说，如果驾驶员能够帮助战士到达一些通过步行不能到达的地方，那么黑客也应该与驾驶员一样做出相同的选择，即对战士伸出援助之手。而这种做法正符合我们游戏的最初设计原则，即在游戏中我们并不强迫任何一名玩家执行任何特定模式的操作。

因为我们如果在游戏中设置一个特定的小组配置，那么这些小组中的成员将会因此倍感压力，他们不得不选择这种配置，很可能将由此失去与他人的交流和互动的意愿。

这就是为什么我们在《Fusion》中并未设置任何特定模式的原因。当然了，《Fusion》这类游戏也可以不按照ACG的目标设置游戏，而选择突出游戏策略的复杂性。如果是在这种情况下，我们当然就可以选择针对特定小组配置的设计元素。

我们也同样限制了一些不但可增加游戏模式趣味性，同时也可能使其进一步升华的设计选项。例如，黑客能以更富策略性的控制能力安置特定的炮塔，而这种机制更像塔防游戏而非益智游戏，所以我们就没有添加这种元素。

阻碍游戏平衡的另一个关键因素便是来自于单一游戏模式中的交互性。我们所希望的是不同游戏模式间能够相互协助，但是因为在单一游戏模式下，战士与战士之间会相互帮助，导致他们比起自助玩游戏，更喜欢在同一个游戏模式下与其他玩家相互协作进行游戏。我们当然可以设计支持玩家在同一个模式中相互帮助，但却无法自助的游戏机制，但它的开发过程更棘手且费时费劲。

例如，在跑道上安装触动装置以为驾驶员开启一条更好的赛道，但是如果跑道上并未安装这种触动装置，驾驶员便无法自主使用这种设置。这种一开始就让玩家占据优势的机制其实隐藏不少让玩家困惑不已的问题。所以，在《Fusion》修订版本的玩家小组中，每组至少都含有2种不同的模式。

并不平等的游戏模式

我们最初的设计原则是让所有游戏角色同时擅长于袭击，防御和维护功能，但是因为各种设计问题，我们便不得不重新考虑这种设计是否合理。第一人称射击游戏中较为注重侵略性，但是如果把这种侵略性融入赛车游戏中却会异常困难，因为赛车玩家并不擅长袭击其他玩家。

在解决这个问题的同时，我们还必须考虑到不同玩家的心态问题。不仅因为赛车玩家不具备第一人称射击游戏玩家那种侵略性，而且他们在赛车游戏中所追求的目标也与后者截然不同。

所以我们正在修改《Fusion》的设计原则，使不同游戏模式都具备有袭击，防御和维护等角色，同时也兼顾了各个模式优劣势的平衡问题。

在《Fusion》中，驾驶员并不具备战士的侵略性，但是他们却有着战士不能比拟的速度，而且除非被袭击了，要不他们总能比战士获得更多积分。

以战士为主的小组比以驾驶员为主的团队更具有侵略性，而且为了反击驾驶员所具备的其它优势（速度优势），战士会利用这种侵略性对其发起进攻。

找到不同模式的劣势

推动一种模式的玩家帮助另一模式玩家，最有效的方法便是找到其中一者的劣势。如果在游戏中安置一些所有人都不欢迎的合作元素，那只能说明开发者在做无用功。游戏玩家必须思考他们所选择模式的劣势是什么，并让其他模式玩家帮助解决这个问题。

《Fusion》中的“战士—驾驶员”机制能够帮助那些希望更快前行的战士借助驾驶员的速度优势快速前行。同时，驾驶员也因为害怕受到攻击而希望借助战士的炮火作防御。但是这两种角色却很难与黑客建立合作关系（游戏邦注：因为《宝石迷阵》这种益智游戏中并不存在这种互助机制）。虽然我们在整个游戏中为黑客这个角色设立了很多劣势，但是这些劣势并非《宝石迷阵》这种游戏本身的缺点，所以黑客玩家并不需要因此感到忧虑。

《宝石迷阵》的玩家希望能够在游戏中摧毁更多宝石以快速晋级，所以为了帮助同一小组的黑客玩家获得更多的奖励，游戏中的其他模式玩家可以通过解琐更多的黑客节点，以为黑客们创造更多便利。

明确合作关系

《Fusion》中的每一种游戏模式中的最主要游戏机制便是“小组库存”。我们通过创造这种共享的库存使小组成员能够帮助其他玩家收集游戏道具，这种做法能够推动不同模式玩家之间的相互协助。虽然这种机制在某种程度上来说是有效的，但它无法让玩家清楚地感受到团队协作感，这种机制很容易被玩家所忽视。

虽然玩家能够得到自己需要的游戏道具，并因此感受到小组内部的互助感，但由于这种机制并非直接出现于游戏世界中，而且玩家常常会忽略一些关于“其他玩家正在使用什么道具”或者“获得了什么道具”等信息，所以这种机制并不能实现玩家之间真实且直接的交流。

与此相反，如果是驾驶员携带战士闯过难关，情况便不一样了，因为战士从驾驶员身上所获得的帮助十分明显，而且玩家也能清楚地看到是谁在帮助自己。虽然像“小组库存”这类游戏机制很有益处，而且也算是一种最简易的整合新模式的手段，但为了针对不同模式玩家创造一种真实的共享体验，开发者必须制定一些更有效的游戏机制，使玩家能够真切地感受到这些机制对团队协作的有利影响。

游戏类型选择的局限性

什么类型的游戏能够相互融合并创造出《Fusion》这种风格的游戏呢？我们在开发《Fusion》时所面临的唯一限制性便是游戏的实时性设置，把实时性游戏和非实时性游戏融合在一起确实是个巨大的挑战。虽然真正的合作类游戏常常会与回合制游戏和实时类游戏的本质相矛盾，但开发者却可以对其做出一定调整，以便玩家在实时与非实时环境中都可以相互支持。

共享游戏机制

为了使《Fusion》能够成为一款深受各类玩家喜爱的游戏，我们就必须使玩家能够完全理解其他模式玩家体验游戏的方式。因为我们之前就遇到过类似的问题，即一些玩家在游戏中因为不了解其他模式而不知如何挫败对方。

因为黑客玩家的游戏进程取决于等级系统，而其他模式却没有这种设置，所以只有阻止黑客在游戏中不断升级才能抑制其获得成功。但是由于战士和驾驶员都不具备与黑客对称的等级系统，所以他们很难对黑客的行为做出反击。我们不想剥夺黑客所拥有的这种系统功能，所以我们也为战士和驾驶员设置了与黑客相称的等级系统，但是战士和驾驶员必须分别通过“杀戮”和“赛车”方式才能赢得更多等级。

这三种模式如果能达到更高的等级便能获得更多积分，但如果他们在游戏中被摧毁了，也会因此而遭遇降级。比起特定的游戏模式机制，我们更青睐于设定普遍的游戏机制，并公开当前所有玩家的游戏级别，使其了解如何更好地使用游戏系统，同时也为高级别黑客减少一些不必要的麻烦。

游戏反馈系统

为玩家提供游戏反馈系统对于任何一款游戏来说都很重要，对《Fusion》这类游戏来说尤其如此。一种游戏模式下的玩家通常都不理解其他模式玩家的行动，但通过游戏反馈，他们便能知道小组其他玩家在做什么。很多时候玩家并不清楚自己的同盟是否需要帮助，他们的敌人是否变得更具威胁难以对付，所以明确的游戏反馈能够提醒玩家注意一些不利境况或重要状况，以便为他们释疑解惑。

文章前部分对不同模式下的玩家目的转化做了相关描述，虽然这种转化隐藏在幕后，但是有时候我们还是得明确其转化结果，并将其公之于众。在战士攻击黑客的例子中，因为黑客的“闪避”动作经常不是很明显，所以战士需要反馈系统向其通报自己对黑客节点到底有多大的杀伤力。

同时黑客由于只能专注于自己的游戏界面，所以他们也需要一些向其传达自己的炮塔何时对敌人进行了攻击等明确信息。所以，无论玩家在何时对其他模式产生了影响，开发者在设计游戏时都必须考虑到玩家能否清楚地看到其行为结果，并将这些结果具体呈现在他们面前。

融入整体游戏世界

在《Fusion》这款游戏中融入益智元素虽然在某些方面取得了较大的成效，但却无法使黑客真正感受到游戏中的一些共享体验。因为真正的益智游戏机制与这个综合了不同模式的游戏世界并不完全兼容。

虽然战士和驾驶员的潜在行动对于游戏共享空间或多或少都会产生影响，但真正的益智游戏机制却不具备这种功能。《Fusion》的设计虽然把益智游戏的成功因素融合到更大的一个游戏世界中，但益智游戏本身就是一种缺乏玩家相互联系的体验。虽然《Fusion》使不同模式的游戏产生了较大的联系，但因为益智玩家常常只关注于眼前任务，与不同模式的同盟在任务目标上存在差异，所以他们常常会在游戏过程中产生强烈的孤立感。

由此可以看出，《Fusion》这类游戏中任何模式的机制都必须与更大的游戏世界产生直接的联系才行。在理想状态下，益智游戏必须与黑客节点附近的领域产生直接的联系，而其他玩家经过此地时的行动也会对益智游戏产生影响。

按照当前的游戏设置来看，游戏世界的反馈信息对黑客的行动帮助极大，但由于黑客在完成任务的时间点上并无明显限制，所以人们常会忽略游戏反馈这一要素。

意料之外的收获

我们原本打算通过《Fusion》使每一名玩家都能体验自己所熟悉的游戏模式，而无需完全掌握其它的游戏类型的任务，我们显然在这方面已经取得了一定成效，同时还发现了之前并未预料到的一个有趣现象。

在绝大部分的游戏测试中，很多玩家通常会在进行了三合一游戏后对其中一种游戏产生了兴趣。虽然他们还是比较喜欢自己早前选择的游戏模式，但是经过这种特殊的体验，他们也能借此了解其它不同模式的游戏。

就这样，很多玩家会开始尝试一些之前并不感兴趣的游戏，有时候也会发现这些游戏比预期想象的更有趣。除了鼓励玩家一起体验游戏，我们还希望通过《Fusion》能够支持他们与他人进行交流并分享自己的游戏体验。

总结

ACG的研究目的是为了探索三合一游戏体验的困难和潜在优势。通过研究，我们不仅发现这种尝试困难重重，而且比其它游戏设计更具独特的挑战。但是这些问题并非不可突破的障碍，而且很值得我们尝试一番。相信只要有足够的开发时间，我们不仅能够创造出《Fusion》这类游戏，而且也能够使更多玩家喜欢上这种游戏。

整合不同模式的游戏机制其实并不困难。首先我们必须使用一个健全的游戏框架，充分体现不同模式玩家的游戏意图和技巧。这个游戏框架必须能够向任意一种模式小组成员展示一个明确的目标。只要投入开发阶段，在这个框架下的游戏融合与其它游戏的设计过程其实并没有任何差别，其特定的交互性和功能设计过程与其它设计也并无区别。

将不同类型的玩家捆绑在一块也同此理。我们在前文已经提到，不同类型的玩家一直都有共同体验游戏的想法，只是缺少一个有趣的平台让他们实现这个愿望罢了。而事实也正是如此，从游戏测试中可以看出，各种玩家都表示在《Fusion》中既能够感受到游戏的乐趣，也能够与其他玩家一起游戏，还能向其他玩家炫耀自己的游戏技巧，并因此赢得其他玩家的敬佩。这其中最主要的问题就是兼容不同的游戏玩法操作习惯。

不同玩家喜欢不同的冲突级别和策略，但是在《Fusion》这款游戏中，玩家完全可以按照自己的喜好进行游戏。我们也建议开发者为玩家提供不同的游戏皮肤选项，让他们按照自己的审美眼光设定游戏皮肤。如果玩家能够自行控制游戏中的音效，那么他们也能够进一步按照个人喜好设定自己的游戏体验。

我们的游戏设计，开发和测试的最终结果表明，这款三合一游戏有望得到广大玩家的欢迎。在整个研究过程中，我们也遇到了一些困难，如我们在游戏中融入其它模式时，不得不考虑如何保持不同游戏模式原有的属性。

针对这些问题我们对游戏做出了相应调整，以更好地贴近玩家的游戏体验，虽然整个研究过程的时间很短，但是我们却有足够的信心克服这些困难和障碍，而且我们也清楚，比起传统的单一风格游戏，这种三合一游戏在操作上的阻力更小。

以下是我所列出的这类游戏的总体设计原则：

1.明确体现玩家意图和技巧。在《Fusion》这类游戏中，玩家必须清楚不同模式玩家的游戏目的是什么，在游戏中的特长是什么。这一点也是这种三合一游戏获得成功的重要动力之一。

2.特定互动方式比一般交流机制更管用。像“积分”和“小组库存”这种抽象的系统是游戏不可或缺的一部分，但它们还不足以推动玩家的游戏共享体验。必须想法让各个模式的玩家进行具体的沟通，让每个参与者都感受到这种互动机制对自己的影响 。

3.为不同模式设置特定的主题。确定每个模式中可赢得最多奖励的技巧，并围绕这些技巧设计所有的交互体验和游戏挑战。假如整体游戏主题与某个模式的主题相悖，那就得让其中一者妥协并进行调整。

4.创造更多共享的游戏机制。玩家没有必要了解其他模式的细节内容，但必须知道其他模式对自己的利弊。如果玩家对其它模式足够了解，并能借此有效帮助或阻碍其他玩家的游戏进程，那么其他玩家也能够更清楚地了解该游戏机制是否适用于自己的模式。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

The Genre Blender: Experiments In Social Gameplay

by Stephen Dewhurst

[A team at Carnegie Mellon's Entertainment Technology Center launched a project to determine how to get multiple game genres -- racing, first person shooter, and puzzle -- to blend into one socially competitive experience, and here present the results of that experiment.]

As gaming becomes more social and more widely accepted, the division between game genres increasingly frustrates social groups such as friends and families. People want to share social gaming experiences, but their different tastes in games leads them to be forced to compromise in order to play together.

Asymmetrical Cooperative Gaming (ACG) is a semester-long project at Carnegie Mellon’s Entertainment Technology Center aimed at solving this problem by merging multiple game genres into a single game, allowing players to play together while still using mechanics that are appealing to them.

This article will discuss the successes and failures of the project in order to inform and encourage similar designs in the future.

We will first cover the guiding design philosophy behind our game, Fusion, and then move on to specific design choices and their results. Our hope is to show that this sort of design is both highly enjoyable to players and not overly difficult to develop.

ACG started from the belief that nearly any genre of game could be integrated into a shared gaming experience. Throughout this paper, we will refer extensively to “modes”, which in Fusion refer to the way in which a player enters the game for a match.

Essentially, a mode is Fusion’s representation of a genre inside the larger game. In order to prove that a Fusion-style game could work, we set down four specific design goals that we felt were integral to a successful proof of concept.

1.Each player can choose any mode, without any pressure from teammates. In order to give players the freedom to choose the game mode that most appeals to them, it was important to balance the game for any team configuration such that no one would ever be pressured to choose a particular mode to influence team balance.

2.Modes are not restricted to particular roles, such as attacker, defender, or support. While different genres of game appeal to different demographics, we felt it was important to allow a player of any game to assume any role within their team, so that the mode a player chooses would not define how they contribute to their team. We also attempted to have strategies shift during a single match of Fusion, such that at different points it might be to a team’s advantage to have players change their roles to respond to their opponents.

3.Modes resemble traditional genres. The goal of Fusion is not to create a new game, but rather to allow different games to play together. In finding ways to allow these games to interact, it was important to keep the essence of those genres intact and recognizable. We want players of any genre integrated into Fusion to be able to sit down and feel like the game is familiar.

4.All modes have significant interactions with each other. The ability to harm or support should be available between players of any mode. In addition to teams needing to be balanced regardless of team configuration, it’s also important that each player feel like they are playing directly with or against each other player.

For the purposes of our proof of concept, ACG chose three game genres: first person shooter, racing, and puzzle. We chose these because they are very different and the potential interactions between them are not obvious. If we can merge these three genres, it should be clear that other games and genres such as RTS, tower defense, Cooking Mama, and RPGs will also be able to be incorporated.

Inside Fusion, Soldiers have FPS mechanics, Pilots are modeled after racing games, and Hackers play puzzle games. Given our limited time, we used the mechanics of Bejeweled for the puzzle game, but the Hacker design could be applied to a wide range of puzzle games.

Level Design: Merging Spaces

If different game modes are truly going to play together, they must have a space in which to play. Passing information and resources back and forth is not enough; they have to share a space in order for players to really feel like they are playing together, rather than only playing related games.

If each mode has its own “space”, then two problems arise. The first is that it’s much harder to share moments, those specific events which everyone will be talking about after the game. In order to create those experiences, each player in the game needs to see the same event and understand it in similar ways.

Second, while it may be possible to have players in different places feel like they’re supporting each other, it’s extremely difficult to let them feel like they are opposing each other. In fact, the failings of the Hacker mode in the current design largely exist because they aren’t as integrated into the shared space as they need to be, an issue discussed at greater length in the Feedback section.

This shared space is a key challenge in any Fusion-like design, because the game spaces of different games are different for a reason. Arenas in first person shooters tend to be small and compact,emphasizing conflict over travel. Racing levels tend to be much larger so that there can be a significant amount of track. And puzzle games rarely deal directly with any sort of 3D world. Designing levels to accommodate these different games is difficult; we didn’t find any general rules to make the process easier.

There were three solutions we applied to the problem of scale difference between an FPS level and a racetrack. The first was to loop the track across itself into a figure eight. In this way, we fit more racetrack into a relatively compact space. This concept could certainly be further taken advantage of with an engine more specifically developed to allow for interesting racing physics, such as those seen in F-Zero.

Second, we made use of jump pads and could considered teleporters. Using these requires careful consideration, because it would be unfortunate if Soldiers could essentially move as fast as Pilots.

The level needs to be satisfying for all modes, but it’s important not to strip different play styles of their natural advantages. In our case, we used jump pads to allow faster access to key areas, creating points of conflict and interest where the FPS terrain and racetrack intersected.

Third, important areas for each mode should be combined so that all modes are encouraged to be in the same place as much as possible. In Fusion’s case, there are parts of the race track that are difficult or impossible to reach for Soldiers, but those locations don’t allow Pilots to earn points directly. All modes earn points at the same locations, making those places conflict zones where all modes must interact in order to achieve victory. Each mode can have areas that only they can access so long as the goals and mechanics of the game make it necessary to enter shared space.

Playtesting has shown that most of this design works as intended. The only flaw is that the racetrack has areas with no incentive for Soldiers to go. We thought that have points on conflict would be sufficient, but we’re finding that Soldiers quickly stop caring about Pilot positions because the time that they can interact for is so short. If we were to redesign the level, we would make greater use of jump pads and place more important points for Soldiers around all parts of the racetrack to allow much more of the game space to be shared between those two modes.

The puzzle player presented the unique problem of merging a game that normally does not deal with 3D space into a 3D world. It was important that the Hacker have a physical presence in order to feel like they were a part of the same game. It would be strange for Soldiers to know that they were being opposed by an enemy, but for that enemy to not have a physical manifestation to attack.

At the same time, puzzle players generally don’t navigate 3D space and given ACG’s goals, we did not want puzzle players to deal with such unfamiliar mechanics. Our solution was Hacker Nodes; physical locations that Hackers could log in and out of without directly navigating the level.

While logged into a node, Hackers have specific options dealing with the world around that Node, without having to directly interact with it. The other modes can see that a Hacker is in a Node and attack it accordingly. While logging in and out of nodes is somewhat new to puzzle players, it is an easy mechanic to learn and doesn’t take any time away from the main focus of playing the puzzle game.

A final challenge regarding level design in Fusion was symmetry. Having a symmetrical level that favors neither team is important in many games, but symmetry is dealt with differently in different genres. Specifically, racing games don’t have to worry about symmetry because all players are racing down the same track.

What this meant for Fusion was that given that each team had a base and the race track had to move through the same space, if Pilots started at a shared start line then they would move into one team’s territory first.

There were two potential fixes to this. The first would be to remove the concepts of bases or team territories, such that the disconnect between the symmetry of the world and the asymmetry of the racetrack would become irrelevant because each team would be equally affected. The second possibility would be to start Pilots for each team at different parts of the track. This option balances the level, but removes much of the feel of a traditional racing game.

We opted for the second choice because having territories made creating shared goals for all modes much easier. This solution did cause the Pilot design to drift slightly away from a traditional racing feel. The solution was not perfect and the problem should be further explored. With further development, it’s likely that a track configuration where Pilots from either team can begin at the same starting line without either team having an advantage could be found.
 
Help and Harm: Translating Intent and Skill between Modes

Creating a social experience in multiplayer games relies on each player understanding two things about each other player; their intent and their skill. Game specifics like weapons and health matter much less than knowing what your allies and enemies are trying to do, and how good they are at it.

At its core, the goal of ACG is to remove the element of personal taste from the game while allowing intent and skill to remain, such that each player can show off their talent and strategy without having to fit those things into a genre that other people prefer.

As such, translating intent and skill between modes is absolutely essential to making a Fusion-style game. The game’s framework must allow players to express their intent and their skill at their own mode in a way that is easily recognizable and has a large effect on each other mode.

The clearest example of this in Fusion is translating aggression in and out of the Hacker mode. When an FPS player fires a weapon at someone, their intent is to kill that player. Their ability t do this quickly without getting killed themselves is the measure of their skill.

Normally this mechanic involves a health meter of some sort. Gunfire can generally be avoided by actions like dodging. But health is a concept rarely used in puzzle games and forcing that concept into the Hacker design would have created a disconnect between the Hacker mode and the puzzle genre that inspired it.

What is important is that the Hacker knows that he is being attacked and that he has a way to respond. As such, when a Hacker Node is fired upon, the puzzle gets correspondingly harder. If the Hacker fails the puzzle while this is happening, then the hacker is booted, which has a similar effect to being killed or destroyed in the other modes.

If the hacker responds to the damage by successfully completing the puzzle despite the increased difficulty, then the Hacker escapes unharmed, essentially having ‘dodged.’ In this way, Soldiers attack in their traditional way and Hackers defend by doing well at the puzzle game. Their skills are being tested against one another without either needing to concern themselves with unfamiliar mechanics.

Hackers need a way to not only endure attacks, but also retaliate or start attacks of their own. Soldiers and Pilots understand aggression in the form of weapons fire or, in the Pilot’s case, obstacles appearing on the road. Puzzle players shouldn’t be forced to aim or otherwise deal with the 3D world, so having them deal directly with those sorts of attacks wouldn’t work. There should be a way for their puzzling prowess to directly translate into effective attacks. We accomplished this through the use of automated turrets.

Hackers have the ability to spawn turrets near their nodes, which automatically attack nearby enemies. How often Hackers can create turrets is item-based, meaning that a Hacker creating a lot of turrets could be the result of good teammates, rather than skill on their part.

But the Hacker chooses what node to be at when they create turrets, putting the strategic element in their hands. More importantly, the effectiveness of the turrets depends on how well the Hacker is puzzling, so if turrets appear and begin decimating the opposing team, it is clear that the Hacker responsible must be quite good.

This specific aspect of Fusion’s design illustrates the importance to translating both a player’s intent and a player’s skill between modes, so that the player on the receiving end can understand both aspects inside the context of their own game. This is important for game balance and cohesion, but also necessary in order for players in different modes to respect each other’s the strategy and skill.

Intuitive Common Goals

How victory is defined needs to be easily understood within the context of each game mode. While not absolutely necessary, we recommend that some form of abstract point system be used, although specific goals can be designed around it. Actions like killing, solving problems, or completing laps can sometimes be hard to tie together into an understandable team goal and it’s important that each player understand how each other mode is succeeding so that they can either help or stop them.

If the way of succeeding in a traditional genre can be incorporated into a shared point system, then each player can strive for success in familiar ways, while seeing the success of players in other modes being reflected through the same system.

For Fusion, we kept this system very abstract as a matter of scope. We considered making a number of smaller goals that worked towards victory which could each be accomplished by any mode. For instance, a sealed door could be destroyed by Soldiers, bypassed by Pilots, or forced to open by Hackers, allowing that team that much closer to their opponents’ base.

Due to scope issues, we abandoned those ideas in favor of simpler design, but we believe that a more complicated level with smaller shared goals could do a lot increase the variety and cooperative elements of a Fusion-style game.

Game Balance

A feature of Fusion’s design that people were generally skeptical of was the ability to balance teams regardless of configuration. Making the three modes balanced within a team seemed like enough of a challenge without trying to make a team of three Hackers equal to a team of one of each mode.

While it is certainly true that balance is a difficult aspect of any design and is particularly challenging in a Fusion-style game, it is not insurmountable by any means. Balance can be tested and adjusted in a similar way to any design as long as the actions available to each mode are thought of in general terms. In other words, we strove to make each mode equally good at the three roles of attacking, defending, and supporting. As long as each mode is equally good at each of these three areas, then the mix of modes on a team becomes a much less significant factor.

This in itself can be fairly difficult, as fully explained in the next section. In addition to the problem of different modes having different strengths, there are two other factors that make balance difficult. The first is that interesting mode interactions have to be carefully considered and sometimes thrown out if there are not equivalent opportunities for other modes.

For instance, if Pilots have the ability to take Soldiers to an area not reachable on foot, then Hackers also need a way to provide that assistance, or alternatively Hackers need an option for helping Soldiers that is equally as powerful and as interesting as the Pilot option. This gets back to our original design philosophy of no player being pressured into a particular mode.

If options exist only for specific team configurations, then groups of players will feel pressured to use those configurations. This constraint can be difficult to work around and results in the abandonment of many potentially exciting interactions.

This was the result of our aim to create a situation where no player is pressured to choose any particular mode. A Fusion-style game could certainly be designed where the emphasis is on complex strategy, rather than ACG’s goals. In that instance, designing elements that require or encourage specific team configurations would certainly be an option.

Similarly, we refrained from design options that would have added interest to modes, but also would have taken them further from the genre that inspires them. For instance, Hackers could be given the ability to specifically place their turrets, which adds a lot more tactical control. That mechanic is very reminiscent of Tower Defense rather than Puzzle, however, and so we didn’t put it in.

The one aspect of balance we have found most difficult has come from creating interactions within a single mode. We want each mode to be able to help each other mode, but if a Soldier can help another Soldier, it becomes much trickier to make it so that a single Soldier is encouraged to work in a team instead of using those game elements to simply help themselves. Designing mechanics where a player in one mode can help other players in the same mode, but not themselves is certainly possible, but it’s generally more awkward and would take more time to develop.

For instance, the racetrack could have a trigger that when driven over open a better track for Pilots, but if this track was behind the trigger than the triggering Pilot wouldn’t be able to use it themselves. This sort of mechanic that specifically aims to keep the benefits of an action from the player initiating it has the potential to be confusing to players. As a result, teams in the current iteration of Fusion generally benefit from having at least two modes represented.

Not All Modes Are Created Equal

Our design principle of having each role be equally good at attacking, defending, or supporting was the first to principle to be reconsidered in response to design challenges. Everything about a first person shooter is designed to be aggressive, and putting that level of aggression in a racing game is very difficult, largely because racers have less ability to hunt down other players.

While attempting to solve this problem, we realized that we also need to take into account different mindsets. Not only is it mechanically more difficult to have racers be as aggressive as shooters, it also isn’t something that players who gravitate towards racing games are looking for.

As a result, we are amending our principle to state that each genre should be as equal as possible in the roles of attack, defense, and support, and that when it comes to balance the designers need to make sure that the strengths and weaknesses of each mode are balanced.

In Fusion, Pilots are not as good at being aggressive as Soldiers, but they are significantly faster and more able to earn points than Soldiers unless they’re being attacked.

As a result, a Soldier-heavy team will be more aggressive than a Pilot-heavy team, but will also have to use that aggression well to counter the benefits afforded by a Pilot-heavy team.

Finding Weaknesses

The key to finding good ways for one mode to help another is to find the other mode’s weaknesses. It is useless to design cooperative elements that no one is inclined to use. A player has to be thinking, “I wish my mode was better at…” and then provide a way for another mode to solve the problem.

The Soldier-Pilot passenger mechanic in Fusion is based on the idea that Soldiers feel slow and will want to take advantage of a Pilot’s speed. At the same time, Pilots feel vulnerable and want to take advantage of a Soldier’s firepower. Creating these interactions with Hackers was more difficult because Bejeweled doesn’t lend itself to these kinds of opportunities for assistance. We created some weaknesses for Hackers in the overall framework of the game, but because those weaknesses aren’t a part of Bejeweled itself, Hackers weren’t inclined to worry about them.

We finally decided that what Bejeweled players want is the ability to destroy more gems and earn levels faster. To aid in that, the other modes can unlock additional Hacker Nodes across the level for their team, which give these sorts of bonuses to their Hackers when logged in.

Cooperation Should be Obvious

One of the overarching systems that applies to every mode in Fusion is the team inventory. We created a shared inventory and the ability for team members to collect items for any mode as a way to allow any player to quickly and intuitively help any other. This has worked to an extent, but it fails to create a real sense of teamwork because it isn’t easily noticeable.

Having the items you need when you need them is rewarding and creates a sense that there’s some help among the team, but because the system is external to the game world and because messages concerning who is earning and using items are largely ignored, it doesn’t create any real direct connection between players.

In contrast, the ability for Pilots to pick up Soldiers is significantly more rewarding because it’s directly apparent what the benefits are and who’s helping who. General systems like the inventory are still useful and provide a low-cost way to begin integrating new genres, but in order to create real shared moments between players in different modes, there must be mechanics that allow both players to directly see the effects of the teamwork.

Constraints on Genre-Selection

What genres can be merged into a Fusion-style game? Our only constraint when creating Fusion was that it be real-time. Merging real-time genres with non-real-time genres would be an additional challenge. True cooperative gaming would be hampered by the very nature of turn-based or play-whenever games, but a system could be devised where support could flow in and out of real-time.

Mechanics Should Be Shared

To make Fusion approachable to a large variety of gamers, it is important that our design not require a player in one mode to understand exactly how the other modes work. We ran into a problem where this was taken too far and some players didn’t understand how to thwart the other modes.

Specifically, Hackers rely on a level system and initially the other modes didn’t. Preventing Hackers from accruing too many levels is key to stopping them from winning, but since Soldiers and Pilots had no parallel system, that was never an easy thing to remember or respond to. We wanted to keep the level system for Hackers, and so we created parallel level systems for Pilots and Soldiers using elements already prevalent inside their own experience. Soldiers earned levels with kills and Pilots earned them with laps.

All three modes earn more points at higher level and lose levels for being destroyed. By making the mechanic universal instead of mode-specific and by publicly displaying the current level of all players, we created an awareness in all players of how to use the system to their advantage and overly-leveled Hackers became far less of a problem.

Feedback

Giving players feedback is important in any game, but especially so in something like Fusion. Because a player in one mode may not understand how the other modes work, it’s important that they get feedback telling them how teams and individuals are doing. Specifically, they may not intuitively know when one of their allies needs help or when one of their enemies has become a significant threat and needs to be dealt with. Explicit messages alerting them to dangerous and important situations clear up a lot of the confusion in the game.

Earlier it was described how intent has to be translated between game modes. The actual translation can be behind the scenes, but the results sometimes need to be made explicit. In the Soldier-Hacker example, a Soldier needs feedback on how much damage they are dealing to a Hacker Node since a Hacker’s form of “dodging” isn’t apparent in the world.

And Hackers need explicit messages telling them when their turrets have killed an enemy since they’re focused on their game board, rather than the turrets. Whenever a player is given the chance to affect another mode, the design needs to take into account how apparent it will be to them if they’re successful or not and how to make it more obvious if need be.
 
Integration

The way that puzzle gaming was integrated into Fusion succeeded in several aspects, but failed to some degree in making the Hacker truly feel like they were a part of the shared experienced. The reason for this was the disconnect between the actual puzzle mechanics and the larger world.

All of the Soldier and Pilot’s potential actions had some effect on the shared space, but the actual puzzle mechanics did not. Fusion’s design made strong ties between success in the puzzle game  and effects on the larger game, but the puzzle itself had no connection. We believed that the ties would be enough, but because puzzle games tend to make players myopicly focused on the task at hand, the disconnect between that task and what their allies and enemies were doing resulted in Hackers feeling more isolated than the other modes.

The lesson learned here is that the mechanics of any mode in a Fusion-style game should relate directly to the larger world as much as possible. Ideally, a puzzle game would relate directly to the terrain around the Hacker node and things like other players moving through that space would directly affect the puzzle.

With the current set-up, feedback about the world was helpful to Hackers, but it was often ignored because of how far removed it was from what Hackers were trying to accomplish from moment to moment.

Unintended Benefits

With Fusion, our hope was to allow each player to play a mode familiar to them, without needing to understand much about the other styles of play. Not only did that work well, we discovered an interesting aspect of Fusion that we had not expected.

In most of our play tests most players played a mode for three or so games and then switched to one of the others. Although they generally preferred their initial mode, seeing the other game types in the same world made them want to see how those modes worked as well.

In this way, many players explored game genres they otherwise have little interest in and in some cases enjoyed them more than expected. Although this is secondary to our intended goals, it’s exciting that a Fusion-style game could allow players to not only play together, but also to share their own tastes with each other.

Conclusions

The purpose of the ACG project was to explore the difficulties and potential of merging genres into a single game experience. What we found is that the design of such games is difficult and presents unique challenges, but more importantly that these challenges are managaeble and well worth the effort. With more development time, we believe that a game like Fusion would not only be possible, but also very well received.

Merging the mechanics of multiple genres is not especially difficult. A well thought-out framework that translates player intent and skill between modes is an essential first step. This framework must provide a clear goal for the team of players independent of the specific modes. Once developed, this framework makes the process of integrating the games no different from any other design process. Then the development of specific interactions and features can progress just like any other design.

Merging audiences is similarly possible. The premise we worked from was that these different people already want to play together; they just do not have an enjoyable way to do so. That turned out to be largely true, and testing shows that a wide variety of gamers do enjoy Fusion and the opportunity it provides for shared play. It also provided a way for players of different genres to show each other their own skill in a context that would earn respect from each other. The main difficulty is in allowing different play styles.

Different audiences will enjoy different levels of conflict and strategy and it’s important that players in each mode have an ability to play the game in such a way that it appeals to their tastes.

We also recommend that in an asymmetrical cooperative game, different skins be available such that players have some control over the artistic style they experience. If players could control aspects such as the sound effects to the level of gore, they would be able to custom-tailor the experience to better suit their tastes.

The end result of our design, development, and testing is that we are confident that merged-genre games are possible and enjoyable. Within the scope of this project, we discovered particular difficulties with aspects such as keeping a genre’s feel intact while affording it the same basic options as each other mode inside the game.

The changes we made in response to these discoveries have created improvement to the player experience even within our limited time frame and we have no doubt that such obstacles can be overcome without much more difficulty than design challenges in traditional single-genre games.

As a final note, we leave you with these general design principles that we hope can serve as guides in the design of this style of game:

1.Translate intent and skill. Any action that a player takes in a Fusion-style game has to be understandable by each other mode in so far as they know what the player’s intention is, and how good they are at it. This is the driving force behind successfully merging genres.

2.Specific interactions are more powerful than general ones. Abstract systems such as points and inventories have their place in these designs, but they aren’t enough to create a shared experience.

There must be interactions between each mode that happen concretely in the game world and have obvious effects for each player involved.
 
3.Decide on a theme for each mode. Determine what skills are to be most rewarded in each mode and design all interactions and challenges for that mode around those skills. If the theme of the overall game is counter to a mode’s theme, one or the other may have to shift to accommodate.

4.Share mechanics when possible. Understanding the specifics of other modes shouldn’t be essential for a player, but they must understand other modes enough that they can support or hinder them. As such, if understanding an aspect of a mode is essential to helping or harming players in that mode, other players will be less confused if elements of that mechanic are integrated into their modes as well. （source:gamasutra）