ExcelAndJSON的設計決策

不少人看到ExcelAndJSON的第一反映是，這東西個人公司裏面也有，那麼我爲何用呢？

作爲開發來講，每個工具的存在，都是爲了加快遊戲開發的速度。那麼從無到有，從有到精。有和沒有，好用和很差用的差異，每個都比前一個狀況能提高50%的效率。（按IPD理論，極限速度是提高100%的效率，這裏取保守數字）。

ExcelAndJSON這個工具，前先後後設計思考大約有一年的時間。在以前的開發中，咱們使用大量的相似工具，數量有四五個，若是考慮評估階段的話，是十幾個。

這些工具或多或少都有這樣那樣的問題。而每個問題，都是開發中的一個大坑。下面咱們來看ExcelAndJSON是如何對這些問題提供解決方案的。

1、爲何選擇Python開發？

若是選擇C++，那麼是可使用Qt的。但C++領域，一直沒有好用的開源跨平臺Excel解析庫。要麼是閉源的，要麼是隻支持老格式xls不支持新格式xlsx，還有就是不可以跨平臺。而這些，偏偏都是ExcelAndJSON自己必須具有的特性。手遊開發，決定了必須跨平臺。開源項目決定了依賴庫必須也是開源的。Office的不斷更新，決定了必須支持新格式。因此，C++被淘汰出局。

若是選擇JS，由於個人方向是全棧式，目前來講在Node.js領域，npm中我沒有找到很是好用的Excel解析庫。不少庫都是直接把Excel讀成一個巨型JSON對象，這種寫法是我所不能接受的，太SB了。還有一個緣由在於，考慮將來擴展性，Node.js領域一直沒有好用的UI庫。另外，若是在web開發裏面去找，我我的不是很喜歡BS架構的工具。因此，JS被淘汰出局。

若是選擇Java。Java目前在前端手機遊戲開發領域，已經沒落。在後端，快速開發方向面臨新興方案的衝擊（RoR， Python，Node.js，Go），並且高性能方向又始終幹不過C++。對於各個公司自行修改維護可否找到適合的人，是個問題（前端幾乎沒人作Java，後端可能有人作Java）。因此，Java也被淘汰出局。

若是選擇Python。首先，Python是跨平臺的。其次，Python的學習速度很快，3~5年經驗的人，上手時間頂多3~5天。再次，Python對於文件，文本，命令行處理，支持的很是之好。最後，Python裏面也有方便的圖形化工具，例如Qt就提供了Python版本。

因此，選擇Python。

2、數組的做用

若是沒有數組，那麼在遇到成序列的數據時候，好比設計怪物AI中的技能部分，表的結構就會是相似這個樣子：

length	skill1	skill2	skill3	skill4
4	火球	冰箭	魔法盾	順移
3	突刺	半月	重斬
1	治療

若是你使用過相似這樣的JSON結構，那麼你應該知道，在填寫數據的時候，容易出錯，輸出數據的時候會很難看（不論是填充null做爲空數據，仍是不輸出空白格，都同樣難看。前者存在無用數據，後者丟失了表的結構，形成閱讀困難），遍歷代碼寫起來也很麻煩。

在JSON中，數組天生就能夠得到其「元素個數」，而且能夠方便的遍歷。因此，咱們要在工具層面支持數組，這樣才能使用JSON的這個特性。

3、「引用」該怎麼用？

仍是舉一個例子，在經營建造遊戲中，對於建築物屬性的定義，每一個建築的解鎖等級這是一個固定值，該建築佔用的地塊面積也是一個固定值。可是該建築不一樣等級的屬性，則是徹底不相同的。若是是一個資源產生建築，那麼會有不一樣的資源生成速度和資源上限，若是是一個出兵建築，會有可造兵種類別，出兵時間。若是是一個防護建築，會有***半徑，傷害力等。這些不一樣結構的字段，是沒有可能放到一個二維表中的。

通常採用的方式是，會有幾種方案：

1.會有一個主要的表來存放全部建築包含的相同的字段，而後那些不相同的字段信息放到其餘表中，而後經過主鍵跳轉來訪問。

2.直接拆成多個表來填數據

3.使用一些不一樣的開關字段或分類字段，讓同一個字段在不一樣開關狀態下有不一樣的含義。如今遊戲愈來愈複雜，這是最不建議的一種方式。

上面的3種方案，維護和修改爲本都很高。

採用引用實現就很簡單，仍是多個表，而後在主要表上，插入其餘表的引用便可。

s	i	i	r	r	r
name	unlock_lv	area	lv1	lv2	lv3
基地	1	4	基地.lv1	基地.lv2	基地.lv3
鈾礦	3	4	鈾礦.lv1	鈾礦.lv2	鈾礦.lv3
兵營	5	1	兵營.lv1	兵營.lv2	兵營.lv3

4、主表模式的意義是什麼？

遊戲開發中，先後端對於數據的需求是不同的。前端須要的是一些顯示數據，如資源名稱，動做參數。後端須要的是一些計算數據，好比***力，防護力，傷害公式等。可是有一些數據，是先後端都須要的，好比：技能範圍，技能類型等，這些數據既與前端的顯示有關係也和後端的邏輯計算有關係。

那麼這種狀況下，按照傳統方式，也會拆成若干表。通常是一張表前端用，一張表後端用。但問題在於，先後端都須要的數據該如何處理？在兩個表之間同步是一個成本比較高的辦法。

這就體現出主表模式的意義了。咱們能夠把這些數據都組織在一張表上：

name	type	effect	atk
平砍	1	平砍.png	10
橫掃千軍	3	橫掃千軍.png	7
暴風雪	4	暴風雪.png	8

而後在輸出的時候，在主表模式中，分紅兩個來輸出：

skill->skill_fn	name	type	effect
skill->skill_bn	name	type	atk

最後

需求一直在變，工具要提供的是應對不一樣需求的靈活性。