各位好，我和我的伙伴（樂風創意視覺）是來自台灣的獨立遊戲開發者。我們的團隊有四位核心成員，我是其中唯一的程式設計者。最近我們在蘋果的 App Store 上釋出了我們開發的第一款遊戲《Bonnie’s Brunch》，是一款屬於模擬與策略類型的食物製作遊戲。

自《Bonnie’s Brunch》上市以來，已經過兩個月左右，現在我想要以「事後分析」文章的形式，分享一些我們目前獲得的經驗及想法，期望對有志於進行遊戲開發的人有些許助益。

若您未玩過或不熟悉《Bonnie’s Brunch》的話，建議先看看這篇簡短的介紹文章，會比較易於理解後續的遊戲開發分析內文。

（本文首發於 Inside）

我們做對的事

1. 令人愉快的視覺設計

在我先前的遊戲業界經驗裡，我發現許多人，特別是工程師，會將美術設計師視為一種「可取代的資源」，可以輕易地外包出去，或是以合約方式進行工作。但我堅信任何一位能力出色的美術設計師，其貢獻價值絕對不會少於傑出的工程師或設計師。

在開發過程中，我們在視覺設計上花費了大把的功夫，以確認我們的遊戲擁有非常棒的美術品質，讓每個人看到遊戲畫面時，都會覺得眼睛一亮。我們的目標是製作出具有獨特風格的美術視覺，不僅能吸引台灣的玩家，也同樣能夠吸引世界各地的玩家。

由於在《Bonnie’s Brunch》中有 10 種不同類型的客人，我們決定花費更多的精力在角色設計上。以其中的一名角色「流浪漢」為例，他的出現會導致明顯的負面效應；不僅其他客人會被他的壞味道影響而減少等候餐點的耐心值，而且在給予他餐點之後，他也不會給玩家額外的小費。為了讓這個角色吸引玩家的目光且討喜，我們經歷了數次的修改與調整，才讓他看起來惹人憐愛。

結果證明，我們在美術視覺上的努力確實獲得了玩家們的讚賞。許多玩家以為《Bonnie’s Brunch》是一款來自國外遊戲開發者製作的高品質遊戲，我們認為這點對於遊戲的推廣來說，應該是一個很不錯的正向徵兆。

2. 使用 Lua 撰寫的組件式架構

談到程式設計，我完全是個 Lua 語言的愛好者。《Bonnie’s Brunch》是我以 Lua 程式碼為主撰寫的第二款商業遊戲。在這款遊戲中，我使用了三種程式語言，調合比例分別是 60% 的 Lua、30% 的 C++，以及 10% 的 Objective-C 語言。C++ 主要用來處理圖像繪製與資源管理的任務，而所有的遊戲邏輯程式碼皆為 Lua 所寫。

幾年以前，在我讀完幾篇關於「組件式架構」的文章後，我清楚地意識到這是一個比「繼承架構」更好的程式設計架構，於是我就開始使用 C# 語言撰寫此架構。然而，直到我開始使用 Lua 時，才真正地發揮了組件式架構的優點。

使用 Lua 實做組件式計架構，給予了我相當大幅度的程式設計彈性，目前我已實做出數個常用的遊戲組件，例如：Transform、Sprite、Motion、State Machine 等等。

每一個遊戲物件均由一到多個遊戲組件所構成，且每一個遊戲組件打從一出生就得以被重複使用。當我需要額外的遊戲功能時，我只需要創建出一個新的遊戲組件，而非產生一個繼承自上古時代父類別的子孫類別。乾淨，俐落。

一旦組件式架構完成後，我可以在幾小時內迅速地做出各種遊戲玩法的雛形。在《Bonnie’s Brunch》的早期開發中，我們只有一些靜態的草圖以及許多的顏色色塊用來代表遊戲中的各種物件。儘管此時遊戲的外觀看起來其貌不揚，但「組件式架構」確實幫助我們一開始就集中火力在核心的遊戲性設計層面上。

3. 額外的磨亮時間

我們的開發時程原先預期會在三個月之內結束，最終我們投入了整整六個月的時間完成它。在第三個月結束時，我們幾乎已完成了所有的遊戲功能，但大家都清楚還有很長的路要走。我們必須決定是否要急促地釋出遊戲，或是咬緊牙關、拉緊腰帶投入更多時間精力，讓遊戲發出光芒。

像 Noel Llopis 說過的：「好東西需要時間醞釀。」我們的團隊成員都同意我們需要更多的時間來磨光擦亮《Bonnie’s Brunch》，使它從一款平庸的遊戲，搖身一變成為一款好遊戲，甚至是一款優秀的遊戲。最終為了產出高品質的遊戲作品，我們加倍了開發時間以及開發預算。

舉個例子來說，在某些遊戲測試的過程中，我們發現有些玩家在完成十幾個關卡後，無可避免地會對近乎相同的遊戲玩法感到疲乏。因此，我們決定從原有的遊戲玩法中，衍生出某種特殊的關卡類型，以讓玩家們保持對遊戲的興趣。

為了提升這些特殊關卡的節奏，我們讓所有的客人一一排隊按照順序點餐。玩家們必須盡可能迅速地移動手指完成餐點，看他們能夠在有限的時間內服務多少位客人。此外，我們也在這些關卡中安排了十分緊湊的背景音樂，藉以進一步刺激玩家們的遊戲情緒。

4. 強力的台灣首發成績

在《Bonnie’s Brunch》正式上市後，我們立即藉由 Facebook、Twitter、Plurk 與電子郵件通知我們所有的親朋好友。我們的家人與朋友給予了我們巨大的支持，不僅馬上購買遊戲，也主動將遊戲推薦給其他朋友，幫助我們在台灣的遊戲 App 市場中建立了一個強而有力的基礎。

一開始，我們的遊戲空降在 iPhone 付費遊戲排行榜第 30 名的位置，然後我們開始看著它瘋狂地向上攀升。非常幸運地，在上市後的第三天，我們擊敗了《Angry Birds》，並榮登台灣 iPhone 付費遊戲排行榜的第一名寶座！在台灣的成績表現，也大幅提升了我們在香港、印尼、泰國、馬來西亞以及新加坡等地的排名。

由於《Bonnie’s Brunch》的出色成績，我們在短期內接受了一家報紙、兩家電視新聞，以及數家遊戲網站的採訪，報導的標題就像是：「短短三天之內，《邦妮的早午餐》擊敗了《憤怒鳥》登上第一名！」真是不得了的恭維與讚美哩。

許多人對於我們遊戲的首發佳績感到十分驚訝，也很好奇我們是如何做到的。事實上，我們在市場行銷層面上，並沒有做出什麼特立獨行的舉動。在此我們學到的一課，是「讓遊戲自己說話」，並使人們打從心裡願意分享它。

我們做錯的事

1. 笨拙的食物機器介面

我們從玩家們的回饋意見中，所得到關於遊戲的最大抱怨，就是關於製作食物機器的操作使用。

遊戲裡除了點擊後即刻完成的餐點，像是貝果與飲料之外，另有三大種類的食物製作機器：鬆餅、吐司與煎鍋機器；在這些食物準備妥當並可將食物遞送給客人之前，需要花費幾秒鐘的時間等待。畢竟我們都清楚烘烤鬆餅需要時間，不是嗎？

在《Bonnie’s Brunch》中，要烤個鬆餅，你必須先點擊「鬆餅機」，然後它會跳出一個介面，你必須在這個介面中選擇你所想要製作的鬆餅類型。接著你可以點擊介面之外的區域以關閉它，先去做其他事情。幾秒鐘後，當鬆餅烤好了，你必須再點擊一次鬆餅機打開它的介面，然後選擇剛烤好的鬆餅，選擇後它就會自動關閉鬆餅機器的介面。

在設計這些需耗費時間的食物機器時，我們非常努力地試圖平衡遊戲設計的「多樣性」與「直覺性」。為了提供寬廣多樣的食物材料組合（圓形鬆餅、方形鬆餅等等），我們做了個困難的決定，就是使用彈出式的介面做為這些食物機器的操作方式。

身為遊戲開發者，我們瞭解我們應當不惜一切代價，使機器的操作方式比現在的作法更簡單直覺。為了達到多樣性，我們犧牲了易用性 (Accessibility)。我原先認為這是一種不得不這樣做的取捨，但它顯然並非如此。易用性，永遠該放在我們的第一優先順序上。

2. 缺乏長期的遊戲目標

在遊戲設計階段中，我們幾乎沒有考慮過任何「超遊戲」(Meta-Game) 的設計機制，以及使玩家願意一玩再玩的策略。

玩家們在關卡中所獲得的金錢，只扮演著「分數」的單一角色而已。許多玩家希望他們能夠花費這些金錢去購買一些升級道具，讓食物機器運作得更快，或擁有一個額外的餐盤空間。

因為我們沒有預先將玩家們的長期遊戲目標納入設計的規劃中，事後要再增加這些功能就顯得困難重重。玩家們或許非常喜愛《Bonnie’s Brunch》，但它的生命週期可能無法長久持續，因為遊戲本身的可重複遊玩性很低。

在遊戲團隊的整體發展計畫中，我們原先的想法是「以小開始」、「打安全牌」。事後來看，這或許不是一項很好的決定。

3. 陡峭的難度曲線

在前 10 個關卡中，遊戲簡單的就像是一塊蛋糕，既使是七歲的小女孩，也能夠以三顆星的成績通過這些關卡。然而，當玩家們抵達第二章節（第 11 至 20 關）後，遊戲難度就隨著吐司機器的出現而提升許多。更甚者，到了遊戲的第三章節及第四章節後，某些特殊客人如食評家及流浪漢的出現，更劇烈地升高了遊戲的困難度。

有些玩家指出，在非常努力地嘗試過關後，卻依舊只能得到一顆星的評價，讓他們感到非常地挫敗。雖然只需要得到一顆星，玩家們就可以繼續遊玩下個關卡，但這些玩家仍然覺得相當沮喪，因為他們認為「遊戲實在太難了」。

儘管《Bonnie’s Brunch》是被歸類在模擬及策略類型的遊戲中，但它需要玩家們的快速反應力及高度專注力。我們發現某個族群的玩家，不是特別喜歡這種類型的遊戲。他們不想要搞砸事情，更不想讓自己看起來像是手忙腳亂、不知所措的樣子。

如果你的遊戲需要玩家善用他們的「多工反射神經」，你真的該仔細斟酌你的目標玩家是否會喜歡它。

4. 模糊不清的市場方向

我們是一個超小型的團隊，來自一個東南亞地區的小國家叫做台灣。而且「台灣」還經常被西方人誤認為「泰國」。更糟糕的是，身為獨立遊戲開發者，我們既不熟悉也缺乏對於美國及歐洲遊戲市場的接觸管道。

誠如許多 App 開發者所知，我們正站在 App Store 的戰場中，打一場關於「能見度」的戰爭。若我們沒能向世界展現出自己的作品，我們將會跌落在沈默中安靜地死去。

於是我們把所有的遊戲促銷代碼發送給各大 App 評論網站，希望能夠引起他們的興趣進一步探究《Bonnie’s Brunch》的內容。然而，大多數的行動就像是石沈大海一樣沒有半點回音。其中 AppAdvice 是唯一給予我們機會的網站，我們真心地感謝他們。

再者，為了進一步試驗廣告是否能造成任何影響，我們在 Touch Arcade 的主站與論壇中，購買了兩組小型的廣告空間。截至目前為止，呈現出來的效果非常有限，每天只產生少於 50 次的連結點擊，而點擊率甚至不到 0.1%。

我們在思考的是，是否我們遊戲的目標族群（女性為主）並不符合 Touch Arcade 的讀者群？我們的美術設計風格，是否難以符合西方人的口味？或者它只是被視為另一款餐廳經營類型的老梗遊戲而已？這些是我們正努力嘗試想要得到答案的關鍵問題。

目前《Bonnie’s Brunch》（iTunes 連結）已推出最新的 1.1 版本，內容包含全新的關卡場景、Game Center排行榜以及多項功能修正，期望將來有機會和各位分享更多我們的開發心得及成績表現。

若您有住在國外或看不懂中文的朋友，歡迎將本篇文章的英文版轉發給他們。謝謝您的收看！

即‧將‧上‧市。

超可愛的人物表情，超逗趣的角色動作，超豐富的食材組合！

超夢想的行動餐車，超美麗的歐洲風情，超放鬆的背景音樂！

超詳盡的入門教學，超挑戰的反應速度，超刺激的限時關卡！

超超超好玩的唷～～～

今年夏天，火熱上演，敬請期待！ ^_^

《Bonnie’s Brunch》Facebook 粉絲團：http://www.facebook.com/bonniesbrunch

《Bonnie’s Brunch》官方網頁：http://www.bonniesbrunch.com/

《Crystal Guardian》Design Draft

這是《Crystal Guardian》的遊戲設計草稿。

其實大約在四個月前，我就已經完成了遊戲的基礎設計，本來想要在 NDS 平台上嘗試製作這款小小的遊戲原型，不過後來因為被其他有趣的事情吸引，再加上我一直找不到能夠在 Homebrew 套件上執行 Lua 的方法，所以也就沒有往 NDS 的方向繼續發展下去了。直到兩個月前，在玩過「咕世界」並且讀了「How to Prototype a Game in Under 7 Days」一文之後，內心深處那股「無論如何都想要做遊戲」的雄雄烈火，又再度燃燒了起來！

一開始在做遊戲設計的靈感發想時，對於目前網路上各種動作過關類型的小遊戲，可以看到大多數作品都是以「攻擊」、「毀滅」或者「破壞」當作遊戲的主要題材與樂趣元素。而我想要嘗試的，則是完全相反的方向。我反問自己：「有沒有可能以『保護』或者『防衛』的概念，做為遊戲的主要機制？」

當然，現在有許許多多 Tower Defence 類型的遊戲，但是我想做的並不是這種玩法的遊戲。我想做的遊戲，設計概念與核心機制的出發點在於「防護」(Defence)，或許是保護金銀財寶、捍衛重要的東西或者心愛的人，無論那是什麼，我認為世界上總有些值得我們守護的人、事、物以及價值。而至於遊戲的操作方式，我想嘗試的方向，是一個不用動腦思考，只需要不停移動並且點擊滑鼠就能夠進行的遊戲。

按照遊戲原型開發文章裡的做法，我原先預估的開發時程為 10 天整。直到正式開始動工之後，馬上就發現每天的開發時間，實在是超級無敵不夠用，才剛做出了點東西就花費掉一整個晚上，依照這樣的進度，10 天左右肯定無法完成遊戲，於是決定將開發時程延長為 14 天。結果，最終在燃燒小宇宙與睡眠時間的狂暴化狀態下，還是延遲了 2 天，整整用了 16 天才完成這款小遊戲。

雖然遊戲的核心機制很早就已經建立完畢，但是 Game Theme（遊戲題材）卻一直處於懸而未決的狀態。原因是「遊戲題材」與「遊戲素材」具有非常高的相依性，在找不到美術設計者合作，我自己也不會畫圖的情形下，想要對遊戲題材拍板定案，實在是一項相當困難而又不切實際的想法。

以後見之明來看，如果當初能夠使用 Flash 做為製作工具的話，應該可以節省不少開發基礎遊戲元件所花費的時間。但是我對 Flash 的熟悉度，差不多停留在讓矩形移動與變大變小的程度而已，所以最終還是毫無懸念地決定使用我最熟悉的 C++ 與 Lua 製作遊戲。

而這次開發的成果，並不是完全從零到有產生出來的。我原先已經有一個小小的遊戲程式框架 (Framework)，曾用來製作過一個 2D 遊戲的半成品，其中的功能只有非常基本的 Graphics、Audio、Input、Script 與 Debug 功能。於是我就以這個 Framework 做為出發點，義無反顧地展開了這趟遊戲開發的奇妙旅程。

過程中，我將每一天的進度都大致記錄了下來。以下就是這段時間裡，每天所做的開發日誌筆記：

Day 1

• 簡單扼要地在 Lua 端確立了程式的主流程。當程式啟動初始化完畢後，程式的控制權，包含 Update、Render 以及偵測視窗訊息與鍵盤滑鼠狀態在內，全權交由 Lua 端掌控。只要控制權一回到 C++ 端，就要清理資源然後準備結束程式了。
• 在既有的程式碼中，只能夠顯示單一的 Sprite 物件，這樣可不行哪。以 Sprite 為基礎，開始打造 CompositeSprite，可以組合任意多個 Sprite 做為一個完整的物件個體。（結果最後並沒有使用到這個功能）
• 原先在 Framework 中的 Input 系統只有二元狀態 On 或 Off 的 Polling 模式，對於開發除錯來說實在很不方便，所以決定先在 Lua 裡弄個簡易的 Event-based 模式，讓我在每次按下鍵盤或滑鼠按鈕時，只會送出一次事件訊息。
• 在網路上亂逛，意外找到《太空戰士》系列作品的 Sprite Sheet，品質看起來很不錯，是不是可以考慮拿來做為遊戲的素材？

Day 2

• 製作 Animation 系統。以前有使用 Lua 寫過相同的東西，所以翻出舊作的 Source 來看。「寫得真糟，當初怎麼會這樣想又這樣寫呢？」費了些功夫，翻修製作出新的 AnimatedSprite 元件。當然動畫資料的定義，也全部都使用 Lua 完成。
• 現在可以載入多張獨立的圖片播放動畫，但是網路上找到的 Sprite Sheet 通常都是一整張圖片的連續畫格，如果還得自己動手裁切，未免也太費力了點。所以只好再製作 AnimatedSprite 的第二種模式，讓它能夠讀入單張圖片來播放動畫。
• 套用《太空戰士》的 Sprite Sheet，測試 AnimatedSprite 元件的功能無誤。好，就決定偷這些圖來用！
• 重新組織 Lua 端的檔案結構。

Day 3

• 給點回應吧！實現簡單的矩形與圓形碰撞檢測。有了 Pick 元件後，才能夠知道滑鼠到底有沒有點選到 Sprite。
• 創造簡易的 State Machine 元件來搭配角色的 Animation 系統，目前只有 idle 與 move 兩種狀態。
• 放上數個不同圖片的角色，於遊戲視窗中隨機遊走。顯示結果怎麼全部的角色圖片都相同？
• 第一次臭蟲大魔頭來襲：是之前的 AnimatedSprite 功能有誤嗎？還是哪個部分的功能有所疏忽？經過了一番奮戰並且用掉好幾罐「補血瓶（小）」之後，才發現原來我誤用了 Lua 物件導向設計的觀念！

下列程式碼是錯誤的用法：

    local o = self:Instance();
    o.m_Transform = transform;
    o.m_Texture = texture;
    o.m_Sprite = sprite;
    

下列程式碼才是正確的版本：

    local o = self:Instance
    {
        o.m_Transform = transform,
        o.m_Texture = texture,
        o.m_Sprite = sprite,
    };
    

修改完成後，終於還給每個角色他們原來的真面目了！

Day 4

• 開始加入先前已設計完成的 Game Level 結構，可使用 Lua 檔案很便利地定義每一個關卡敵人的出現時間、類型、數量與方位。
• 簡便地使用 function 與 if-else 切換不同的 Game Stage。目前初步規劃，共有 Initialize、In Game、Between Level 與 Game Set 四個 Stage。（決策錯誤）

Day 5

• 建立玩家角色的各種狀態：idle、move、attack、powerup 以及 dead。滑鼠點擊後，玩家角色會移動至滑鼠位置，如果角色正在進行攻擊動作則無法移動。過程很順利。
• 創建敵人的 dead 與 dig（偷取水晶）狀態，包含先前的 idle 與 move 在內，終於完成了第一個完整的 AI 流程。不過敵人還是只會在場景上到處亂逛。

Day 6

• 開始著手製作原先規劃的數種 AI 型態：預設的一路走到底 AI、亂亂走 AI，還有走一走會停下來的 AI。

Day 7

• 為了讓 Release Build 的建置程序更加自動化與直覺化（簡單說就是我懶得做一大堆複製貼上的動作），所以用 Lua 弄了個 Prebuild 程序。將指定的純文字格式 Lua 檔案，全部寫入一個新的檔案中，完畢之後執行 luac 編譯成 binary 格式。最後，把執行命令加在 Project 的 Post-Build Event 中，搞定！

Day 8

• 開始寫 Gameplay 流程的部分，包括 Stage 與 Stage 之間的銜接，Game Over 與全破關的條件判斷。程式碼逐漸有越來越混亂的感覺……

Day 9

• 到目前為止，遊戲中還沒有出現任何文字。所幸 Framework 中已有繪製 TrueType Font 的功能，直接拉進 Lua 使用。測試無誤。

Day 10

• 到 POPcade 的音樂音效素材區搜尋資料，找到一個日本的網站 Propan_Mode，裡頭滿滿的都是 MP3 格式的高品質音效與音樂，真是太棒太讚太感動啦！（不過一直沒有找到合適的攻擊音效，囧）
• 加入播放音樂與音效的功能。製作一個 Radio 元件，用來做為遊戲中的 BGM Player，可把使用者提供的播放清單，依序、隨機或者循環播放。

Day 11

• 在 Google 打上「Free Font」，從成千上萬個 Font 裡找到幾個還算合用的字型。
• 用網路上搜尋到的免費軟體，將 MP3 轉換為檔案容量較小的 OGG 格式，將播放音效的程序加入遊戲。

Day 12

• 用 Photoshop 幫角色圖片進行去背程序。讚！終於不用帶著白色的框框在場景上行走啦。
• 再度修改 Animation 系統與 AnimatedSprite 元件，現在可以指定動畫中每個畫格的起始位置了。
• 產出遊戲角色以及水晶的動畫定義檔，對每一個動作的每一個畫格（還好數量很少），Pixel by Pixel 逐一進行微調。

Day 13

• 測試 AI 系統裡最複雜的「閃避」程序。果然有不少問題，經過整修後得出一個還算可接受的成果。
• 修改 Framework 的 Debug 功能，可將 Lua 的錯誤訊息以 MessageBox 秀出來並且記錄在 Log 檔中。（為什麼這麼晚才想到可以這樣做？ =_=）

Day 14

• 實作 AI 的 Perk 程序，敵人「格檔」時會無視玩家的攻擊，「反制」時會使玩家在三秒內無法動作。掛上一個額外的盾牌與雙劍小圖示。
• 加入分數計算以及 Combo 連擊加成的程序。
• 從以前的作品素材中，拉來幾張背景圖。場景畫面終於脫離了單調無趣的背景色！

Day 15

• 開始正式製作遊戲關卡。試玩，微調，微調，微調。
• 找了台沒有安裝 MSVC 的電腦測試，確認遊戲執行檔沒有 DLL 相依性的問題。
• 第二次臭蟲大魔頭來襲：正當我以為遊戲已經逼近完成之時，突然發現了嚴重的邏輯與流程問題。當敵人奪取水晶之後再被玩家擊倒，敵人的 AI 會產生異常狀態。然後過關條件的判斷也不正確，水晶都被幹光了竟然沒有切換到 Game Over 的 Stage，到底是怎麼回事？

Day 16

• 重新大整修：首先是敵人連結水晶的部分，寫的方式含糊不清又太多假設條件，造成不正確的執行結果。接著再重新思考敵人的 State 轉換，將原先散落在各個 State 中的邏輯判斷，提煉出來做為獨立的 function。最後，加入一個新的「準備階段」Stage，大幅簡化 Stage 與 Stage 之間的切換流程。
• 重新調整關卡難度。調整。測試。調整。測試。完成！
• 打包壓縮，撰寫文章，發佈。（靈魂飄走）

以上就是 16 天以來的開發流程。

雖然我使用 Lua 已經有一段不算短的時間了，但這還是我第一次以 Lua 完成所有的 Gameplay 程式碼。在遊戲的開發流程中，相關於程式設計的部分，只有使用了 5% 左右的時間在修改及新增 C++ 端 Framework 的功能上，其餘 95% 的時間全投注於 Lua 的環境下撰寫程式碼。再者，為了使這些以 Lua 撰寫的遊戲元件能夠繼續在未來的遊戲作品中使用，所以也耗費了不少時間在考量 Reusability（可復用性）的議題。最終，順利地把 Lua 端的程式碼，分成了「遊戲元件」（可復用）以及「Gameplay 相關」（不可復用）兩種不同的用途。

使用 Lua 編寫 Gameplay 程式邏輯的主要優勢在於「速度」。修改，存檔，然後執行，一氣呵成！再也不必因為一點小小的修改，而必須等待漫長的程式碼編譯與函式庫連結時間。但是使用 Lua 也並非全無缺點；在程式碼編輯工具的選擇上，我使用的是 Lua for Windows 套件中的 SciTE 編輯器，雖然 SciTE 具備有基本的編譯與除錯功能，但無法與 C++ 端的程式碼相互連結，所以在 Gameplay 的除錯程序上比較麻煩，還是必須執行 C++ 端的程式執行檔，才能夠找出 Lua 端的錯誤與問題點。

另外在撰寫程式的過程中，我有點太過於小看 Stage 切換邏輯判斷的複雜度。一開始在撰寫 Stage 相關的部分時，並沒有設想太多，只使用了最簡單的 function 與 if-else 敘述句來切換不同的 Stage，結果到了最後反而造成不少問題。還是應該打從一開始就把 Stage 的架構與流程控制，寫成一個獨立可重複利用的元件才正確。

而在所有的程式系統與遊戲邏輯中，最複雜的部分應該就是敵人的 AI 程序了。我想達到的目標，是多變且具有擴充性的 AI 模組。為了達成多樣化的 AI 行為，如果只是單純地將 AI 程序分成「直線型」、「隨機型」與「格檔型」等等，其實無法發揮良好的綜效。所以後來我想到了一個做法，就是將 AI 處理程序拆解成三種獨立的邏輯程序，分別是 Path Planner、Tactic Thinker 以及 Perk（特技）：

Path Planner

• 直線
• 隨機

Tactic Thinker

• 無
• 暫停
• 閃避

Perk

• 無
• 格檔
• 反制

分成三種獨立程序之後，我就可以在設計各關卡的敵人類型時，任意組合上述三種 AI 邏輯程序，然後再加上敵人外觀與生命數值的設定，製作出豐富而多樣化的敵人軍團。

在這 16 天的遊戲開發過程中，排除之前預先完成的遊戲設計層面，以程式設計、素材生產與關卡設計三個面向進行評估，程式設計約略佔了 80% 左右的開發時間，而素材生產與關卡設計加起來卻只佔用了 20% 左右的時間。用在關卡設計與素材製作面向上的心力，實在太少太少啦！

總結來說，下一款遊戲作品的改善目標為：

1. 先搞定 Stage 架構與流程控制元件。
2. 美術！我需要找到能夠共同合作的美術成員，或者是可以見人的 Better Programmer Art。
3. 花費更少的時間寫程式碼，把更多時間心力投注在關卡設計與素材製作上。
4. 遊戲必須要更有趣，更具有可玩性。

在遊戲設計的層面上，我還是個十足的嫩咖，但是只要過程好玩，我就會一直一直玩下去！ ：D

你可能不知道的小秘辛：遊戲本來想取名為 Crystal Defender，後來發現 Square Enix 在 iPhone 上有發佈一款同名作品，所以只好更換名稱為 Crystal Guardian。 XD

你不可不知道的小秘技：如果覺得遊戲太刁難或是滑鼠不夠滑而過不了關，請打開遊戲資料夾中的 GameEnemy.lua 與 GameLevel.lua 檔案，相信各位一定能夠發現戰勝遊戲的很黑暗的招。 ：P