自負

  老師最初佈置這個作業的時候，我是對此不以為然的，因為自己有一定的Canvas基礎，並且曾經制作過魔獸爭霸3的地圖，對於這種物件-事件觸發的機制也還算熟悉，因此，當時的我認為，利用這樣一個引擎，要仿製一個和坦克大戰一樣的遊戲，應該只需要兩個小時。

  然而事實上，這份作業花費了我超過三個下午的時間，由於不瞭解許多功能，導致許多預期的效果只能通過繁瑣的方法實現，而對於內部執行機制的不瞭解更是雪上加霜，大量的冗餘事件堆滿了事件表，不僅未能實現預期的效果，還極大地拖累了作品的執行速度。

  在整個作品的製作過程中，這種可怕的狂妄自大幾乎是致命的，它使得我沒有認真閱讀過Construct2的文件便開始工作，這使得我的製作一度陷入巨大的困境。

困境

  最初我的設想是：由於坦克、磚塊、基地是正方形的，那麼就可以將地圖表示為一個m*n的二維陣列，陣列的位置對應物件在地圖上的對應位置，陣列的內容為該位置的物件型別（磚塊、坦克、森林、基地），然後再根據陣列與地圖的對應關係，將單位渲染到地圖上。並依據這個陣列中的資訊，進行坦克的移動，擊毀等判定。

  這個想法看上去有點像Canvas中的繪製：先決定好顏色、線段等資訊，再進行填充或者繪製。看上去這似乎有利於我進行各種判定，但事實上這種想法卻略顯多餘：許多用Construct2製作遊戲的人都知道，地圖資訊可以通過位置選擇、碰撞判定、視野判定等多種方法獲得。更何況，坦克在移動過程中的位置不可能總是恰好對應到陣列上，在這種情況下，陣列的很多計算無法正常進行。

  但這並不是主要的麻煩，更主要的麻煩是：利用陣列進行的多種計算忽略了引擎本身就具有的功能，導致需要大量的事件，但如果不採用這些方法，陣列所帶來的計算上的直觀性的優勢就會蕩然無存（事實上，如果採用了引擎自帶的功能，在陣列上進行的大多數計算是沒有任何必要的）。

  但大量的事件在很多情況下會帶來諸多麻煩：一是和龐大的程式碼一樣，大量的事件使得遊戲本身極難易維護；二是老師推薦使用Construct2社群版，並且我也不希望為一份作業付費，而社群版只允許使用100個事件，這是我後來放棄地圖陣列這一想法的最主要原因。

重構

  在浪費了很長一段時間在大量事件中的掙扎過後，我找到了Scirr a上的手冊，在進行粗略的閱讀過後，我又去看了幾份自帶的樣例，我選擇放棄最初的想法，使用了另一個方案：

• 首先，在判定碰撞方面，給磚塊和坦克新增Solid行為，避免一些了莫名其妙的動畫重疊。
• 在地圖生成上，放棄使用並查集判斷隨機生成的地圖的連通性，轉而使用PathFinding行為進行計算，從而進行判定。
• ……

  這個方案被驗證為是行之有效的，因為它將我的事件表簡化到了只有70個左右的事件，並且在實現效果上不亞於原本的上百個事件。

反思

  這次的作業讓我重新反思了之前的許多觀點：比如使用輪子一定比沒使用輪子來得好，或者是軟體的說明書和樣例不如直接Google方便等，這些觀點曾經影響了我很長一段時間，而我竟對此帶來的不便渾然不覺。

  這次的作業給我帶來的觸動非常深刻，它讓我重新反思了過去的作為，並總結出了以下的經驗：

• 在使用一種工具之前，要先瀏覽該工具的文件和案例，避免重複造輪子。
• 在嘗試使用一種功能之前，要先檢視該功能的詳細說明，不可輕信搜尋引擎帶來的結果，這極有可能是你陷入某種困境。
• 不要總是使用以往的觀點看待某樣工具，每個工具都有其設計者的思想包含在其中，先理解這些思想，再進行設計，會為你帶來眾多設計上的便利，反之，則會使你的構想的實現輯為複雜。