民初思韻網

加入收藏   設為首頁
選擇語言   簡體中文
你好,請 登陸 或 注冊
首頁 人文思韻 傳奇人物 歷史思潮 時代作品 話題討論 國民思韻 民初捐助 賬戶管理
  搜索  
    人文精神 >>> 技術的天空 溫和的思緒
字體    

[技術交流] 手游主玩法系統中被忽略的管理中樞機制
[技術交流] 手游主玩法系統中被忽略的管理中樞機制
GameRes游資網     阅读简体中文版

GameRes發布,文/猴與花果山,轉載請注明作者和出處


所謂主玩法系統什么是游戲的主玩法系統?這個要追述到一些最近2年才從大佬們嘴中流行出來的系統分類:

核心玩法系統一個游戲的亮點,無論在市場推廣的時候還是在策劃研發的時候,都是十分重視的系統,絕大多數手游的核心玩法系統表現為戰斗系統。這個系統理論上會花最大量時間去設計開發,因為游戲的一切玩法理論上都是圍繞著他延伸的。但是理論上始終是理論上,我們研發的是游戲產品,不是研發游戲。

主玩法系統主玩法系統,其實就是大佬們嘴中所說的游戲“可玩性”,當然系統越多的游戲可以玩得東西就越多,數據理論上也會越好,這當然是沒錯的(請不要用BLZ反駁,大佬們認為這世界上是有奇跡的),“可玩性”故名思義就是可以玩得東西么。你不這么認為?我原來也不,只是我重新定義了“可玩性”這個詞而已。那么什么主玩法系統呢?通俗易懂的說法就是:游戲中那些可有可無的玩法系統,沒有這些系統游戲一樣能玩,因此很多時候是被硬湊出來的,最常見的就是秦時明月的武將突破,突破以后僅僅提高了數字,假如游戲設計的時候不設計這塊能不能玩?當然!甚至玩起來目標更清晰,游戲更偉大,但是不這么設計,渠道發行不買單阿——收費點少了,影響數據。所以我們在游戲中必須加上成千上萬個主玩法系統。由于海量的存在,主玩法系統最終成了游戲研發過程中最花時間的部分,本貼的討論目的實際上也就是為了簡化這個過程。

其他系統郵件、公會、好友之類的系統,即使是應用軟件都會有的系統,沒人認為開發這玩意兒存在什么問題,事實上也是再弱的團隊一周內就能搞定這些玩意兒了。

被弄丟的管理中樞機制

  明確了什么是主玩法系統之后,我們很快就能從腦袋里拿出很多很多已經設計好的主玩法系統來,并且在很多游戲中已經確實實現了。可是我們實際開發中通常犯了一個錯誤,就是把這些系統想復雜了,甚至每個系統去單獨開發邏輯,雖然也并沒多花多少時間,但是在調試、后期擴展的時候頭疼不已。

  最常見的頭疼現象:策劃設計了一個抽卡系統,一開始說了我們能抽到的都是武將和碎片,開發完了運營說話了,我們還能抽到體力,這時候就開始勞命傷財了,策劃去擴展表項,至少得把MagicNumber的意義擴展了吧,程序則對應去實現代碼,當然最頭疼的不是實現本身,而是再啃一遍已經封存了的代碼。

  事實上我們可以嘗試這樣一個做法——先一句話描述一下你要開發的那些主玩法系統,會是如何?我簡單的舉幾個例子:

抽卡系統玩家按照規則支付一定的元寶,然后隨機抽取,最后獲得武將或者碎片。
簽到系統玩家每天可以簽到一次,根據一定規則,最后獲得當天可以獲得的貨幣或者道具。
吃飯系統玩家每天一定時間內,可以吃一次,最后獲得一定數量的體力。

  當我們說到這里的時候,你應該不難想到,之后深入要設計的無非就是抽卡得支付元寶規則、隨機規則、簽到的規則等規則,以及最后獲得的東西的內容范圍。沒有經驗的策劃可能會在這里認為這樣的設計就沒有問題了,事實上這樣的設計只是停留在玩家交流階段,任何有經驗的程序員都會問一個問題:“你最后獲得的東西一定不會擴展了?比如抽卡一定只能抽到武將或碎片?”,這時候沒有經驗的策劃甚至會拍胸脯保證。可事實上在這里,我們弄丟了一個核心的東西——我們需要的是一個管理中樞,由這個管理中樞來管理東西(我也不知道怎么稱呼好了,thing恐怕是最合適的了)的獲得。



  假如我們按照上圖這個邏輯來整理邏輯,你不難看出:

  1,在我們需要獲得任何東西的時候,我們都向管理中樞提出請求,當然中間可以插入(但不建議)一個額外的條件判斷。

  2,所謂的“分析請求”實際上就是這個管理中樞的核心工作。

  3,分配各種東西給玩家對應的數據塊。比如道具、比如體力,我們知道通常這些東西,包括我們所理解的道具本身都會產生不同的結構,比如武器和藥丸和鑰匙之類的,最終真的用同樣的數據結構嗎?如果不,我們是不是至少需要每個都有一個數組去記錄?那么這些東西在策劃填表的時候是否本身就該區分開?(至少某些表格的內容會有明顯區別)

  這個思路其實就是所謂的“管理中樞機制”的核心所在,他的好處在于一個更高的可擴展性,以及后期程序不用太大的去改動代碼,簡單的例子就是:

  簽到系統:最初策劃的設計是,每天簽到可以得到配表中的道具(擴展的什么連續多少天獲得什么我們姑且不說,各家有各家的做法,但原理相同于每天簽的東西),但是運營認為不夠,除了道具我們還要能簽到小弟,還能簽出碎片。這時候我們傳統的做法是做一個禮包之類,而禮包本身其實就是這個管理中樞,只是沒有機制化的管理。

  從我們的這個機制來看,簽到系統是如何工作的?


  我們對比傳統做法和管理中樞機制,區別僅僅在于最后一步“發放獎勵”的過程。但玄機也在這里,因為最后一步決定了一個可擴展性和策劃表項的問題,當然這里的可擴展性僅僅只是可以給的東西的可擴展性。

  我們先看下傳統的表項會有什么數據?

  1,id:還是有比較好。

  2,時間:可能是用于幾月幾號,也可能是簽到多少天,這個具體看策劃設計的規則,但肯定有一個時間。

  3,獎勵道具id:獎勵什么道具。

  4,獎勵道具個數:就給1個肯定滿足不了需求吧。

  那么現在問題來了,運營說話了,我們要簽到給小弟,怎么辦?做法2個:

  1,增加一種道具叫做小弟,得到道具給小弟,聰明的做法。

  2,傻瓜做法,增加表項:獎勵類型,這個MagicNumber決定了獎勵的是道具還是小弟,0=道具,1=小弟,自然的,原來的“獎勵道具id”和"獎勵道具個數“根據這個MagicNumber值不同也被賦予了不同的意義。

  無論你怎么做,最后的結果是,程序必須去增加一個道具獲得方式,改變讀表的代碼是少不了的工作,畢竟你表項改變了,至少某些數據的意義發生了變化。這樣的擴展手法其實是不良的,那么看看我們的管理中樞機制是如何工作的?

  還是先看一下表項有些什么數據?我們可以把它分為2個表,其中一個叫做東西表,這個東西表的用途不僅僅是在簽到,她的數據一樣可以用于抽簽等其他系統:

  1,id:別的數據掛過來的依據。

  2,執行腳本:事實上對于策劃來說,需要的只是填寫一個String,甚至如果環境允許就直接在里面寫函數了。程序在“分析請求”的時候要做的事情就是執行這個腳本。Array<Dynamic>->Dynamic (Haxe),傳入的數據是腳本參數,返回的是獲得的東西,所以都采用Dynamic。

  3,腳本參數:腳本需要的參數,Array<Dynamic>,根據每個腳本需要去傳。

  我們嘗試虛擬2條數據,一條是獲得id=333的道具20個,一條是獲得id=216的武將,如果武將已經存在則是她的靈魂碎片。則數據為:

thing[0]=[script="gain_item", param=[333,20]];
thing[1]=[script="gain_buddy", param=[216]];


  我們在通過簽到去掛向這個表,簽到的表項為:

  1,時間:同傳統模式。
  2,獲取:int,也就是對應thing的id。

  除了簽到外,其他表一樣可以索引thing的數據,比如我們需要一個抽簽表,表項為:

  1,thingId:對應到thing表的id。        
  2,出現加權:這個thing被抽取的概率。
  3,必出多少
  4,在多少次中:和3共用形成“1000次抽取中必出3個這東西”的效果,此處不作詳細解釋。

  說到這里,你應該大概能看出這個機制的一個好處,但是這里還有一個疑問應該留在你心里——“一條是獲得id=216的武將,如果武將已經存在則是她的靈魂碎片”這玩意兒應該如何去做?這里通常思路會犯一個錯誤:我們直接在腳本中判斷:

if (iHaveBuddyById(216)==true){
   giveSoulShard(216, Math.ceil(Math.random()*10));//錯在這里
}else{
   giveBuddy(216);
}


  我們可以看到上面一段偽代碼中,有一個嚴重的錯誤,就是當我們判斷到已經有武將了,沒有通過這個中樞機制就直接給了靈魂碎片,這形成了一個錯誤的邏輯交叉:


  既然分析請求已經執行了腳本,那么要么就是給出武將要么就是給出碎片,因此在給出武將未果的情況下,應該重新提交一個請求給自己,那就是給出碎片的請求:


  這樣才是一個正確的執行流程,因為我們需要保證,游戲中給的任何東西都是走這個中樞機制的,為什么要這作,因為這里有一個真正的可擴展性存在,舉一個簡單的例子:

  1,我們要設計成就了——獲得過100個道具,請注意是獲得過,而不是你的背包里實際有!那么你必須要有一個點去統計你獲得過多少個道具。

  2,我們要設計挑戰了——獲得楊過之后獲得小龍女,然后獲得尹志平,請注意,獲得順序必須是這樣的,楊過-〉小龍女-〉尹志平,那么在這個流程上該干什么?你看出來了嗎?

實際游戲開發中的使用感覺

  其實說到這里你應該已經多少看出來了,這個機制用于游戲的絕大多數主玩法都沒問題,因為所謂的主玩法無非就是玩家通過一定規則獲得一定好處。而這個機制的關鍵就在于把好處抽象成一個東西,整體管理。

  而在實際開發中,我們發現程序在完成了這個機制的coding之后,不需要對這個機制的代碼在作什么改動,只需要在對應的系統中提供腳本接口和維護功能就可以了。但是這玩意兒有一個門檻,就是對于策劃的抽象能力要求會略微高那么一點,如果用一個數字來形容的話,一般策劃需要60以上,而玩這個機制的策劃需要64以上。


2015-08-23 08:38

歡迎訂閱我們的微信公眾賬號!
春秋茶館訂閱號
微信號 season-tea(春秋茶館)
每天分享一篇科技/遊戲/人文類的資訊,點綴生活,啟迪思想,探討古典韻味。
  清末民初歷史人物  民初人物
學貫中西品讀東西文化
林語堂(1895年10月10日-1976年3月26日),中國文學家、發明家。福建省龍溪(現為漳州市平和縣)坂仔鎮人,乳名和樂,名玉堂,後改為語堂。美國哈佛大學比較文學碩士....
傳統官僚翰林總統
徐世昌(1855年10月24日-1939年6月5日),字卜五,號菊人,又號水竹邨人、弢齋。祖籍浙江寧波鄞縣。清末民初,曾為北洋政府官僚。1918年,徐世昌獲段祺瑞控制的安....
資助民初精神網
        回頂部     寫評論

 
評論集
暫無評論!
發表評論歡迎你的評論
昵稱:     登陸  註冊
主頁:  
郵箱:  (僅管理員可見)

驗證:   验证码(不區分大小寫)  
© 2011   民初思韻網-清末民初傳奇時代的發現與復興   版權所有   加入收藏    設為首頁    聯繫我們    1616導航