游戏策划入门修行（六）——浅析基础副本系统的设计
有了任务系统和引导系统，我们还需要一套完善的副本玩法，用以支撑玩家的日常游戏内容。副本也是偏休闲类游戏玩家比较喜欢的玩法之一。
早期端游还没有做副本的时候，玩家每日游戏获得的资源是没有保障也没有限制的。后来游戏种类越来越多，玩家的选择多了之后就越来越不太愿意浪费大把的时间在产出未知的游戏上了。这是副本玩法出现并流行起来的原因之一。
有了副本玩法以后，大部分游戏都会在副本中投放一些保底资源。玩家只要完成每天限定的副本次数就可以获得相应的游戏资源。比较有代表性的就是装备副本、金币副本、经验副本等。
卡牌类的这种纯副本游戏对于副本玩法的设计以及用户付费体验的设计是达到了一个很高的水平的。最简单的，付费对应着体力值，体力值对应着副本次数，从而玩家获得游戏资源就有了计算依据。
除了资源产出控制之外，副本还会用在很多特殊玩法的制作上。比如验证玩家PVE实力的通天塔；验证PVP实力的竞技场；还有一些特殊的趣味性玩法，像五行八卦、闯迷宫等，这些都是以副本的形式来表现的。
那么在这篇文章中，我们就从一个游戏策划的角度来谈一谈基础副本系统的设计。
基础副本结构设计
常见的副本内容会包含以下几个元素：地图、过场动画、刷怪、剧情对话、机关陷阱、关卡BOSS、隐藏宝箱等。
另外，副本中还会设有开启条件(战力、体力、通关前置关卡等)限制、通关时间、通关评级、通关奖励、扫荡机制等基础机制。
根据以上分析我们整理出副本的基础结构大致如下所示：
简单的副本流程
我们希望策划人员可以根据基础副本机制，灵活地配置和制作出各种各样的副本玩法。所以根据结构图我们定义出一套通用的副本配置：
<Config>
<!--
maoID 副本对应使用的地图
copyType 副本类型(用来区分单人、多人、活动副本等)
openLevel 开启最低等级
needAbility 开启所需战力
needPower 开启消耗的体力
lastTime 副本持续时间
pasReward 通关奖励
mopReward 扫荡奖励
action 副本当中的相关指令
createBlock 创造地图阻挡
destroyBlock 撤销地图阻挡
story 播放剧情
summon 招怪
killAll 击杀要求
locateact 定点触发相应机制
trap 召唤陷阱
success 副本通关信号
-->
<Copy id="1" mapID="1" copyType="1" openLevel="5" needAbility="100" needPower="10" lastTime="600" pasReward="1001" mopReward="2001">
<action act="createBlock" id="1" pos="100,100"/>
<action act="createBlock" id="2" pos="200,200"/>
<action act="story" storyID="1"/>
<action act="summon" npcID="101" num="10" pos="100,100" radius="5" ai="1"/>
<action act="killAll" npcID="101"/>
<action act="destroyBlock" id="1"/>
<action act="locateact" pos="100,100" radius="5"/>
<action act="summon" npcID="102" num="10" pos="110,110" radius="5" ai="2">
<action act="killAll" npcID="102"/>
<action act="trap" trapID="1" pos="110,110"/>
<action act="summon" npcID="103" num="1" pos="120,120" radius="1" ai="3">
<action act="summon" npcID="104" num="10" pos="120,120" radius="5" ai="2"/>
<action act="killAll" npcID="103" clearOther="1"/>
<action act="success" leave="1"/>
</Copy>
</Config>
程序完成副本配置各个功能的制作，策划就可以用这套系统制作出各种有(zhuang)趣(bi)的关卡了。
是不是感觉跟任务的配置方式有点类似？其实在执行副本的时候，就相当于在执行一个小型的任务系统。这个任务是自成一套体系，且只有在副本中才会生效的。
- 举个例子，剧情副本的制作
仅有一套基础的副本系统，想要做出剧情副本、通天塔、迷宫等玩法肯定是不够的。基础副本系统是一个个单独的副本，我们需要的是能将一系列副本串联起来，形成一个玩法体系，这里我们以最简单的剧情副本为例子，分析一下一套副本体系的制作方式。
剧情副本的每一个章节都对应着多个副本
这里副本就不再是单独存在的个体了，我们需要一个方便对其进行统一管理的方式。最常见的做法就是增加一个配置，可以将其命名为Story，然后在这里面引用各个单独的副本组成完整的剧情副本体系。
<Config>
<Story>
<Chapter id="1" image="1,1,1" openLevel="1">
<section id="1" image="1,2,1" copyID="1" needLevel="1" reward="1001"/>
<section id="2"image="1,2,2" copyID="2" needLevel="2" reward="1002"/>
<section id="3"image="1,2,3" copyID="3" needLevel="3" reward="1003"/>
</Chapter>
<Chapter id="2" image="1,1,2" openLevel="4">
<section id="1" image="1,2,4" copyID="4" needLevel="4" reward="1004"/>
<section id="2"image="1,2,5" copyID="5" needLevel="5" reward="1005"/>
<section id="3"image="1,2,6" copyID="6" needLevel="6" reward="1006"/>
</Chapter>
</Story>
</Config>
服务器副本与客户端副本
经常玩手机游戏的朋友们可能会注意到这一点，战斗比较炫酷、技能释放节奏快、技能特效比较绚丽的游戏，一般野外战斗都会比较少，以单人的副本闯关玩法居多。多人的玩法也几乎都以小规模团战为主，这就是大家常说的ARPG游戏。
与之相反的是，那些主玩野外战斗或者是主打大规模群战的游戏，在技能表现这一块和副本玩法这一块会相对简单一点，一般不会有特别炫酷的表现，也就是大家常说的MMORPG。
这中间有什么原因呢？难道就不能二者中和，做一个表现强力同时又有比较多的野外战斗玩法的MMOARPG游戏吗？
这主要还是归根于服务器性能和制作成本两个原因。
最开始副本是由服务器生成的，即每开启一个副本，服务器都需要开辟一块区域用于进行玩家副本游戏的计算。当有很多玩家去开启副本玩法时，服务器副本会达到一个很大的并发量，这会给服务器带来非常大的计算压力。这时候玩家在游戏中就会感觉到明显的延时卡顿，甚至会出现服务器宕机的情况。
野外大规模战斗对于服务器的性能要求也非常高。大量的副本逻辑计算和大规模玩法同时存在，对于服务器来说是毁灭性的压力
一般的，为了提升游戏体验，同时避免服务器宕机，游戏会限制单服游戏人数。但是服务器人数过少对于mmorpg类游戏来说体验就会比较差了。所以比较常见的做法就是将单人的副本玩法做在客户端上。言下之意就是单人副本的开启和结算由服务器控制，玩法过程和计算逻辑就在玩家自己的客户端上完成。
同时为了给玩家一致的战斗体验，不能因为单人副本做在客户端上就让人感觉是在玩另外一个游戏。所以客户端还需要制作出一套与服务器相同的复杂的战斗系统，和各种技能实际效果等。
不讲究研发成本投入和研发周期，是可以把游戏（尤其是手游）各方面都做的非常棒的。但实际情况是，市场千变万化，资金投入也有限定，所以造就了ARPG不重大规模团战玩法，而MMORPG战斗表现就相对薄弱的情况。
当然也有游戏立项就是以特定的玩家群体为目标的，毕竟ARPG游戏与MMORPG游戏的核心设计仍然有比较大的差异。
