爐石傳說山寨的工作一直在進行著,在開發過程中深深體會到,對于業務的理解和整個程序的架構的整理遠比開發難得多。
在開發過程中,如果你的模型不合理,不準確,很有可能造成代碼的混亂,冗余,難以維護和擴展性比較差等問題。
當然,除去領域專家之外,很少人對于一個新的事物可以在一開始就把握住整個核心業務。
接下來講講整個程序的構造:
Card類庫:將整個業務邏輯封裝在里面,包括了服務器和客戶端的通信邏輯。通信協議的編碼和解碼。現在是為了爐石定制的,以后想改寫成更加通用的。
CardHelper:一個輔助程序,例如一些簡單的單元測試,從Excel讀取卡牌信息保存為xml等等
火爐服務器:一個簡單的服務器
爐邊傳說:一個簡單的客戶端
程序最難的部分是理清楚一個客戶端和服務器的通信流程,以及,各個模塊的職責。
1.(本方客戶端)本方使用一張手牌
2.(本方客戶端)GameManager分析這種手牌的作用
3.(本方客戶端)如果需要 抉擇或者需要指定施法對象,則返回UI獲得需要信息(UI和GameManager之間,使用delegate通信)
4.(本方客戶端)使用法術的時候,將法術分解為效果,將法術名稱記錄到使用法術的日志(ActionList)
5.(本方客戶端)法術模塊進行施法動作的邏輯計算,修改本方的對象實例,將法術效果記錄到使用法術的日志(ActionList)
6.(本方客戶端)將法術的日志傳送給服務器
7.(對方客戶端)獲得法術的日志
8,(對方客戶端)通過法術名稱,告訴用戶被使用了法術
9.(對方客戶端)根據法術效果修改本方的對象實例(這里沒有邏輯計算,單純的根據日志修改對象)
從整個游戲流程上說,大概是這個樣子的
整個爐石的核心部分是法術效果
法術的卡牌,隨從的戰吼,亡語等等都可以看做為法術效果。
對于法術的分解,分解為最小單元則是最重要的事情。
例如:奧術飛彈 隨機對目標發動3次攻擊,每次1點傷害
這個法術在分解為原子法術的時候變為 3個原子法術效果
隨機對目標發動1次攻擊,每次1點傷害
每個原子法術的效果實施之后,都必須進行整個戰場的再計算。
下面是整理的法術表格
希望有人幫助我整理資料,一個人力不從心了
不知道有人愿意為我開發客戶端嗎?服務器和核心類庫的開發,我來完成,希望有一個對于客戶端和美工比較在行的朋友,開發一個客戶端。
C#的代碼,可以考慮以后移植到Surface上去,或者通過Mono移植到Liunx去。
考慮到版權問題,可以做成三國主題的卡牌游戲
源代碼:https://github.com/magicdict/MagicMongoDBTool
Card/Card Helper/火爐服務器/爐邊傳說 4個目錄就可以了,其他的是MongoDB的項目源代碼
考慮到以后用MongoDB做日志維護,暫時先放在一起管理了。
新聞熱點
疑難解答