在 Global Game Jam 2014 的三天內與另一位程式設計師協作完成一款遊戲，讓我深刻體會到版本控制、共通框架與 pair programming 在快速開發中的價值。本文保留我在活動中的第一手筆記，從遊戲發想的心智圖方法，到程式協作踩過的坑，分享給同樣要短期衝刺開發的團隊。
短期開發需要哪些協作工具？
我們這次使用的協作工具很單純：
- FlashBuilder 4.7
- Flash
- 心智圖
- SVN
工具越簡單越好，重點是雙方都要熟悉——這一點後來在程式協作時讓我付出不小的代價。
遊戲發想為什麼要用心智圖？
我們這一組是使用心智圖的方式去發想遊戲的概念，並且紀錄下討論的內容、將發想的點子分門別類，以樹狀圖的形式，將所有的主題分類成三種：顛覆、人性、元素。
下圖是我們當天所討論出的主題架構：
本屆主題是：We don't see things as they are, we see them as we are.
我們以這主題去延伸，討論出幾點我們認為有符合這種概念的幾件事情，在討論時，Mao哥點出幾點我們在發想遊戲時，應該要注意的點：
- 不要管怎麼實作（不要去想細節）
- 點子越奇怪越好
- 用一句話就能表達出你想傳達的內容
- 用別人的點子去延伸自己的想法
- 先思考遊戲『想要給人的感受』
發想階段最容易犯的錯誤是什麼？
一般人比較容易犯的錯誤，是很容易會在企劃發想時期就想到太多細節或實作面的東西，這樣會讓創意失焦，並且容易納入許多和主題不相符的內容到遊戲裡。因此在發想時期，應要把討論的重點放到『想讓玩家感受到什麼』，而不是『怎麼作』。
在實際討論時，我也發現這樣的發想方式，更容易激發眾人的思考與創意，每個人可能說出他喜歡玩、以及曾經玩過的遊戲，在聽別人描述那個遊戲的玩法，以及玩那遊戲所感受到的好玩之處時，聽的人可以加上一些自己原本就有的 idea 和想法，提出來加以討論，很容易就能融合出很不一樣的創意。
為什麼『肯定他人的想法』在腦力激盪中這麼重要？
在遊戲發想時期，另一個很重要的點就是『延伸』。在這次的討論中，我發現在討論時期，『肯定他人的想法』是一件非常重要的事。台灣人大多比較害羞，會較不好意思說出自己的想法，因此，當有一個人說出自己的 idea 時，肯定它並加以延伸，是很重要的事。即使那個點子非常的無聊，主持者也可以用該點子去延伸出一個比較有趣的主題附加在上面。
這會讓其他與會者更有膽量說出自己的看法，並且也更容易讓更多好點子融合在一起，成為一個新的點子。
以我們的討論為例，當時我們組員有一位提出了太空這個想法，在一開始我聽到時，還並不覺得有趣，但是後來另一位組員又補上了『因為太空是未知的，所以太空的所有事物都可以是幻想的，可以充滿想像力。例如或許一群星球很靠近，但他們並不是像太陽系這樣是靠引力去維持運轉，或許某一個另外一個星球系，是因為每個星球彼此相斥，所以才能夠彼此維持相同不動的狀況』，這個想法一丟出來，大家就引發許多其他更多的想像空間去做發想，然後激發更多更好的點子。
快速協作開發會遇到什麼問題？
在這次的遊戲開發裡，我對於在短時間內要同時進行開發一個作品的協同開發上，有許多的心得。
首先是，協作的版本控制系統非常重要，並且要是雙方都熟悉的工具。我們採用 SVN 來做檔案的版本控制，因為第一次參加活動，SVN 是在當場現場才設定好環境，花掉了我們開發的好一些時間，若有下次參加會建議事前要準備好版本管理系統的環境。
我們在一開始時，因為很擔心進度趕不完，所以當時想要用最快、最簡單的方式做開發。也就是未將 MVC 拆開，將所有的功能皆用純手工打造，希望能以最快速的方式，將功能做出來。
但我們後來卻遇到了嚴重的協作問題。
為什麼沒有共通架構會讓兩個高手寫出很醜的程式？
因為原作者寫 code 的方式，配合的人不了解。在遇到一些因原來作者所寫的 code 而產生的邏輯問題時，會變得只能去修改後面的開發邏輯去配合前面的開發者，而不會去修正前面寫不好的邏輯，這會造成到最後全部的 code 都看起來很奇怪。或許 A 跟 B 都是高手，但是因為需求改變，彼此寫 code 的方式不同，彼此看不懂彼此在幹麻（更可能的是為了尊重，不好意思擅自改其他人的 code），架構又沒有拆好，兩個高手開發出的程式卻很醜的狀況，就有可能會出現了。
在需要快速開發的時候，因為需求以及遊戲內容會快速的隨著開發的時間而改變，在一開始幾乎會不可能可以完全正確的規劃出最好的設計邏輯。為了應變快速改變的需求，這時候 framework 和 MVC 的重要性就真切的在此時顯現出來了。
越是需要快速開發，越是需要應變頻繁的功能修改，共通的框架及開發模式就越是重要。
我們如何用 Robotlegs 與 Pair Programming 補救？
我們在第二天晚上花了很多時間將架構整個用 Robotlegs 去改寫過，並且在最核心的架構部份採用 pair programming 的方式，兩個人同時盯著螢幕，一起開發程式。事後也證明，那一段兩人一起開發的程式，是所有部份裡最穩固最成熟，也最不容易出現 bug 的部份。
Pair programming 是 eXtreme Programming 很提倡的一種方式，我認為 eXtreme Programming 的開發方法，特別適合用在於類似這種三天內要趕出一款遊戲的狀況下。這邊有關於 XP 的簡單介紹：極限編程（維基百科）、軟體開發之極限編程（極限開發）eXtreme Programming, XP。
因為時間不足，不太可能所有的程式碼都用 pair programming，我們先將功能以關卡劃分工作項目，然後討論出各關卡一定會共用到的部份，將共用的部份用 pair programming 去開發，剩的功能再拆分出來各自實作。
Pair Programming 的好處有哪些？
在這邊列出幾點我感受到的 pair programming 的好處：
- 參與的開發人員都能了解程式邏輯：一個能讓其他開發人員看得懂的程式，才叫做漂亮的程式。這也是為什麼近來大家總是很注重的在探討『如何寫出漂亮的程式碼』的原因。很多時候，完全看懂別人的程式邏輯比重寫一次還要更花時間，一起寫 code 能讓參與的人都能夠同時了解到程式的邏輯，而不用自己去當人腦編譯器理解別人寫的 code。
- 在合作中可以截長補短：在合作中，其實是可以學習到東西的，每個人都有不同的想法以及擅長的地方。一起寫 code 真的可以集結雙方寫程式的優點，能讓產出的 code 有更好的水準。
- 培養共通的開發習慣：這個因為我們合作時間較短，所以這一次活動裡比較沒有感受到這優點。但我覺得若是能夠長期讓一起合作的成員有機會去做 pair programming 的開發，這能讓大家在合作中更深入的了解到其他隊友的開發模式，對於未來的協同開發上將會能夠更加順暢。
在其他敏捷開發的書裡也有談到許多關於快速開發的一些想法，在這次的聚會中，讓我真切的感受到書中許多論點的有力性。我覺得，像這種活動，因為時間上的緊迫性，書上許多過去看來像是難以理解的開發方法，在活動中都能讓我們感受到這些理論所說論點的實用性，是個很難能可貴的經驗。
延伸閱讀
- Global Game Jam 2014 心得：遊戲發想方法與 Pair Programming 協作經驗：同樣聚焦 Pair Programming、版本控制，可接著比較不同情境的做法。
- [GGJ-2014] 活動參與心得：同樣聚焦 Global Game Jam、遊戲開發，可接著比較不同情境的做法。
- GGJ 2014 開場影片與主題介紹：遊戲發想與腦力激盪的啟發：同樣聚焦 Global Game Jam、遊戲開發，可接著比較不同情境的做法。
常見問題
短期衝刺開發前該先準備什麼？
版本控制系統一定要事先設定好，並且確保所有協作者都熟悉該工具。我們因為在活動現場才設定 SVN 環境，浪費了寶貴的開發時間。
來不及拆 MVC 架構時該怎麼辦？
越急越要有共通框架。我們的經驗是先硬寫之後再重構會付出更大代價，第二天晚上仍花了整晚用 Robotlegs 重寫架構。事前約定好目錄結構與命名慣例，能大幅降低協作摩擦。
Pair Programming 適合用在專案的哪些部分？
最適合用在共用、核心的架構程式碼上。我們把各關卡一定會共用的部分用 pair programming 開發，各自獨立的功能再拆分實作。這些兩人一起寫的程式碼，後來證實是整個專案最穩固、最少 bug 的部分。
發想遊戲點子時最容易犯什麼錯？
在發想階段就深入實作細節，會讓創意失焦。發想期的重點應該放在『想讓玩家感受到什麼』，而不是『怎麼做』，並且用一句話就能說清楚想傳達的內容。
極限編程（XP）適合 Game Jam 這種活動嗎？
非常適合。極限編程強調的快速迭代、簡單設計與 pair programming，正好對應 Game Jam 中需求快速變動、時間極度壓縮的情境。平常看起來抽象的敏捷理論，在時間壓力下反而最能驗證其實用性。
參考資料
最後更新
2026-08-28（原文發布於 2014-02-05，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2014-02-05