爐石傳說的開發，已經有30個工作日了。
關於法術的定義方法，有過一次重大的變更：法術效果是整個爐石的核心，正是因為豐富的法術效果，才造就了爐石的可玩性。
原來構思的時候，對於法術效果沒有充分的理解，所以只將效果數據做成了常數，例如 造成5點傷害。
隨着更加深入的解除，發現還有 毀掉你的武器，對所有隨從造成武器攻擊力的傷害，這樣的話，效果是一個 表達式。
然后考慮到，有些追加效果，例如，對某個隨從造成2點傷害，如果這個隨從沒有死，則抽一張牌，
這里就牽涉到了根據條件追加效果的處理。
同時，德魯伊的抉擇系列，有的是主動讓用戶選擇效果，有的是根據戰場形勢自動計算使用效果，這些也是原本沒有考慮到的。
經過權衡之后，將數據定義表格進行了重構。
（舊的法術定義）
（新的法術定義）
新的表格對於法術的定義更加詳細具體，每個種類的法術都有自己不同的字段。
同時在法術的使用流程上，也加入了更多的思考，並且將這種思考落於設計書。先進行了設計，然后將成熟的設計轉化成代碼。
對於爐石這樣流程復雜，規則詭異的東西，一定要徹底做好設計！！設計的時候發現問題，修改成本是1，開發的時候修改成本是10，測試的時候修改成本是100
接下來的一段時間，大概截止到6月底，將是做單體測試的時間。將整個架構進行必要重構后就要進行測試了。
對於代碼的重構，包括對於名字空間和代碼目錄的重構，花了一些時間整理了名字空間和代碼結構，讓正確的代碼文件放在爭取的地方。
讓正確的方法出現在正確的類里面。Engine是總的空間名稱，下面有Card，Effect，Client，Server等子空間。
爐石的測試，最難的就是對於結算的測試和規則的測試。平心而論，爐石的結算規則還是非常模糊的。
1.如果奧術飛彈的第一發將一個隨從打死了，隨從的亡語是召喚一個隨從，那么，這個時候進行召喚操作嗎？召喚出來的隨從也是奧術飛彈的目標嗎？
如果是的話，每一個奧術飛彈的結果都要結算，如果不是的話，3發結束后進行結算。
如果是全體型的烈焰風暴呢？
肯定是對所有隨從造成傷害后再一次性結算了。
2. 叫囂的中士
如果場上沒有其他隨從，有時候這張牌是不能上場的？iPad的時候，以前的版本一定會讓你選擇一個施法對象。
3.如果帶有召喚戰吼的隨從入場，遇上滿員的時候，該怎么處理呢？
爐石的很多規則不是很清晰，所以開發的時候，可能需要做兩手准備，或者能讓用戶自定義，讓這個項目的核心更接近於一個引擎，而不是一個爐石定制的東西。