爐石傳說山寨的工作一直在進行着，在開發過程中深深體會到，對於業務的理解和整個程序的架構的整理遠比開發難得多。
在開發過程中，如果你的模型不合理，不准確，很有可能造成代碼的混亂，冗余，難以維護和擴展性比較差等問題。
當然，除去領域專家之外，很少人對於一個新的事物可以在一開始就把握住整個核心業務。
接下來講講整個程序的構造：
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做日志維護，暫時先放在一起管理了。