魔王堡壘筆記

http://beast.godfat.org/forums/3/topics/24#posts-55

1.
敵人不做 collision, 考量如下：
collision detect 一向非常吃資源，就算是最單純的作法，
或是隔一段時間才 detect 一次，一樣非常吃資源。
在 flash 執行能力並不強，且單位量可能很多的時候，
做 collision detect 很可能會嚴重拖慢執行效能。

而更重要的是，enemy collision 對 tower defense 有什麼好處？
假使敵人會碰撞卡住，那麼使用 slow 甚至是 stun 的效果是否會太驚人？
除此之外，敵人會有停下來的時候嗎？答案當然是否，
所以 collision 對於 tower defense 其實是有點雞肋的。

所以不做。

2.
地圖上需要存哪些資料？敵人資料？塔的資料？
塔的資料是一定得存的，而且還需要反向查詢，
所以塔本身也要記錄自己的座標。
但是敵人呢？假設要存好了，那麼應該分開還是合併？
合併省記憶體，但我認為分開比較好。
一來這樣可以簡化流程，二來敵人是否需要記錄，
還需要再商榷。如果確定不要了，合併之下會不好移除。
而 flash 當然是 CPU 資源遠比 RAM 資源重要得多。

敵人其實應該是不用記錄的，因為需要查詢敵人的狀況並不多。
像是查詢敵人資料，這個可以做在敵人的 mouse click event 上，
沒有 collision detect, 記錄到地圖上的意義也沒有太多。
但還是有一個狀況需要查詢敵人位置，就是你的塔不能蓋在他身上。
這點可以在你按下去的那瞬間，直接用座標反查就好了。
畢竟玩家並不會瘋狂測試有敵人的地方能不能蓋塔，
省下所有一般情況下的運算能力比較重要。
畢竟，敵人記錄座標其實也是很費資源的，試想，進入和離開
區塊都是需要偵測的，那幾乎是無時無刻都要計算了。

3.
blocking algorithm 可以用 depth first search 就解決了，不是問題。
按下去的瞬間再做就好。

4.
敵人的 path finding alogrithm, 每一秒做一次即可。
也就是敵人每秒鐘做一次路徑修正。不過會不會因此撞上塔？
這點可能要再看看，是否要縮短路徑修正的時間，
或是撞上後立刻修正自己的位置，或是路徑修正和塔的碰撞分開做。
至於敵人的路徑搜尋，depth first search 不能找到最短路徑，
A* 怕太吃執行資源，這點要再看看。理想上當然是用 A*

5.
武器與敵人的碰撞？應該要用座標算，這部份還需要再考慮，
肯定也會是個效能瓶頸。複雜度似乎是 N*M, 如果效能太差
也許必須考慮讓計算變得粗糙或是直接減少敵人或子彈的數量。