iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 9
0
自我挑戰組

卡牌遊戲開發日記v2020系列 第 9

Day9 再談資料封裝(介面)

說明在多人連線遊戲的情況下,內部資料要如何保護?最後講個屬性(property)的概念

今天跳下去寫扣,寫著寫著腦袋又開始打結了。於是暫停整理了一下自己的思緒。

原本玩家物件(Player)
成員:牌庫、手牌、棄牌
方法:出牌、抽牌、抽加棄牌

玩家狀態物件(PlayerStat)
成員:生命值、防護罩、牌庫、手牌
方法:扣血、治癒、建立護盾、扣護盾、封印、防禦、反震、空城、目眩(承受光芒)、抽掉卡片(混沌效果)、牌庫加牌(混沌效果)、展示手牌(光芒、混沌效果)

這時候開始發現玩家物件和玩家狀態物件功能越來越接近,所以打算把這兩個物件合併成一個。

另外因為玩家照理說不應該具備主動控制數值的方法(玩家幫自己加血),所以任何可以改變玩家狀態的方法都應該被封裝為系統內部方法。那時候意識到玩家物件必須限制它可用的方法,於是就必須區分成以下:

  • 給玩家使用的API介面
  • 系統接收玩家API呼叫的介面
  • 系統的API實作內容

然後又延伸一個問題:玩家不應該知道自己的牌庫內容。在思考相關問題的時候,意識到資料有三種層級:

  • 公開資訊:場面狀態
  • 個人資訊:玩家手牌內容、蓋牌內容
  • 系統資訊:牌庫內容

然後因為遊戲是多人連線的形式,所以玩家這邊不會擁有遊戲的內部運作邏輯。於是思考資料拆分、介面&實作分離的方式要怎麼弄?因為程式寫一寫就會莫名其妙變成單機遊戲的思考方式,還好自己有想到這部份的問題

昨天有講到陣營共用資料的部份,這在四人對戰的時候一定會遇到,因為血量是按照陣營區分的。所以在底層實作中,血量訊息會被放在陣營層級的物件中被存取。這部分還沒想的很清楚,但大概在執行扣血的時候,會根據玩家ID轉換成對應的陣營ID,然後扣陣營的HP。老實說,想這部分有點頭痛

後面稍微復習了一下屬性property的概念,這是因為資料封裝而跑出來的概念
property表面上看起來很像是物件的成員,但是它其實是偽裝的函數呼叫

因為一般物件成員被封裝後,只能透過getter和setter去存取
原本的寫法:obj.x = obj.x+1
封裝後:obj.setXX(obj.getXXX()+1)
為了繼續保有原本存取成員的便利語法,同時又具備資料封裝的功能,property就被發明出來了。

實際語法就不貼了,看良葛格寫的說明文件吧。

以上為今天的進度,繼續加油吧!


上一篇
Day8 場面資訊封裝
下一篇
Day10 實作:玩家資料的封裝
系列文
卡牌遊戲開發日記v202030

尚未有邦友留言

立即登入留言