爐石傳說山寨的工作一直在進行著，在開發過程中深深體會到，對于業務的理解和整個程序的架構的整理遠比開發難得多。

在開發過程中，如果你的模型不合理，不準確，很有可能造成代碼的混亂，冗余，難以維護和擴展性比較差等問題。

當然，除去領域專家之外，很少人對于一個新的事物可以在一開始就把握住整個核心業務。

接下來講講整個程序的構造：

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做日志維護，暫時先放在一起管理了。