這篇文章整理我參加 2014 Global Game Jam 的兩大核心心得：一是如何在有限時間內用心智圖有效率地發想遊戲點子，二是在短時間協同開發中，為什麼越急越需要共通框架、MVC 架構與 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？
我們在一開始時，因為很擔心進度趕不完，所以當時想要用最快、最簡單的方式做開發。也就是未將 MVC 拆開，將所有的功能皆用純手工打造，希望能以最快速的方式，將功能做出來。
但我們後來卻遇到了嚴重的協作問題。
因為原作者寫 code 的方式，配合的人不了解。在遇到一些因原來作者所寫的 code 而產生的邏輯問題時，會變得只能去修改後面的開發邏輯去配合前面的開發者，而不會去修正前面寫不好的邏輯，這會造成到最後全部的 code 都看起來很奇怪。或許 A 跟 B 都是高手，但是因為需求改變，彼此寫 code 的方式不同，彼此看不懂彼此在幹嘛（更可能的是為了尊重，不好意思擅自改其他人的 code），架構又沒有拆好，兩個高手開發出的程式卻很醜的狀況，就有可能會出現了。
在需要快速開發的時候，因為需求以及遊戲內容會快速地隨著開發的時間而改變，在一開始幾乎會不可能可以完全正確地規劃出最好的設計邏輯。為了應變快速改變的需求，這時候 framework 和 MVC 的重要性就真切的在此時顯現出來了。
越是需要快速開發，越是需要應變頻繁的功能修改，共通的框架及開發模式就越是重要。
我們在第二天晚上花了很多時間將架構整個用 Robotlegs 去改寫過，並且在最核心的架構部份採用 pair programming 的方式，兩個人同時盯著螢幕，一起開發程式。事後也證明，那一段兩人一起開發的程式，是所有部份裡最穩固最成熟，也最不容易出現 bug 的部份。
Pair programming 是 eXtreme Programming（XP，極限編程）很提倡的一種方式，我認為 eXtreme Programming 的開發方法，特別適合用在於類似這種三天內要趕出一款遊戲的狀況下。關於 XP 的簡單介紹，可參考：極限編程（維基百科）、軟體開發之極限編程 eXtreme Programming, XP。
Pair programming 實務上怎麼分配工作？
因為時間不足，不太可能所有的程式碼都用 pair programming，我們先將功能以關卡劃分工作項目，然後討論出各關卡一定會共用到的部份，將共用的部份用 pair programming 去開發，剩下的功能再拆分出來各自實作。
Pair programming 有哪些好處？
在這邊列出幾點我感受到的 pair programming 的好處：
- 參與的開發人員都能了解程式邏輯：一個能讓其他開發人員看得懂的程式，才叫做漂亮的程式。這也是為什麼近來大家總是很注重地在探討『如何寫出漂亮的程式碼』的原因。很多時候，完全看懂別人的程式邏輯比重寫一次還要更花時間，一起寫 code 能讓參與的人都能夠同時了解到程式的邏輯，而不用自己去當人腦編譯器理解別人寫的 code。
- 在合作中可以截長補短：在合作中，其實是可以學習到東西的，每個人都有不同的想法以及擅長的地方。一起寫 code 真的可以集結雙方寫程式的優點，能讓產出的 code 有更好的水準。
- 培養共通的開發習慣：這個因為我們合作時間較短，所以這一次活動裡比較沒有感受到這優點。但我覺得若是能夠長期讓一起合作的成員有機會去做 pair programming 的開發，這能讓大家在合作中更深入地了解到其他隊友的開發模式，對於未來的協同開發上將會能夠更加順暢。
在其他敏捷開發的書裡也有談到許多關於快速開發的一些想法，在這次的聚會中，讓我真切地感受到書中許多論點的有力性。我覺得，像這種活動，因為時間上的緊迫性，書上許多過去看來像是難以理解的開發方法，在活動中都能讓我們感受到這些理論所說論點的實用性，是個很難能可貴的經驗。
延伸閱讀
- GGJ 2014 遊戲開發心得：用 Pair Programming 與極限編程撐過 48 小時協作地獄：同樣聚焦 Pair Programming、版本控制，可接著比較不同情境的做法。
- [GGJ-2014] 開場影片與遊戲發想：主題解析與腦力激盪筆記：同樣聚焦 Game Jam，可接著比較不同情境的做法。
- 鳳凰專案讀後筆記：看IT部門如何讓公司從谷底翻身的傳奇故事：同樣聚焦 敏捷開發，可接著比較不同情境的做法。
常見問題
什麼是 Global Game Jam（GGJ）？
Global Game Jam 是一年一度的全球遊戲開發活動，參賽者要在 48 小時內，依據大會公布的主題，組隊從零做出一款遊戲。時間極短、需求持續變動，是它最大的挑戰，也最考驗團隊的發想與協作流程。
遊戲發想階段最容易犯的錯誤是什麼？
最容易犯的錯是在發想時期就深入實作細節，讓創意失焦。正確的做法是把討論重點放在『想讓玩家感受到什麼』，而不是『怎麼做』，先用一句話說清楚點子的核心感受。
為什麼越趕時間的專案越需要框架和 MVC？
因為時間越趕，需求與功能修改就越頻繁，一開始幾乎不可能規劃出完美的設計邏輯。共通的框架與 MVC 分層讓成員能看懂彼此的程式、降低修改成本，否則即使都是高手，沒有架構的合作也容易產出難以維護的程式碼。
Pair programming 適合用在專案的哪些部分？
在時間有限的專案裡，不可能所有程式碼都用 pair programming。建議把團隊一定會共用到的核心模組（例如共用架構、核心邏輯）用 pair programming 一起開發，其餘獨立功能再拆給成員各自實作。
參加遊戲 jam 活動前該做什麼準備？
事前把版本控制系統（如 SVN 或 Git）的環境設定好是最重要的，我們當場才設定 SVN 就花掉不少開發時間。另外也要確認協作工具與開發環境全隊都熟悉，才能把時間花在開發本身。
參考資料
最後更新
2026-08-28（原文發布於 2014-02-05，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2014-02-05