>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

GameRes發布，文/猴與花果山，轉載請注明出處

很早以前就想寫一篇關于我說的一些機制在實際開發中的運用的帖，但是一直沒有一個話題，所以一直以來只能零零碎碎的發些技術交流。正好最近在項目后期的空檔里，抽1天休息時間單獨做了一個HTML5的小游戲，就拿這個我一個策劃用一天（還不到）的時間單獨完成的游戲來詳細說說，基于數據驅動設計思路的游戲該如何設計和實現吧。首先發一下這個游戲的2維碼，沒東西還說什么了是吧。

閱讀原文進入demo頁面

游戲規則與詳細設計

假如你已經玩了這個游戲，乍一看你會認為這是一個傳統的戰棋類游戲。這個玩法其實是我們正在做的一款手游《江湖派》的核心戰斗玩法的精簡版，由于這個手游的設計中允許了玩家實時對戰，因此在這個游戲的規則設計中，我們思考且避免了SLG游戲中因為等待時間過長而帶來的問題，所以我們改變了傳統的SLG戰棋游戲的一些規則。你可以發現，這個游戲的核心規則更接近于太閣立志傳5的個人戰小游戲結合金庸Online的戰斗規則。

每個回合玩家需要做的事情是：

1，從可移動范圍內，選擇一個單元格，這是這回合要走過去的地方。

2，從上下左右4個方向中選擇一個，作為本回合的面向，而面向也決定了自己的攻擊方向。

在參與的每個玩家發布完畢以上指令之后（在這個HTML5版本中，是單機的，所以只有玩家自己發布指令），回合開始，所有的角色同時先移動到自己本回合移動目的地，如果目的地的單元格內有可以吃的道具，就會先吃掉道具，如回血的藥水等。然后所有角色同時發動攻擊，處于自己攻擊范圍（多個單元格）內的角色將受到自己攻擊的傷害。而在原游戲《江湖派》中，為了更多的數值可培養性，加入了身法屬性，由身法決定出手的先后順序，所有角色移動到目標單元格后，由身法最高的角色開始到身法最低的角色依次攻擊，這個規則的差異產生的結果差異是，身法低的角色在《江湖派》中可能沒機會攻擊身法高的角色就先掛了，然而在這個HTML5的游戲中，仍然可以對別人造成傷害。

整個游戲的樂趣在于，掌握了敵人的行動規律后，在盡可能少的被攻擊的情況下，盡可能多的對敵人造成傷害，其實說到這個玩法的時候，可能靈活的你已經想到了很多很多的規則擴展手段，包括且不限于：

1，增加一些地形，讓可以動的區域收到一些限制，如加大一些單元格的移動消耗（這個游戲中都是1），甚至這些地形還可以被摧毀。
2，一些單元格是特殊地形，走上去會產生特殊效果，比如被燒傷。
3，每一個回合一些單元格會出現火苗，在下一個回合單元格內冒出火柱。
4，增加buff給每個角色，增加游戲的不定性。
5，攻擊后產生AOE，比如某些角色的攻擊可以在攻擊范圍內留下釘子，持續2回合，移動到釘子上的角色會受到割裂等debuff。
6，增加我方的隨從配合戰斗，可以釋放合體技。
7，角色到一定條件下釋放大招。
8，小寵物加入戰斗，而小寵物本身和其他伙伴不同，也不是別的游戲那種就增加屬性的，而是小寵物可以輔助戰斗，且不會被殺死，比如你的小寵物是一只小猴子，當他與敵人移動到同一個單元格時會抱住敵人不讓敵人發動攻擊。
9，角色的攻擊范圍可以培養，比如帶不同的武功就有不同的攻擊范圍。

等等等等，你還可以想出很多很多很多擴展的玩法，的確這些玩法在《江湖派》中全都有了，在這個HTML5的游戲中，機制上也做到了，可是我并沒有去利用這個機制作這個設計，因為我認為既然把這個核心戰斗拿出來做一個小游戲，并且想在微信上和小伙伴們分享，就要讓它盡可能的輕。而現在的游戲規則是具有一定的探索性的，也就是說并不是所有人一上來都能看明白怎么玩得，需要一定的學習成本，當然假如你并不是抱著對抗心理（這個在游戲研發的日常討論中也很常有，最常見的表現就是一個勁的質疑這個玩法怎么復雜怎么不好上手，假如你存心不想上手，你連吃飯、大便都能學不會，事實就這么簡單，而存心不想上手的心態，就是一種對抗心理，就是認定了你這個東西不好了，所以這種情況我們不予以討論），那么這種學習的過程，僅在于2個回合，就目前事實的反饋來說，我老媽的一些老同事，從不玩游戲的阿姨們，都在3個回合內搞懂了游戲的玩法。

數據驅動的制作方式

數據驅動一直是游戲行業在探索的一種思路，數據驅動本身是一個很傳統的編程方式，Liunx的作者很早就提出了這個概念，并投入了實用，傳統軟件行業已經證明了這種模式的優勢，之前我在游資網也發過一篇技術交流貼探討了關于這個Data Driven思路的戰斗設計，需要的話前往游資網搜索查看。

我寫這個HTML5游戲的時候，思路仍然是客戶端和服務器的，和我做其他手游的思路是一樣的——客戶端只是一個簡單的瀏覽器，這個思路假如你做過早期的WebGame（大約08年時候JavaScript的那種）你就會很明白，我只是將客戶端當作一個沒有邏輯的瀏覽器，不用客戶端去實現核心邏輯（眼下包括刀塔傳奇在內的很多游戲戰斗是在客戶端的，也就是我用模擬器+FPE是可以輕松改變戰斗結果的，所以刀塔傳奇不會因為戰斗結果帶來額外的數據好處），當然我也不拋棄客戶端可以寫邏輯的優勢，一些基礎的判斷功（比如這個按鈕能不能按下）能還是會留在客戶端做第一層過濾。當然從邏輯上來說這是一個CS的游戲，但這個HTML5游戲本身是一個單機的，我只是把“客戶端”和“服務器端”打包在一起了而已。

那么我們接下來看看Data Driven在這個游戲中的運用：

首先我們要確定在這個游戲中有哪些元素是客戶端需要有的，用通常的思維邏輯去思考：

1，地上亮起來的2種格子——一種是我的移動范圍，一種是戰斗中展示角色的攻擊范圍的，顏色會有所不同。
2，角色——敵人的、我方的。
3，寶物——小蘋果，藥、小師妹的啤酒雞和VIP寶箱。
4，視覺特效——各種刀光等等。
假如是傳統的開發思路，我應該開發這些類：
1，格子類：派生出可點擊格子，其中屬性包括了顏色。
2，角色類：派生出主角，而敵人本身就采用角色類。
3，寶物類。
4，視覺特效類。

那么在數據驅動模式下，我們需要什么“類”呢？事實上在數據驅動模式下，所有的“類”只有Entity一個（事實上，在Entity System這種Data Driven的邏輯下，不應該還有類這個概念，這里只是為了說清楚事情，我也發現很多用unity的程序員仍然還抱這“類”這種OOP才有的概念，當然這也是unity為什么仍然還允許component可以寫邏輯的原因），一個Entity所包含的Component（也就是Data）決定了這個“類”“參與的工作”而非“工作性質”：

1，Sprite，這個Component決定了一個“類”能否被畫出來，并不是所有的Entity都是“玩家可見”的。在Sprite中有PointerDown\PointerUp等點擊事件，這些用來處理玩家對于該“對象”的操作。

2，BattleCharacterInfo，這個Component是標志一個Entity是否為戰斗角色的，在客戶端上，一個角色本身擁有一些額外信息(Data)要去記錄，比如這個角色的UniqueId等等，全都丟在這個Component里面。并且由這個Component的存在與否得到一個Entity是否是一個角色。值得注意的是，由于UI上敵我雙方的表現是不同的，所以才在這個Component中記錄了一個side屬性來決定這個角色在游戲規則下是屬于哪一方的。

3，BattleTreasureInfo，和BattleCharacterInfo類似，但他標志了這個Entity是一個寶箱，在客戶端，我并不關心寶箱吃掉后的效果是什么，所以他的屬性只需要UniqueId和Position（邏輯位置，而不是象素位置）就可以了，像素坐標和他的外觀信息，在創建這個Entity的時候已經賦給了Sprite了。

以這個眼光來看，我們游戲中的Entity：

1，地上的格子：僅擁有Sprite。
2，角色：Sprite+BattleCharacterInfo。
3，寶箱：Sprite+BattleTreasureInfo。
4，特效：僅擁有Sprite。

除此之外，數據驅動的另外一個核心是在于邏輯流程的處理，在這一環上，我在上一帖中也討論過了關于這種回合制游戲的設計思路，那么在這個游戲中，我們又需要那些“動作”來支持“服務器”到“客戶端”的交流呢？從策劃角度的歸納應該是：

1，移動一個角色：參數：角色uid，目標坐標、指定時間。把一個角色從當前位置移動到目標坐標，在指定時間內完成。

2，角色做動作：參數：角色uid，動作id，是否循環。讓一個角色做指定的id的動作（在這個游戲中包括了站立、跑步、受傷、慶祝、死亡、攻擊6個動作），Play（執行一次后恢復上一個動作）或者Loop（循環播放）。通過角色做動作（跑步）+移動一個角色就可以實現角色在視覺上跑起來的效果。

3，角色說話：參數：角色uid，說話內容。讓一個角色頭上冒出泡泡來說話。

4，殺死一個角色：參數：角色uid，死法。確切的說是移除一個角色，角色的死法是一個enum，決定如何移除掉他，在這個游戲中包括了原地消失和飛起來消失2種，因為死法的處理比較特殊，如果用移動一個角色+殺死一個角色來處理效果未必會很好，所以這里采用了客戶端寫一些特殊處理的邏輯，而這也是典型的需要策劃去衡量到底如何實現的點，從用其他動作組合或者單獨制作中進行抉擇，我選擇了后者。

5，添加一個角色：參數：角色uid，角色外觀，角色位置。把一個角色放置到戰場上。通過殺死一個角色來關閉一個被顯示的地面單元格，通過添加一個角色來顯示一個地面單元格。所以從一開始，我們游戲中就沒有“單元格類”和“角色類”的說法。

6，播放特效于角色：參數：角色uid，特效id，播放次數。之所以獨立出這條，而不像處理單元格一樣處理特效，是因為如果是一個地面的視覺特效，我可以“添加一個角色”，但如果我想讓特效跟隨角色，還是必須把角色的Entity當作Parent來使用，所以我額外增加了這條。

在這個游戲中，其實核心的動作只要有這么6種，然后通過上一篇說的組織方法告訴客戶端之后，客戶端就能順利的重現出一個回合的戰斗來。由于這個游戲每一個回合都要等待玩家的指令，所以它是一回合為一次與客戶端交互的，而不是MT類游戲一場戰斗一次交互的。

下一時代的人會如何開發游戲？

為什么要采用Data Driven來做這樣的游戲？作為一個既得利益主義者，最直接受益的就是可擴展性，你可以看出只要隨便增加一個動作，就能給游戲增加很多很多新的東西出來，同樣的，客戶端也不需要做出很大的調整。而Data Driven的思路，在游戲開發整個過程中的核心好處，就和這個方式被提出來的核心好處是一樣的——人類處理數據的能力遠強于處理邏輯。因此將來我們游戲的一個開發方向就是——讓好的設計師可以通過用自然語言描述來完成一個游戲邏輯層的coding。

你不難看出，假如你在這游戲中，利用我的buff機制開發一個新的buff，可以如何去編寫他的效果，比如說我需要一個buff，每回合持有者都可以恢復50點生命值，播放一個視覺特效。策劃不再需要填寫很長的表單，只需要寫一段中文的dsl——“回合1的倍數開始時：回復自己50點生命，同時播放特效1001號于自己身上1次，之后跳出宋體10號綠色"+50"于自己身上1次。”

GameRes游資網 2015-08-23 08:39:18