有了任務系統和引導系統，我們還需要一套完善的副本玩法，用以支撐玩家的日常游戲內容。副本也是偏休閑類游戲玩家比較喜歡的玩法之一。
早期端游還沒有做副本的時候，玩家每日游戲獲得的資源是沒有保障也沒有限制的。后來游戲種類越來越多，玩家的選擇多了之后就越來越不太愿意浪費大把的時間在產出未知的游戲上了。這是副本玩法出現并流行起來的原因之一。
有了副本玩法以后，大部分游戲都會在副本中投放一些保底資源。玩家只要完成每天限定的副本次數就可以獲得相應的游戲資源。比較有代表性的就是裝備副本、金幣副本、經驗副本等。
卡牌類的這種純副本游戲對于副本玩法的設計以及用戶付費體驗的設計是達到了一個很高的水平的。最簡單的，付費對應著體力值，體力值對應著副本次數，從而玩家獲得游戲資源就有了計算依據。
除了資源產出控制之外，副本還會用在很多特殊玩法的制作上。比如驗證玩家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游戲的核心設計仍然有比較大的差異。
