[GGJ-2014] 遊戲開發心得

協作工具

  1. FlashBuilder4.7
  2. Flash
  3. 心智圖
  4. svn

遊戲發想

我們這一組是使用心智圖的方式去發想遊戲的概念,並且紀錄下討論的內容、將發想的點子分門別類,以樹狀圖的形式,將所有的主題分類成三種:顛覆、人性、元素。

下圖是我們當天所討論出的主題架構:

螢幕快照 2014-01-29 下午5.24.38

本屆主題是:We don’t see things as they are, we see them as we are.

我們以這主題去延伸,討論出幾點我們認為有符合這種概念的幾件事情,在討論時,Mao哥點出幾點我們在發想遊戲時,應該要注意的點:

  1. 不要管怎麼實作(不要去想細節)
  2. 點子越奇怪越好
  3. 用一句話就能表達出你想傳達的內容
  4. 用別人的點子去延伸自己的想法
  5. 先思考遊戲『想要給人的感受』

一般人比較容易犯的錯誤,是很容易會在企劃發想時期就想到太多細節或實作面的東西,這樣會讓創意失焦,並且容易納入許多和主題不相符的內容到遊戲裡。因此在發想時期,應要把討論的重點放到『想讓玩家感受到什麼』,而不是『怎麼作』。在實際討論時,我也發現這樣的發想方式,更容易激發眾人的思考與創意,每個人可能說出他喜歡玩、以及曾經玩過的遊戲,在聽別人描述那個遊戲的玩法,以及玩那遊戲所感受到的好玩之處時,聽的人可以加上一些自己原本就有的idea和想法,提出來加以討論,很容易就能融合出很不一樣的創意。

在遊戲發想時期,另一個很重要的點就是『延伸』。在這次的討論中,我發現在討論時期,『肯定他人的想法』是一件非常重要的事。台灣人大多比較害羞,會較不好意思說出自己的想法,因此,當有一個人說出自己的idea時,肯定它並加以延伸,是很重要的事。即使那個點子非常的無聊,主持者也可以用該點子去延伸出一個比較有趣的主題附加在上面。

這會讓其他與會者更有膽量說出自己的看法,並且也更容易讓更多好點子融合在一起,成為一個新的點子。

以我們的討論為例,當時我們組員有一位提出了太空這個想法,在一開始我聽到時,還並不覺得有趣,但是後來另一位組員又補上了『因為太空是未知的,所以太空的所有事物都可以是幻想的,可以充滿想像力。例如或許一群星球很靠近,但他們並不是像太陽系這樣是靠引力去維持運轉,或許某一個另外一個星球系,是因為每個星球彼此相斥,所以才能夠彼此維持相同不動的狀況』,這個想法一丟出來,大家就引發許多其他更多的想像空間去做發想。然後激發更多更好的點子。

程式協作

在這次的遊戲開發裡,我對於在短時間內要同時進行開發一個作品的協同開發上,有許多的心得。

首先是,協作的版本控制系統非常重要,並且要是雙方都熟悉的工具。我們採用svn來做檔案的版本控制,因為第一次參加活動,svn是在當場現場才設定好環境,花掉了我們開發的好一些時間,若有下次參加會建議事前要準備好版本管理系統的環境。

我們在一開始時,因為很擔心進度趕不完,所以當時想要用最快、最簡單的方式做開發。也就是未將MVC拆開,將所有的功能皆用純手工打造,希望能以最快速的方式,將功能做出來。

但我們後來卻遇到了嚴重的協作問題。

因為原作者寫code的方式,配合的人不了解。在遇到一些因原來作者所寫的code而產生的邏輯問題時,會變得只能去修改後面的開發邏輯去配合前面的開發者,而不會去修正前面寫不好的邏輯,這會造成到最後全部的code都看起來很奇怪。或許A跟B都是高手,但是因為需求改變,彼此寫code的方式不同,彼此看不懂彼此在幹麻(更可能的是為了尊重,不好意思擅自改其他人的code),架構又沒有拆好,兩個高手開發出的程式卻很醜的狀況,就有可能會出現了。

在需要快速開發的時候,因為需求以及遊戲內容會快速的隨著開發的時間而改變,在一開始幾乎會不可能可以完全正確的規劃出最好的設計邏輯。為了應變快速改變的需求,這時候framework和MVC的重要性就真切的在此時顯現出來了。

越是需要快速開發,越是需要應變頻繁的功能修改,共通的框架及開發模式就越是重要。

我們在第二天晚上花了很多時間將架構整個用Robotleg去改寫過,並且在最核心的架構部份採用pair programming的方式,兩個人同時盯著螢幕,一起開發程式。事後也證明,那一段兩人一起開發的程式,是所有部份裡最穩固最成熟,也最不容易出現bug的部份。

pair programming是eXtreme Programming很提倡的一種方式,我認為eXtreme Programming的開發方法,特別適合用在於類似這種三天內要趕出一款遊戲的狀況下。這邊有關於XP的簡單介紹:極限編程軟體開發之極限編程(極限開發) eXtreme Programming, XP

因為時間不足,不太可能所有的程式碼都用pair programming,我們先將功能以關卡劃分工作項目,然後討論出各關卡一定會共用到的部份,將共用的部份用pair programming去開發,剩的功能再拆分出來各自實作。

在這邊列出幾點我感受到的pair programming的好處:

  1. 參與的開發人員都能了解程式邏輯:一個能讓其他開發人員看的懂得程式,才叫做漂亮的程式。這也是為什麼近來大家總是很注重的在探討『如何寫出漂亮的程式碼』的原因。很多時候,完全看懂別人的程式邏輯比重寫一次還要更花時間,一起寫code能讓參與的人都能夠同時了解到程式的邏輯,而不用自己去當人腦編譯器理解別人寫的code。
  2. 在合作中可以截長補短:在合作中,其實是可以學習到東西的,每個人都有不同的想法以及擅長的地方。一起寫code真的可以集結雙方寫程式的優點,能讓產出的code有更好的水準。
  3. 培養共通的開發習慣:這個因為我們合作時間較短,所以這一次活動裡比較沒有感受到這優點。但我覺得若是能夠長期讓一起合作的成員有機會去做pair programming的開發,這能讓大家在合作中更深入的了解到其他隊友的開發模式,對於未來的協同開發上將會能夠更加順暢。

在其他敏捷開發的書裡也有談到許多關於快速開發的一些想法,在這次的聚會中,讓我真切的感受到書中許多論點的有力性。我覺得,像這種活動,因為時間上的緊迫性,書上許多過去看來像是難以理解的開發方法,在活動中都能讓我們感受到這些理論所說論點的實用性。是個很難能可貴的經驗。

2 Replies to “[GGJ-2014] 遊戲開發心得”

Comments are closed.