上一次我們已經完成了玩家端的部署，接下來就是要有敵人囉。和「Plant vs Zombies」相同，敵人也是分五道過來，不一定會先從哪一道過來，也不一定都會是哪一種敵人會過來。這次的主題就是設計一個簡單的敵人，並亂數的配置它們從不同的方向過來。
最簡單的敵人
這個遊戲叫「Turret vs Tank」，所以我們當然是搜尋看看有哪些「Tank」可以用囉。在「1-CREATE/OBJECTS FROM WEB/」搜尋「Tank」，正好看到一個不錯的最弱的車可以用：
這台疣豬式衝鋒車，我們沒打算讓它有什麼特殊能力，出來之後就是往前衝，想辦法撞毀玩家的單位(砲台或電腦)，甚至是寶箱。簡述一下它需要的規格就像這樣：
- 只有3點血(可因應平衡性調整)
- 被玩家砲彈打到時會閃紅光，血量歸零時就自爆離場(不會造成損傷)。
- 只會向前直行
- 撞到玩家單位會造成1點損傷，然後自己自爆。
上述的規格中，「只會向前直行」應該沒什麼問題，就是來一張「MOVEMENT」面板就可以，而「被玩家砲彈打到會閃紅光…」這個規格，就是用「HEALTH」這個面板來解決：
它死掉的時候，為了方便，我們就直接來個「Explode」卡吧，但要記得去把「Damage」設為0，不然就會連帶傷害到其他人：
最後就是「撞到玩家單位會造成1點損傷，然後自己自爆」這個規格。很容易理解的是透過「IF-THEN」面板，搭配「Collision Event」來做：
這裡需要注意的重點是”玩家單位”這件事。玩家在運行期可能會生成好幾個呼叫器(supplyer unit)或是迷你砲台(mini turret unit)，我們又要怎麼指定它們是”玩家單位”呢？
在這裡我們就要使用「Tag」的屬性來做，打開「Collision Event」，我們點開「Collide with what」，就會看到這些選項：
這幾個項目是這樣的：
- Any actor：任何一個碰到的物件。
- Player：帶有「Player」tag的物件。
- Actors with tag...：帶有指定tag的物件。
- Specific actor...：直接選擇指定的物件。
- Nothing：沒碰到任何物件。
我們將會用到的是「Actors with tag...」，然後把tag設定成「Player」：
若我們今天選擇的是「Player」這個tag，其實就跟「Collide with what」選項中的「Player」是同義的，算是一個小技巧。這邊選完了，接下來比較重要的，就是要把我們打算讓疣豬車破壞的單位，都要加上「Player」的tag，就像supplyer_unit：
或是「mini_turret_unit」：
我目前Workshop的版本是把supplyer_crate也加了「player」tag，這個就看大家需求囉。若設定一切順利，目前的進度看起來應該就像這樣：
在我Workshop的專案中，我還做了一個「Tank」敵人。在這個框架下設計流程和「WartHog」就差不多：怎麼移動，怎麼攻擊，怎麼挨打，怎麼死，最後把它OffStage去…差不多就這些事，這邊就不再特別說囉。
亂數決定出生點
GameBuilder一直有一點很奇怪的設計：沒有「亂數」這種卡片。雖在WorkShop有人做了「Random」這樣的卡片，但我忠於一個「不寫程式」的前提下，為大家介紹怎麼做出亂數的規格。
「不寫程式」這件事我似乎一直都沒特別強調。主要的想法是，若使用這樣的工具還要靠寫code來擴充功能，那我乾脆就直接用Unreal開發就好了，功能更強，還不一定真的需要寫到code。
好，那回題。究竟要怎麼”亂數決定出生點”，根本就沒有「亂數」呀？在目前為止的GameBuilder，我們唯一有的「亂數」，就是「隨意逛逛(Wander Around)」這張牌：
所以，我們的「亂數決定出生點」就是：擺一隻隨意逛逛的史萊姆，看到碰到哪一個物件，就決定等等下一個敵人要從哪一道出生。
概念成形之後，我就在最右邊佈置好一些「出生點」，用來讓敵軍出生，然後在場景中找一個地方，佈置好讓史萊姆隨意逛逛的空間，也佈置好5個不同的出生點：
大致上就是這樣，我在左下角畫了塊空間，擺了5個「Collectable Hologram」物件，這對應到右邊的5個敵人出生點。當中間的史萊姆隨意逛逛時，它有可能會碰觸到任何一個Hologram，就可以對應到不同的敵人出生點囉！敵人出生點物件我這邊就命名為「enemy_creator」系列(其他4個物件是複製品，就照GameBuilder自動配置的名字就行了)，而史萊姆碰觸到的那5個Hologram就命名為「enemy_spawn_portal」，也是一樣有4個複製品，GameBuilder自動配名。
中間那隻史萊姆就是重點了，我們放進去後，大致上會需要這樣的卡片配置：
這裡會需要5個不同的「IF-THEN」面板，每一個都是一個「Collision Event」配一個「Change Variable」。「Collision Event」的內容，就是不同的「enemy_spawn_portal」如何對應到不同的「enemy_creator」的關係，也就是這樣：
- 第1個「IF-THEN」的「Collision Event」是判斷是否碰到「enemy_spawn_portal」。
- 第2個「IF-THEN」的「Collision Event」是判斷是否碰到「enemy_spawn_portal-2」。
- 第3個「IF-THEN」的「Collision Event」是判斷是否碰到「enemy_spawn_portal-3」。
- …(依此類推)…
那下面的「ChangeVariable」呢？為何不是開始生成敵人呢？因為我們會有2種以上的敵人，又有5個不同的位置，那豈不是要有10種「IF-THEN」？這裡有一個遊戲開發上很常見也很重要的觀念：
要把規格「單元化」，用組合來完成規格，而不是一口氣包山包海的做完，以免失去修改的彈性及擴充性。
所以，我們的「ChangeVariable」就是只做這件事：
也就是說，史萊姆的角色只決定下一個敵人要去哪個位置出生，其他什麼事都不用做。
預設的「Wander Around」可能會讓你覺得速度有點太慢，卡片裡有一些參數可以調整。如果你想要某個位置”比較”容易出生敵人，你也可以把特定的「enemy_spawn_portal」弄得大一點，等於它的機率就會大一點。大致上目前設定的結果，就會如下面影片展示的那樣(蝸牛那邊先不用理它，下一段會說)：
亂數生成敵人
既然我們可以亂數找位置生成了，那要亂數生成不同的敵人當然就可以如法泡製。所以我們也一樣再找一塊地方，這次放一隻蝸牛，來決定要生成哪一種敵人吧。
如上圖，目前我們有兩種敵人，所以就擺個大家機率差不多的位置就行了。 重點也是在蝸牛身上。
在講蝸牛之前，我們倒是應該先決定那5個「enemy_creator」要怎麼生敵人出來。這裡當然還是運用了之前tutorial就介紹過的技巧「ReceiveMessage」。也就是說若它聽到「warthog」就生疣豬車，若聽到「tank」就生坦克。和之前說的原則一樣，它們就別管「亂數」這件事了，「亂數」讓蝸牛來解決。
好，回到蝸牛。它要正式生成敵人，條件就都到齊了：
這個「IF-THEN」面板是處理最終要在哪裡，生成哪一種敵人最終的組合處理，所以會有2種敵人 x 5個出生點 = 10個「IF-THEN」面板，
「Collision Event」很單純，就是疣豬車跟坦克兩種而已。而「Variable Is...」則是要判斷剛剛的史萊姆身上的「portal」變數，現在是1~5的哪一個值。最後的「Send Message」才能決定要給哪一個「enemy_creator」送message，寫成文字是這樣的：
- 若碰到「warthog」，且史萊姆身上的「portal」是1的話，就給「enemy_creator」送”warthog”訊息。
- 若碰到「warthog」，且史萊姆身上的「portal」是2的話，就給「enemy_creator-1」送”warthog”訊息。
- 若碰到「warthog」，且史萊姆身上的「portal」是3的話，就給「enemy_creator-2」送”warthog”訊息。
- 若碰到「tank」，且史萊姆身上的「portal」是1的話，就給「enemy_creator」送”tank”訊息。
- 若碰到「tank」，且史萊姆身上的「portal」是2的話，就給「enemy_creator-1」送”tank”訊息。
- 若碰到「tank」，且史萊姆身上的「portal」是3的話，就給「enemy_creator-2」送”tank”訊息。
- ...(其他依此類推)...
由於面板和所需卡片都是一樣的，只是屬性值不同，所以在編輯上有一個小技巧一定要知道：按著Alt鍵點擊面板時，可複製面板出來哦！這樣就會比較方便了：
大致上亂數生成敵人的說明就到此為止了。為了增加一些難度的設定(不要一開始就random到坦克…玩家一定守不住)，我又加了一些敵方單位的”價格”設定。蝸牛會一直存錢，但有可能會馬上花掉買疣豬車，也有可能會存夠錢買到坦克。這些都是變數的操作可以完成的事情，這邊我也就不特別說明了。
以下的影片是我目前在WorkShop的成果。當然，這確實會需要經過不少數值調整，才不會難度偏高或偏低，不過這和GameBuilder的使用教學沒直接關係，所以就跳過了：
結論
經過這個遊戲的實作，我必須很遺憾地說，這個工具還有很多可以改善空間，即使是拿來當作prototype的製作工具。
主要的問題當然是在功能上的不足(例如沒有「亂數」，這種事情真的很難理解…)，操作順暢度只能算是及格。官方把不少心力投注在API的功能擴充上，我個人認為是方向完全錯誤的。如同我之前提到的，我若真的要寫code的話，再怎麼選也是學Unity，也絕對輪不到GameBuilder。
這個專題目前就到此為止了，沒有意外的話我應該是不會再寫了，除非下次大改版，改到我覺得值得再回頭來玩玩，屆時才會再回來寫囉。
