游戲邏輯系統(tǒng)化

1.游戲邏輯的目的
實(shí)現(xiàn)策劃的設(shè)計(jì)文檔

構(gòu)建游戲系統(tǒng)

構(gòu)建游戲玩法

2.什么是游戲邏輯
游戲邏輯是作為一個(gè)游戲項(xiàng)目里面最為復(fù)雜的系統(tǒng)之一，需要編寫者在一開始的時(shí)候就盡可能的通過經(jīng)驗(yàn)來構(gòu)建一個(gè)比較完善并且擴(kuò)展性強(qiáng)的邏輯架構(gòu)，然后隨后不斷的進(jìn)行迭代改進(jìn)，完善整個(gè)系統(tǒng)。

3.游戲邏輯的作用
如果一款游戲?qū)π阅苡泻車?yán)格的要求，對應(yīng)的游戲邏輯就必須要滿足良好的運(yùn)行性能需求，不能崩潰，有很好的拓展性，但是由于初學(xué)者時(shí)間周期緊張和基礎(chǔ)的不扎實(shí)，所以不太會(huì)花過多的時(shí)間考慮架構(gòu)與設(shè)計(jì)。

    一個(gè)游戲根據(jù)功能可以劃分為多個(gè)不同的模塊，如金錢、背包、裝備、技能、任務(wù)、成就等。按照軟件工程的思想，我們希望分而治之單獨(dú)實(shí)現(xiàn)不同的模塊，再將這些模塊組合在一起成為一份完整的游戲。但現(xiàn)實(shí)是殘酷的，不同模塊之間往往有千絲萬縷的聯(lián)系，比如購買背包物品會(huì)需要扣金幣、打一個(gè)副本會(huì)完成任務(wù)，完成任務(wù)又會(huì)獎(jiǎng)勵(lì)金幣和物品，金幣的增加又導(dǎo)致一個(gè)成就達(dá)成。于是我們雖然在不同的類或不同的文件中來實(shí)現(xiàn)各個(gè)模塊，卻免不了模塊間的交叉引用和互相調(diào)用，最后混雜不堪，任何一點(diǎn)小修改都可以導(dǎo)致牽一發(fā)而動(dòng)全身。

    為了后面說明方便，我們考慮這樣一個(gè)小型游戲系統(tǒng)：總共有3個(gè)模塊，分別是金錢、背包、任務(wù)。購買背包物品需要消耗金幣，賣出背包物品可得到金幣，金幣增加到一定數(shù)額后會(huì)導(dǎo)致某個(gè)任務(wù)的狀態(tài)變?yōu)橥瓿?，完成任?wù)可獲得物品和金幣。這3個(gè)模塊的調(diào)用關(guān)系如圖。








    首先我們把模塊的數(shù)據(jù)和邏輯分離，借鑒經(jīng)典的MVC模式，數(shù)據(jù)部分叫作Model，邏輯部分叫作Controller。如此一來，游戲功能部分就被劃分出來了兩個(gè)不同的層次，Controller處于較高的層次上，可以引用一個(gè)或者多個(gè)Model。Model層專心處理數(shù)據(jù)，對上層無感知。每個(gè)Model都是完全獨(dú)立的模塊，不引用任何Controller或Model，不依賴于其他任何對象，可以單拿出來進(jìn)行單元測試。

對于我們的例子，每個(gè)模塊提供的接口列舉如下：
BagModel：獲取物品數(shù)量，增加物品，扣除物品
MoneyModel：獲取金幣數(shù)量，增加金幣，扣除金幣
TaskModel：增加任務(wù)，刪除任務(wù)，標(biāo)記任務(wù)為完成
BagController：購買物品，賣出物品
TaskController：完成任務(wù)

    購買或賣出物品時(shí)，由BagController進(jìn)行或操作校驗(yàn)，隨后調(diào)用BagModel和MoneyModel完成數(shù)據(jù)修改。完成任務(wù)時(shí)，由TaskController調(diào)用各個(gè)模塊。

    現(xiàn)在唯一的問題是，既然MoneyModel不引用其他模塊，那么在金幣增加時(shí)如何告知任務(wù)模塊去完成任務(wù)呢？這里我們需要引入一個(gè)管理依賴的利器：觀察者模式。

    具體使用方式是把Model實(shí)現(xiàn)為一個(gè)Subject，對某個(gè)Model的數(shù)據(jù)變化感興趣的Controller實(shí)現(xiàn)為對應(yīng)的Observer。我們的例子中，MoneyModel是Subject，在金幣數(shù)量變化時(shí)通知所有已注冊的Observer；TaskController是MoneyModel的一個(gè)Observer，在初始化時(shí)向MoneyModel注冊。






    注意圖中由MoneyModel指向TaskController的虛線箭頭，代表MoneyModel數(shù)據(jù)變化時(shí)會(huì)去通知TaskController，用虛線是因?yàn)镸oneyModel并不依賴于TaskController（只依賴于Observer接口）。同樣BagModel也可以提供背包物品變化的Subject，如果新加一個(gè)任務(wù)是要求某物品的數(shù)量達(dá)某個(gè)值，那么TaskController可向BagModel注冊，這樣在物品變化時(shí)就能得到通知了，圖中也畫出了這條虛線。


    對觀察者模式不熟悉的讀者朋友可以自行查閱資料， 本文的重點(diǎn)并不是介紹設(shè)計(jì)模式。這里簡單提示一下觀察者模式的精髓：當(dāng)某模塊調(diào)用其他模塊時(shí)就產(chǎn)生了依賴，這時(shí)可以不直接去調(diào)用，而是轉(zhuǎn)而實(shí)現(xiàn)一個(gè)機(jī)制，這個(gè)機(jī)制就是讓其他模塊告訴自己他們需要被調(diào)用。最后調(diào)用的流程沒變，變化的是依賴關(guān)系。

    在客戶端情況要更復(fù)雜一些，實(shí)際上加入U(xiǎn)I后，我們的模塊設(shè)計(jì)就成經(jīng)典的MVC，這也是我們?yōu)槭裁窗褦?shù)據(jù)模塊和邏輯模塊分別叫Model和Controller的原因。






    這里只畫出了背包模塊。這里的System API指與游戲運(yùn)行平臺相關(guān)的一些接口，可能是操作系統(tǒng)API、引擎API、圖形庫API等等。View模塊和Model模塊地位相當(dāng)，只處理顯示而不管游戲功能，需要顯示的數(shù)據(jù)都是由Controller提供的。對于能輸入的View同樣采用觀察者模式，點(diǎn)擊等事件發(fā)生時(shí)通知其他模塊（而不是直接調(diào)用），注意圖中由BagView指向BagController的虛線箭頭。