極度邊緣的開發方式 by Ross Huang TGDF演講Youtube連結：https://www.youtube.com/watch?v=yV0aYkDtqp8 今天要分享的主題是「極度邊緣的開發方式」內容是講我們在極度邊緣工作室的開發流程， 會想講這個主題是因為在跟其他開發者聊天或被採訪時，很多人都會想知道為什麼我們工作室只有七個人，卻可以做出記憶邊境這樣的遊戲， 除了我們的團隊成員幾乎都是有經驗的遊戲開發者以外，最主要的原因是我們採用的開發流程可以避免很多問題，絕對不是我們的工作效率有多高或者加多少班， 希望今天的分享能對大家有點幫助。 自我介紹 我叫Ross 極度邊緣工作室的企劃/專案管理 作品「記憶邊境」 喜歡類魂或動作遊戲的人，歡迎追蹤： 極度邊緣工作室官方網站 Facebook、Twitter、YouTube 遊戲開發研究所SMU Guildhall畢業 有5年以上帶團隊跟專案管理經驗 這份簡報、演講者備忘稿跟參考資料都會公布在網路上，歡迎大家分享給身邊有需要的開發者。 首先，先來自我介紹一下，大家好，我叫Ross，我是極度邊緣工作室的企劃也負責專案管理的部分， 我們的第一個作品是「記憶邊境」，目前已經上市了，喜歡類魂或動作遊戲的人，歡迎購買遊戲支持我們或追蹤我們的社群媒體。 在加入工作室以前，我從美國遊戲開發研究所SMU Guildhall畢業，主修關卡設計。 研究所畢業後，先待過幾間非獨立遊戲工作室的遊戲公司，今天分享的內容會是我整合研究所、工作經驗跟自學的結果。 然後今天使用的簡報、演講者備忘稿跟參考資料，在未來都會跟Youtube影片一起公布在網路上， 大家可以不用忙著拍照，認真聽、簡單做個筆記就好，如果講完時間夠的話，我還可以接受幾個現場發問。 === SMU Guildhall遊戲研究所介紹(企劃角度) https://www.ptt.cc/bbs/GameDesign/M.1459934180.A.89E.html SMU Guildhall遊戲課程介紹(企劃角度，內含研究所上課書單) https://www.ptt.cc/bbs/GameDesign/M.1459939570.A.5E9.html SMU Guildhall 第一個半學期的學習心得(程式角度) https://www.ptt.cc/bbs/GameDesign/M.1413070923.A.423.html SMU Guildhall 第二個 Mod 學習心得(程式角度) https://www.ptt.cc/bbs/GameDesign/M.1413070923.A.423.html 免責聲明 這是經驗分享，不是專業建議 大部分內容都不是我原創的，我只是把東西湊在一起 這個開發方式比較適合中小型團隊 沒有最好的開發方式，只有最適合你們的開發方式 我們沒有完全做到 我們也犯了一堆錯誤 我們到現在都還在調整跟修改 在進入正題以前，我先來打一劑預防針： 1. 今天的簡報內容比較像是經驗分享而不是專業建議 2. 簡報中大部分的觀念跟理論都是我從書籍、網路或其他人身上學來的， 所以如果我提到的任何東西你覺得好像在哪裡聽過，你的直覺應該是對的， 我不是原創者，我只是把我覺得有用的東西湊在一起，然後再根據實際經驗調整而已。 3. 今天提到的開發方式比較適合中小型團隊，我的經驗是到20~30個人都還能適用， 再大的團隊我沒帶過，但我認為觀念都是共通的，只是執行方式上要做出改變。 4. 如果各位覺得今天聽到的東西有道理的話，非常歡迎採用， 但希望大家是理解背後的原理再使用，不要太堅持流程或細節的部分， 因為實際在開發的時候「沒有最好的開發方式，只有最適合你們的開發方式」 而且今天講的東西... 大綱 前期討論 開發流程：開發前 (Pre-Production) 開發流程：正式開發 (Production) 開發流程：開發結束 (Post-Production) 加速開發的觀念分享 Q&A 這是今天演講的大綱： 1. 首先，我會先介紹一些在開始開發遊戲以前要釐清的部分 2~4. 然後我會介紹我們目前使用的開發流程長怎樣，還有在開發過程中的每個階段該注意跟該做什麼事情。 5. 除了開發流程以外，我還會分享一些我們學到能增加開發速度的觀念 6. 最後如果有剩餘時間的話，則會開放現場問答。 前期討論 極度邊緣的開發流程是綜合多種理論跟架構的結果 主要是參考敏捷開發，但只採用了一些觀念 流程之間息息相關，因此必須打好基礎 目標是在合理範圍內，做出最理性的決定 因此，團隊必須可以理性溝通 尤其是團隊的領導者必須以身作則 前期討論 - 前言 … 細節 系統 設計支柱 專案的目的 專案的願景 我們現在的開發流程是綜合多種理論跟架構的結果，主要是參考敏捷開發，但我們也沒有完全遵守。 這個開發流程像是在蓋房子一樣，一層一層往上搭上去，每一層都與前一層息息相關，因此打好基礎就非常重要， 右下角這張圖就是一個非常簡單的示意圖，越底下的部分就是專案越重要的基礎， 我後面會解釋我們是怎麼一步步做到，以及每一步背後的思考邏輯是什麼。 這個流程的最主要的目標是希望在合理的範圍內，讓團隊能一起做出最理性的決定， 因此，團隊中大部分的成員都要是能理性溝通的人才能成立， 尤其是帶領團隊的領導者必須以身作則，我後面也會分享如何讓團隊理性溝通的方法。 === 敏捷開發wiki https://zh.wikipedia.org/zh-tw/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91 敏捷開發宣言： 個人與互動：重於流程與工具 可用的軟體：重於詳盡的文件 與客戶合作：重於合約協商 回應變化：重於遵循計劃 個人和互動：自我組織和動機是重要的，像共同定位和雙人程式開發，這樣作業模式中的溝通是重要的。建立一個良好的溝通和協作的開發團隊，優於一個孤立運行的專家團隊。溝通是一個基本的概念。 工作軟體：工作軟體比在會議中向客戶呈現檔案更有用並更受歡迎。最好的做法是和程式碼一起評論，保持外部檔案的輕量化，而不是沉重的檔案，後者需要花費很大的精力，且很快就會過時。 客戶協作：在軟體開發週期的初始階段，需求無法完全收集，所以最好直接涉及到付費客戶、最終使用者或者代理，以便在回饋的基礎上逐步闡述和調整詳細的需求。 回應變化：敏捷軟體開發方法的重點是快速響應變化和持續發展。 前期討論 - 專案的目的 發大財? 練身手? 創意性/藝術性展示? 得獎? 其他? 還是以上多個? 請跟團員充分討論以後 列出一個或多個目的，再排出優先順序 … 細節 系統 設計支柱 專案的目的 專案的願景 讓我們從最基礎的部分開始講起： 在開始開發任何東西以前，必須先釐清的東西是：團隊做這個專案的目的到底是什麼? 是為了賺錢發大財？ 還是你們是個新團隊在練身手? 或是你只是想要發揮創意? 還是目標是為了得獎? 在沒有取得共識以前，任何關於專案內容的討論都是沒有意義的，因為專案的目的會嚴重影響專案中的所有選擇跟決定。 請跟團員充分討論以後，列出一個或多個目的，再排出優先順序 前期討論 - 專案的目的 Why? 發大財? 為了賣更多必須為了市場做出妥協 練身手? 讓越多人看到越好 創意性/藝術性展示? 自己爽就好 得獎? 其他? 還是以上多個? 因為為了達到不同目的 專案中要注重的事情會非常不同 有共同目的，才能做出取捨跟決定 … 細節 系統 設計支柱 專案的目的 專案的願景 為什麼要討論這個呢? 因為 為了達到不同目的，專案中要注重的事情會非常不同： 以商業成功為主的專案，為了要迎合市場的喜好，往往被迫做出許多妥協，這就有可能跟創意性有衝突，甚至不少團隊會主動做市場調查來調整遊戲的內容，這在免費手遊跟服務型遊戲裡面最明顯； 以練身手或累積人氣為主的專案，目標是讓越多人看到你的遊戲越好，因此甚至會考慮低價或免費讓玩家下載，這就跟商業性有衝突； 以創意性或藝術性為主的專案可以什麼都不考慮，就跟畫畫一樣，畫家自己覺得美就好了，甚至不需要其他人的理解，這就跟前兩點都有可能有衝突。 專案的目的可以不只一個， 以記憶邊境為例： 因為工作室需要一定的收入才能長久營運下去， 但我們都從原本的工作離職出來創業了，還是希望能做自己想做的專案， 所以我們的目的就是希望能兼顧商業性跟創意性， 因此在開發過程中，除了少數我們堅持不能改變的東西以外， 我們都願意配合發行商做的市場調查跟玩家測試，多次調整遊戲的內容和美術設計，以結果來看，這些調整都非常正確而且重要的。 很多團隊會把專案的目的當成理所當然而不去討論， 但一個團隊裡面有那麼多人，每個人心中想達到的目的往往非常不一樣， 當團隊成員對於專案的目的不同，在討論事情時，就很容易出現雙方講的都有道理，但卻互相衝突的狀況， 這就是因為那些解法都是對的，只是朝著不同的目的前進， 只有整個團隊一起講清楚，把優先順序排出來以後，未來在開發過程遇到衝突時才有辦法做出取捨跟決定。 前期討論 - 專案的願景 願景 (Vision)： 願景就是一款遊戲完成時的全貌 如何判斷願景是正確的？ 讓團隊覺得： 對！這就是我們要做的遊戲 讓團隊以外的人： 快速理解你的遊戲甚至腦中浮現畫面 … 細節 系統 設計支柱 專案的目的 專案的願景 在決定完專案的目的以後，下一個要討論的就是專案的願景(Vision)， 什麼是願景呢? 願景就是一款遊戲完成時的全貌； 也可以說是如何用一句話或一段話讓別人理解你的遊戲是什麼； 對一些遊戲來說，甚至會直接把願景放在Steam商品頁上當作遊戲簡介。 畫面右上角的圖片就是記憶邊境Steam頁面上的敘述，大家可以跟我一起看過去。 在第一句話裡面我們先提到了遊戲的類型，「記憶邊境」是一款高難度的動作角色扮演遊戲又稱類魂，讓玩家可以快速想像一個基本的遊戲畫面； 在第二句話裡面，我們提到了這款遊戲的玩法跟特色：快節奏戰鬥系統跟瘟疫武器系統，聽到這裡玩家腦中就會開始想像快節奏的類魂遊戲，然後好奇瘟疫武器系統是什麼； 最後幾句話，我們則是快速帶過一些故事與世界觀，讓玩家可以想像這款遊戲是發生在怎樣的背景之下。 願景的寫法有很多種，大家不一定要參考我們的格式。 如何判斷願景是正確的呢？ 當團隊成員看著這段話的時候，心裡會覺得：對！這就是我們要做的遊戲。 而團隊以外的人聽到的時候，能快速理解你的遊戲甚至腦中浮現畫面。 以上兩點都是好的徵兆。 — 記憶邊境Steam商品頁 https://store.steampowered.com/app/1343240 前期討論 - 專案的願景 Why? 確保開發的過程中，所有人都是往同一個方向前進 製作人最重要的工作就是確保大家都擁有一致的願景 製作人還必須確保每個決定都符合願景 願景是有可能改變的，團隊要定期測試跟檢查 提早做好願景可能改變的心理準備 有問題要立刻提出來討論 改變願景不是世界末日，但必須整個團隊一起決定 為什麼要討論願景呢? 願景最主要的功能是：確保在開發的過程中，所有人都往同一個方向前進 就像專案的目的一樣，大家對專案完成時的想像也通常很不一樣， 以記憶邊境為例，儘管我們開發的類魂遊戲聽起來好像已經很清楚明顯了， 事實上，市面上就有一堆很不一樣的類魂遊戲，光FromSoftware自己都出了一堆不同的魂系遊戲：動作慢的有魂1~3，動作快的有隻狼，介於中間的是血源跟艾爾登法環， 如果團隊沒有討論清楚遊戲做完應該長怎麼樣，很容易程式美術企劃大家各做各的東西，而遊戲開發最怕的就是大家像無頭蒼蠅一樣到處亂飛， 因此在開發時，遊戲製作人最重要的工作就是確保大家都擁有一致的願景。 除此之外，在開發時，大部分的人都會專注在自己的工作領域中，通常只有遊戲製作人能看到各個領域組合起來的全貌， 所以遊戲製作人還必須確保團隊的每個決定都符合願景，最後完成的遊戲才會是和諧一致的。 在製作過程中，團隊對於遊戲的願景是有可能改變的： 可能是發現原本的設計做出來後並不好玩、 也可能只是需要稍微改變優先順序或敘述方式、 也可能因為開發過程學到新的知識發現原本的願景是不可能達成的...等， 因此，團隊要定期測試跟檢查遊戲的願景是否改變，也要提早做好願景可能改變的心理準備。 以我們團隊為例，我們每個里程碑完成後都會包版本做內部測試， 除了檢查遊戲的功能和美術以外，團隊也要思考繼續朝著這個方向做下去是否正確， 如果覺得有任何問題就要立刻提出來大家一起討論，看這個問題是否只是東西沒做完整造成的，還是原本的願景有根本上的問題。 改變願景不是世界末日，但必須整個團隊一起決定。 前期討論 - 設計支柱 設計支柱是團隊預計達成願景的方式 列出3個左右，然後按照重要順序排列。 以記憶邊境為例： 1. 流暢的戰鬥系統 2. 黑暗幻想的美術風格 遇到衝突時，可以根據順序做決定 … 細節 系統 設計支柱 專案的目的 專案的願景 在知道遊戲完成時的全貌以後， 我們就能反推回來，並列出團隊預計達成願景的幾個主要方式，這就是設計支柱。 一般來說我們會列出3個左右，然後按照重要順序排列。 以記憶邊境為例，要完成我們的願景，我們討論出來的設計支柱有兩個： 流暢的戰鬥系統跟黑暗幻想的美術風格 這兩點對我們來說是最重要的，其他像是故事情節、關卡設計...等，都是次要的，關於這點，大家應該可以在我們遊戲的成品中明顯地感受到。 按照重要順序排列的原因是：當開發遇到設計支柱互相衝突時，我們才能依照順序來快速做決定， 舉例來說，在記憶邊境開發中期時，我們為了讓一個場景看起來很豐富，美術就堆了很多雜物在裡面， 但雜物太多就很容易卡到玩家的鏡頭，或是卡住主角跟敵人的移動路線， 最後決定為了戰鬥的流暢度，我們必須拓寬走道，並且對雜物的數量、大小跟碰撞都有一定的規範，這就是順序存在的目的。 === Design Pillars by Max Pears https://www.gamedeveloper.com/design/design-pillars-the-core-of-your-game 前期討論 - 系統跟特色 設計支柱 1 系統或特色 1 細節or工作事項 (通常留到寫文件的時候討論) 系統或特色 2 設計支柱 2 系統或特色 3 設計支柱 3 系統或特色 4 系統或特色 5 … 細節 系統 設計支柱 專案的目的 專案的願景 在訂出幾個設計支柱以後，我們可以再進一步往下拆解，列出每一個設計支柱預計要用那些系統或特色來達成， 有需要的話，這些系統跟特色都還能夠繼續往下拆解，直到變成可以實際執行的工作事項為止， 但通常我們會等到寫文件的時候才討論細節跟工作事項的部份，我們這邊先停在系統跟特色就好。 前期討論 - 系統跟特色(以記憶邊境為例) 流暢的戰鬥系統： 爽快又緊湊的戰鬥：進攻、閃躲、招架構成緊湊的攻防，再以華麗的處決作為收尾 魂系敵人設計：學習敵人的行動，並在對的時間作出正確的回應 自訂戰鬥風格：玩家可自由改變天賦與特殊攻擊打造適合自己的遊玩風格 黑暗幻想的美術風格： 陰沉的場景與敵人設計令玩家彷彿置身瘟疫肆虐的絕望國度 … 細節 系統 設計支柱 專案的目的 專案的願景 以記憶邊境為例子， 前面我說過我們的兩個設計支柱是：流暢的戰鬥系統跟黑暗幻想的美術風格 這兩點單純看起來還是太抽象，於是我們就把他們拆解成更具體的系統或特色。 以流暢的戰鬥系統來說，我們拆解成三個部分，一樣從上到下根據重要順序排列： 最重要的是爽快又緊湊的戰鬥，再來是魂系敵人設計， 除了以上兩點以外，我們也很想做出一個能讓玩家高度自訂的戰鬥系統，於是有了第三點自訂戰鬥風格。 以美術風格來說，瘟疫是我們遊戲中貫穿美術跟故事的主題，因此場景跟敵人的設計也必須反應這一點。 前期討論 - 總結(以記憶邊境為例) 目的：希望做出一款兼顧商業性與創意性的遊戲 願景：「記憶邊境」是一款高難度的動作角色扮演遊戲，有著快節奏戰鬥系統跟獨特的瘟疫武器系統。 在死亡蔓延的國度中，扮演一位代號「掠鴉」的神秘人物，掠奪瘟疫、武裝自己，並在一次次回憶中找尋真相。 設計支柱： 流暢的戰鬥系統： 爽快又緊湊的戰鬥：進攻、閃躲、招架構成緊湊的攻防，再以華麗的處決作為收尾 魂系敵人設計：學習敵人的行動，並在對的時間作出正確的回應 自訂戰鬥風格：玩家可自由改變天賦與特殊攻擊打造適合自己的遊玩風格 黑暗幻想的美術風格： 陰沉的場景與敵人設計令玩家彷彿置身瘟疫肆虐的絕望國度 細節 系統 設計支柱 專案的目的 專案的願景 … 最後，我們就會得到畫面上這一整份文字， 從最基礎的專案的目的開始，每一步都會仔細說明如何做到前一步。 以記憶邊境為例，我們工作室對第一個專案的的目的是希望能做出一款兼顧商業性與創意性的遊戲， 那我們要如何達成這一步呢? 答案：是做出一款名叫記憶邊境的高難度動作角色扮演遊戲。 那具體來說記憶邊境是一款怎樣的遊戲呢? 答案：一款擁有流暢的戰鬥系統跟黑暗幻想美術風格的遊戲。 那我們預計如何做到這個戰鬥系統跟美術風格呢? 我們決定採用下面這些特色與系統來做到。 寫到這裡，團隊對於遊戲完成的畫面就會越來越清晰，也會越來越清楚需要製作那些內容來達成這個願景。 前期討論 - 總結 Why? 從根本開始討論，任何事情都有源頭 任何爭執都能往回找到原因 所有事情都有上下之分、優先順序 遇到爭執時就能快速做出決定 真的遇到問題時，再回頭修改 多次討論以後，團隊會越來越清楚共同在意的點 會有越來越多不會被動搖的共識，願景越來清晰 … 細節 系統 設計支柱 專案的目的 專案的願景 這讓我邊來總結一下為什麼前期要花那麼多時間討論這些東西呢？ 首先，我們從做專案最根本的目的開始討論，讓一切事情都有一個共同的源頭， 意思就是如果開發過程發生任何爭執的時候，我們永遠都可以回頭找到當初為什麼決定要做這件事情的原因。 而所有事情都有上下之分、優先順序時，團隊遇到爭執時就能快速做出決定， 像我前面提到的例子，當美術搭的場景跟遊戲玩法有衝突時， 因為我們共同決定這款遊戲的戰鬥比美術優先，於是美術這邊必須讓步， 類似的東西如果沒有在開發前期就討論好，很容易發生兩個部門各執一詞的狀況， 因為每個部門一定都覺得自己的東西最重要，無論誰被犧牲都會不服氣，久而久之團隊成員間很容易出現問題。 不過，儘管這個方式聽起來再怎麼美好，還是有可能遇到無法解決的問題， 有可能是團隊對願景的理解有誤，也有可能是誤判事情的優先順序， 這時候就是團隊該坐下來討論跟修改的時候，這也不是什麼大事， 事實上， 經過幾次這樣的討論以後，團隊反而會越來越清楚共同在意的點是什麼， 最後的結果就是，會有越來越多不被動搖的共識，團隊對於遊戲的願景也會越來越清晰跟一致。 開發前規劃 (Pre-Production) 再來，我們進入開發流程的部分， 首先是開發前的規劃。 開發前規劃 - 開發文件 所需文件： 遊戲設計文件 系統與素材 里程碑與工作規劃 金流追蹤與預算規劃 在把專案的基礎釐清以後，接下來就是要把前面討論完的東西紀錄下來， 這邊是遊戲開發必須有的基本文件，我接下來會快速講過每一份文件裡面必須有的內容。 開發前規劃 - 開發文件(遊戲設計文件) 目錄 願景與設計支柱 特色與系統 玩法介紹：操作、鏡頭、遊戲流程...等 故事：世界觀、角色介紹...等 美術風格：角色概念圖、關卡概念圖...等 文件要定期更新： 讓新成員或外部成員快速了解專案的全貌 開發過程有任何疑問，也能找到當初決定的原因 一般來說，一個專案至少會需要一份遊戲設計文件，裡面用來紀錄這個專案的所有重要資訊， 文件的格式我會參照前面討論的順序，從最基礎的開始記錄，像是：願景、設計支柱、特色與系統...等。 然後，我會順著前面討論的順序繼續往下拆分，並列出其他要完成遊戲必要的設計與規劃，像是：遊戲的玩法、故事細節、美術風格與概念圖...等。 根據專案的複雜程度而定，有可能除了遊戲設計文件以外，團隊還需要分出額外的文件來記錄其他資訊，像是：美術的風格文件、程式的技術規範文件、企劃的關卡設計文件...等， 我這邊沒有時間細講每份文件裡面需要紀錄那些資料，大家可以上網找範例。 專案後續有任何改變時，文件的內容應該也要一起更新， 如此一來如果有新成員加入或外部成員想知道時，他們才能夠快速了解專案的全貌， 開發過程，如果有人對任何事情有疑問或爭執時，也能找到當初為什麼要做某個決定的原因。 === Moving Out 2 - Art Style Guide https://docs.google.com/document/d/1Wd4XNoHxzOjF1_0PUfusC_uVoIfb-ppaDqc9_-ztCuE/edit 開發前規劃 - 開發文件(里程碑與工作規劃) 里程碑的目標可以是外部決定也可以是內部決定 先訂出每個里程碑的主要目標，再往下逐步拆分 預估任何工時至少多抓20%預留時間給突發事件 越不熟的工作要抓越多預留時間 上市後，要預留1~3個月的維護時間 擺不下的東西放入願望清單，有空回來圓夢 每個里程碑結束後，回顧並調整後續的工作規劃 誠實檢討能增加效率跟預估準確度 在遊戲設計文件完成以後，接下來就是要討論遊戲開發的里程碑跟工作規劃。 里程碑指的是團隊根據時間或特定目標，把遊戲開發的過程切成多個分段方便規劃與檢查，這邊的每一個分段我們就稱為一個里程碑。 里程碑的目標可以是外部決定也可以是內部決定： 外部決定的例子像是為了參展要打包一個試玩版本、要給發行商檢查或是遊戲要趕發行日期...等等。 內部決定的例子我後面會提供一種格式給大家參考，這邊先跳過。 團隊要用任何工具來紀錄里程碑跟工作規劃都可以，像我們就是用Google Sheet畫類似甘特圖的表格而已，大家可以看右下角的範例圖， 我有在這份簡報的演講者備忘稿裡面附上我們使用的里程碑跟工作規劃的範例文件，大家要使用只要建立副本就可以。 規劃里程碑時，團隊要先討論出該里程碑的主要目標， 然後每個部門再寫下要完成這個主要目標需要的大工作項目，再根據這些大項目逐步拆解成小的工作項目， 拆解完後，再把這些工作項目填到工作規劃表裡面，像是右下角那樣。 預估一個工作事項的工時的時候，我習慣多抓20%左右的預留時間給突發事件與雜事， 越不熟的工作要抓越多預留時間，因為我們寧願事情提早做完，也不要事情做不完被逼著砍東西。 按照優先順序把工作規劃排滿以後，一定還會有一堆塞不下的事情，這時候我們會先整理到一份願望清單裡面， 未來有人事情提早做完時，可以回來圓夢，這樣也可以鼓勵大家努力完成手上的工作。 進入正式開發以後，每個里程碑完成時， 我們都會花上至少一天開一個會議回顧這個里程碑任何我們認為有問題的地方：檢討工作流程、製作方式、預估工時...等任何事情， 然後在下一個里程碑開始以前，盡量把問題修正，並重新調整下一個里程碑的工作規劃和預估工時， 這個步驟重複幾次以後，團隊的工作效率就會越來越高，預估的工時也會越來越準確，但前提是每個成員都要誠實面對專案跟自己。 最後，遊戲絕對不是做完上架就沒事了， 無論你做的是怎樣的遊戲，上市後都要預留至少一到三個月的維護時間以防萬一。 === 里程碑與工作規劃範例文件 https://docs.google.com/spreadsheets/d/1T9J8YZObVHC3Axw_FoN3xkDk4vid7OoO/edit#gid=2118261295 從遊戲的設計支柱開始，一圈一圈往外延伸 只有在確定核心可以完成時，才能繼續往外 當開發時間不夠時，就能從最外圈開始砍內容 對遊戲完成的樣貌要有多個計畫 開發前規劃 - 系統與素材 設計支柱 1 核心系統/素材 周邊系統/素材 以上兩份文件，都牽扯到如何規劃一款遊戲的系統跟素材，我這邊先忽略設計的部分，單純從專案管理的角度討論如何規劃。 開發遊戲時，任何東西都要錢跟時間，而這兩種東西都是獨立開發最缺的。 在錢跟時間都不能增加的狀況下，你一時興起加入了A素材，那就代表另外有一個B素材不能做，因此我們絕對想到就亂加東西。 那怎麼加才是合理的呢? 答案就是從前面討論過的設計支柱出發，一圈一圈往外延伸， 畫面右下角的圖是我拿一個支柱當範例， 環繞著設計支柱旁邊的核心系統跟素材，就是團隊討論過後，要完成這個設計支柱的最低需求， 理論上，當製作完這些核心系統和素材並組合在一起以後，支柱1就應該要成形了。 以此類推， 我們必須確保支柱1, 2, 3都優先完成了核心系統與素材，才能繼續往外製作周邊系統跟素材， 如此一來，當開發時間不夠時，我們就能從最外圈開始砍內容而不會影響遊戲的核心部分。 當然就算是從最外圈開始砍，也不是隨便亂砍內容就可以，我們對遊戲完成的樣貌有多個計畫， 大家應該都看過類似畫面左下這張，如何開發最簡可行產品的示意圖， 假設我們的目標是把人類從A點運送到B點，在擁有足夠時間的狀況下，上下兩個團隊最終都會做出一台汽車， 但當時間不夠時，就算只缺一點點，上面團隊做出來的產品就無法做到我們的要求， 而下面的團隊則無論停在每個步驟都能把人從A點送到B點。 遊戲開發時，我們要學習下面那個團隊的心態， 我們的目標都是完成同一個願景，但是完成的方式跟專案的大小可以有很多種。 === The Coalition團隊高級製作人Venessa Nyarko分享如何把“講故事的錢”花在刀口上？ http://www.gamelook.com.cn/2023/09/527205 左下範例圖片來源： https://www.dreamstime.com/minimum-viable-product-mvp-development-steps-explanation-outline-diagram-minimum-viable-product-mvp-development-steps-image233077584 流暢的戰鬥系統： 爽快又緊湊的戰鬥：進攻、閃躲、招架構成緊湊的攻防，再以華麗的處決作為收尾 魂系敵人設計：學習敵人的行動，並在對的時間作出正確的回應 自訂戰鬥風格：玩家可自由改變天賦與特殊攻擊打造適合自己的遊玩風格 黑暗幻想的美術風格： 陰沉的場景與敵人設計令玩家彷彿置身瘟疫肆虐的絕望國度 開發前規劃 - 系統與素材(以記憶邊境為例) 美術風格 Boss房 可探索關卡 戰鬥系統 主角與敵人 自訂戰鬥風格 以記憶邊境為例，前面說過我們的核心有兩個：流暢的戰鬥系統跟黑暗幻想的美術風格。 而我們認為要完成流暢的戰鬥系統最核心的需求是主角的戰鬥系統跟魂系的敵人設計， 因為只要有主角跟敵人，這個遊戲就可以玩了， 再搭配上幾個Boss房，就做出了一款專打Boss的遊戲， 事實上，記憶邊境最早的規劃就是只開發一年半，然後內容只有多個Boss戰。 我們是在開發一段時間以後，確定我們有足夠的時間跟能力完成核心的部分， 加上後來得到發行商的幫助，我們才決定將遊戲內容繼續往外延伸， 在戰鬥系統的部分新增了第三點自訂戰鬥風格，就是遊戲中的瘟疫武器跟天賦系統； 然後在美術風格這個部分新增了連結Boss房之間的可探索關卡。 但這不代表我們就沒有砍掉任何東西， 我們原本打算製作更多關卡跟Boss，但因為時間不夠而被迫縮減了好幾次， 我們還砍掉了一個貫穿整個遊戲的系統，因為我們沒時間做到讓自己滿意的程度， 就像我說的，團隊要對遊戲完成的樣貌有多個計畫，並隨時根據開發的狀況調整，而不是堅持要製作那個心目中完美但永遠做不完的遊戲。 開發前規劃 - 開發文件(金流追蹤與預算規劃) 詳細記錄所有開銷，且每一筆都有明確的原因 即使是學生團隊或新團隊，最好每個人都有支薪 紀錄金流一段時間以後，才能做出專案預算規劃 這些紀錄在未來會非常重要 投資人跟發行商會想知道你的預算規劃跟金流 建立正確的金錢跟預算觀念 工作室想長久經營下去必要的資訊 最後一份文件是金流追蹤跟預算規劃，我們也是簡單使用Google Sheet紀錄而已。 我非常建議大家記錄下來開發時的所有開銷，而且每一筆支出都要有明確的原因， 如此一來才不會莫名其妙就沒錢了，也可以在資金用完之前，提早去找錢。 除此之外，無論你是學生團隊還是新創團隊，最好每個人都要拿薪水， 即使是拿最低薪資也好，這樣才能讓團隊有正確的金錢跟預算觀念， 記錄金流一段時間以後，通常是完成前幾個里程碑的時候， 團隊就能知道開發時所有可能的開銷，也才能根據這些開銷預估完成整個專案需要的開發費用是多少。 未來，無論你要找投資人還是發行商，他們都會想知道你的預算規劃跟金流長怎樣， 如果你講不出來，或者跟對方說你沒有支薪，單純靠熱情在做，你很難說服對方你們是認真而且有經驗的團隊， 這時候，對方要嘛是不理你，要嘛就是開出一個不合理的投資方案， 如果你們沒有正確的金錢跟預算觀念，很容易就把自己辛苦開發的遊戲賤賣給別人了。 最後，就算你不需要投資人跟發行商， 只要工作室想要長期營運下去，預算規劃跟金流控管也是必要的知識之一， 你現在不面對，未來遲早也需要面對。 正式開發 準備完以上的文件以後，總算可以進入正式開發了！ 概念發想 Brainstorming 概念驗證 Proof of Concept 技術驗證 Proof of Technology 白盒 Whitebox 遊戲玩法 Gameplay 垂直切片 Vertical Slice 量產階段 Mass production 打磨階段 Polish 正式開發 遊戲的正式開發階段一般來說我們大略會分為下面這些里程碑， 但每間公司都有自己的分法跟名稱，我這邊只是介紹其中一種讓大家參考一下。 正式開發 - 概念發想與驗證 概念發想 Brainstorming 用任何團隊喜歡的方式來做 概念驗證 Proof of Concept 用最簡單的方式，在最短的時間內驗證概念是否真的可行 技術驗證 Proof of Technology 確保團隊有完成這款遊戲所需的技術與能力 這三個其實不太算是正式開發階段 願景跟設計支柱也是在確定遊戲概念以後才能開始討論 首先，最前面三個階段：概念發想、概念驗證、技術驗證，有時候不會被認為是正式開發階段， 因為在這三個階段裡面，通常團隊還不知道到底要做怎樣的遊戲。 而且前面提到的願景跟設計支柱也都是要在確定遊戲的基本概念以後才能開始討論， 但這不代表這三個階段不重要，相反地，很多事情在這裡先釐清以後，就能省去後面可能浪費的大量時間跟金錢。 第一，概念發想可以用任何團隊喜歡的方式來做，我這邊就先跳過了。 第二，概念驗證 當團隊有一個喜歡的遊戲想法以後，就要試著用最簡單的方式，在最短的時間內快速驗證這個概念是否是真的有趣，還是只是聽起來好玩而已。 舉例來說： 如果你們在做一款敘事遊戲，那最大的重點是故事， 這時候至少要寫出一個章節的故事，然後拿給團隊成員、認識的開發者或身邊的親朋好友看，確定你們有能力寫出好故事以後，才有繼續開發下去的本錢； 如果你們遊戲的核心是玩法，那就要找到最簡單的方式讓團隊可以玩到那個玩法， 這邊說的玩到不一定代表要馬上開始寫程式，很多遊戲玩法或概念可以很簡單用紙筆或是角色扮演來驗證， 就算無法真的玩到，模擬一下遊戲流程，也能快速看到是否有在討論時沒有想到的缺點跟漏洞。 第三，技術驗證 當團隊真的覺得某個概念夠好以後，在正式開發前的最後一步，就是確保團隊有完成這款遊戲所需的技術與能力， 以記憶邊境來說，我們要做一款類魂遊戲，而且我們認為最重要的東西是戰鬥，所以我們最一開始製作的就是一個Boss戰的Demo。 當然，有很多問題可能是在開發過程中才會發現的，我這邊也不是在要求大家在開發前就花大量時間在做技術研究， 團隊不一定要把整個玩法做出來，但一定要花一點時間研究你們想做的東西，看團隊是否有能力做到、是否理解背後的技術、是否腦中有個路線圖，而且能在合理的時間內完成。 === Designing 'MARVEL SNAP' by Ben Brode (裡面就提到他們用名片的背面驗證遊戲玩法) https://www.youtube.com/watch?v=HjhsY2Zuo-c Horizon Zero Dawn - Early Prototype and Beta Gameplay (Horizon Zero Dawn最早是修改工作室前一款遊戲的系統來驗證機械獸的玩法概念) https://www.youtube.com/watch?v=1rm55FDYbic 正式開發 - 白盒 重點：確定關卡內的規格 使用簡單的幾何形狀就好 不要浪費時間在視覺上 程式：確定規格後，專心於遊戲核心相關的功能開發 美術：確定美術風格與關卡內的各種規格 企劃：搭建白盒關卡，幫助美術確定關卡裡面的各種規格 驗證完概念後，接下來就是白盒階段，這個階段最重要的目標是確認關卡內的規格： 從主角的身高、一個門的寬度、一個房間的大小、一個地區的範圍，甚至到一整個遊戲世界，我們都要盡量在這個階段抓出大小跟規格。 有些遊戲沒有明確的關卡之分，也可以切割成章節或某個遊玩片段來檢視。 就算是單純的視覺小說或是戀愛遊戲，你也要確定每個UI跟每張圖在畫面上的位置跟比例，程式才知道怎麼寫code，美術也才知道出圖的大小，以及圖片會怎麼被使用。 這個階段主要的工作會落在美術跟企劃身上， 因為無論遊戲是2D或3D，美術都要知道遊戲中的大小規格才有辦法製作素材，， 還需要注意的是，這個階段的重點是規格，因此搭建關卡用簡單的幾何形狀就好，不要浪費時間在視覺美感上。 程式在這個階段除了幫忙確定規格以外，就可以先去開發遊戲核心相關的功能。 正式開發 - 遊戲玩法 重點：遊戲核心玩法或功能初步完成 初步完成的意思是未來還會繼續開發 至少一個關卡要能簡單從頭玩到尾 程式：遊戲核心玩法或功能初步完成 美術：開始製作核心相關的美術素材 企劃：將功能放入白盒關卡，盡量讓所有白盒關卡能從頭玩到尾 確認完尺規後，再來就是確認遊戲的玩法，這個階段最主要的目標是：遊戲核心玩法或功能初步完成， 初步完成的意思是未來還會繼續開發，但在這個階段我們會希望至少一個關卡要能簡單從頭玩到尾。 程式在這個階段的目標是初步完成核心的玩法或功能，讓團隊成員可以試玩這個遊戲。 而企劃則是要將這些程式完成的功能放入關卡裡面，盡量讓一個或多個白盒關卡可以從頭玩到尾。 美術則是可以看著這些可以玩的白盒關卡或者根據企劃提出的需求，開始製作核心相關的美術素材。 正式開發 - 垂直切片 重點：將遊戲中的一部分開發到上市時的完成度 團隊第一次碰到完成專案所需的所有東西 團隊可以一窺遊戲願景的最好機會 程式：將選定要完成的關卡裡面用到的所有功能完成 含：選單、基本UI、關卡管理、核心玩法...等 美術：將選定要完成的關卡裡面用到的所有美術完成 企劃：整合程式與美術資源，確保選定關卡內容與設計一致 垂直切片大概是除了最前面三個概念驗證階段以外，最重要的開發階段，但也是很少有台灣團隊知道要做的階段。 這個階段的目的是要把遊戲中的一個部分開發到接近遊戲上市時的完成度，這邊的一個部分通常指的是一個關卡或一個章節。 為什麼我會說這個階段這麼重要呢？ 因為這個階段可以讓團隊第一次碰到完成專案所需的所有東西， 如果有任何做不出來的東西，或是有某個工作所需時間超過想像， 這個階段就會卡住，團隊必須立刻坐下來檢討。 此外，這個階段也是團隊可以一窺遊戲願景的最好機會， 在白盒或者遊戲玩法階段，遊戲不好玩都還有理由，到了垂直切片如果遊戲還不好玩就有大問題了， 因為下一個階段就要進入量產階段，團隊必須在投入大量時間與金錢以前釐清不好玩的原因是什麼，絕對不能硬著頭皮做下去，期待未來遊戲會突然變好玩。 程式在這個階段，目標是把遊戲從開始到完成指定關卡過程中，會碰到的所有功能都完成，包含：主選單、關卡讀取、核心玩法、基本UI...等。 而美術跟企劃的目標則是盡量把一個關卡做到上市時的完成度。 在成功完成垂直切片階段以後，是團隊第一次知道完成一個關卡大約需要多少時間跟金錢，所以完成這個階段後的檢討會就非常重要。 最後，垂直切片的成品，因為完成度夠高，很適合拿來找投資人跟發行商，或是放到Steam上當Demo吸引玩家，或是使用已經完成的遊戲內容製作行銷資源，開始經營社群媒體跟Steam頁面。 以我個人經驗來說，只有成功通過垂直切片的專案才真正進入正式開發。 === 獨立遊戲行銷，從開案到上市 by Ross Huang Youtube影片：https://www.youtube.com/watch?v=C9PIe-s_4h8 Google簡報：https://docs.google.com/presentation/d/16jFw0rir9c_GvJQXVaEp-rpVR490o9p7xaKpRYBnuFY/edit#slide=id.p 正式開發 - 量產階段 重點：持續完成遊戲所有功能、關卡與美術 通常會根據開發時間或開發內容切分出多個檢查點 程式：繼續開發與更新遊戲功能 美術：完成遊戲所有美術 企劃：幫忙美術與程式整合資源進遊戲，並持續完成與打磨關卡 量產階段就很直白了，基本上就是延續前面的規劃，繼續把整個專案剩下的內容完成， 通常我們會根據開發時間或內容切出多個檢查點，像是每幾個月檢討一次，或是每完成一個關卡檢討一次， 以記憶邊境來說， 因為我們垂直切片階段花了大約三個月的時間，所以量產階段我們也是每三個月設置一個檢查點， 每個檢查點結束後團隊一樣要開檢討會議，避免量產階段有隱藏的問題一直在拖慢開發進度。 正式開發 - 打磨階段 重點：不可再增加任何資源，只能打磨跟除蟲 建議保留總開發時間的20~25%給這個階段 打包 > 測試 > 檢討 > 修正 > 打包...，根據團隊的速度設立多個檢查點 盡量尋找自己遊戲的目標客群來測試或有類似經驗的開發者幫忙 程式：所有功能完成，只能打磨跟除蟲 美術：所有美術完成，打磨美術素材、製作行銷素材(海報、宣傳片) 企劃：所有關卡完成，打磨跟除蟲關卡，幫忙製作行銷素材(新聞稿) 最後一個階段是打磨階段，最大的重點就是不能再新增任何資源， 這邊講的資源包含程式的功能、遊戲關卡跟美術素材，所有更新都只能是為了修Bug或讓遊戲體驗更好， 從這個時候開始，團隊要開始頻繁進行遊戲測試，事實上，我建議大家每個里程碑結束都至少要進行一天的內部測試與檢討，才能盡早發現問題盡早處理。 根據個人經驗，我建議一個團隊至少保留總開發時間的20~25%給打磨階段， 如果你的開發時間是一年，你就需要保留2~3個月的時間打磨；如果如果開發時間是兩年，那就可能需要6個月左右， 因為開發時間越久，通常一個專案裡面的東西會越多、系統之間的相關性越複雜，可能出問題的點也會越多，因此就需要越長的時間來打磨與除錯。 在這個階段， 團隊就是不斷打包、測試、檢討跟修正，然後不斷重來， 我會建議在可行範圍內，重複以上步驟越多次越好。 除了開發團隊自己內部測試跟找親朋好友幫忙以外，能找到自己遊戲的目標客群來測試是最好的，但因為獨立團隊通常很難做到這一點； 因此我建議大家可以找身邊認識的開發者幫忙，最好是找有類似開發經驗的團隊，或是你知道他喜歡你遊戲類型的開發者；通常他們會給比較好的建議， 除此之外，現在Steam每年三次新品節也是很好的測試機會，除了能拿到大量目標客群的回饋以外，還能趁機累積願望清單， 但要記得，一款遊戲一生只能參加一次新品節，我會建議大家參加遊戲上市前的最後一次，確保Demo版本的品質跟上市的品質最接近，效果也會最好。 === 獨立遊戲行銷，從開案到上市 by Ross Huang Youtube影片：https://www.youtube.com/watch?v=C9PIe-s_4h8 Google簡報：https://docs.google.com/presentation/d/16jFw0rir9c_GvJQXVaEp-rpVR490o9p7xaKpRYBnuFY/edit#slide=id.p 開發完成後 在遊戲開發完，上市後，除了一定要做的修bug和更新以外， 開發完成後 事後檢討 做錯什麼？ 遊戲內容、開發階段、開發流程、生活上的大小事...等 作對什麼？ 遊戲內容、開發階段、開發流程、生活上的大小事...等 學到了什麼？ 未來該做什麼跟不該做什麼 專案的事後檢討也很重要，我習慣會從三個方向下去討論： 做錯什麼？ 首先，我們可以從最簡單的開始討論，就是做錯了什麼事情， 有可能是美術風格選錯或者專案的規模太大，到辦公室位置不好都可以， 如果覺得太廣泛的話，也可以從遊戲開發的各個階段或者是遊戲的各個部分開始檢討。 作對什麼？ 在講完壞事以後，團隊可以討論一下那些事情是對的，跟上面一樣，這邊可以分享任何事情。 學到了什麼？ 最後，我們結合前面兩點， 開始整理以整個團隊來講，我們學到了什麼， 這邊，我們通常可以把事情整理成：未來該做什麼跟不該做什麼。 就跟每個里程碑結束的檢討會議可以讓下一個里程碑更順暢一樣，一個專案結束後的檢討會議也可以讓下個專案更好。 加速開發的觀念分享 接下來，我會分享一些，我們在開發過程中學到，能加快開發速度的觀念跟小技巧。 加速會議的方式 會議前： 訂出會議的主題(越明確越具體越好)，會議結束時，一定要有結論 預估會議的長度，時間到就結束會議(釐清原本議題也是結論之一) 提早預告會議的內容，讓成員有機會準備 只要求相關人士出席，其他人可以自由參加 會議中： 講清楚這次會議的結果可能影響什麼 一次討論一個議題，任何離題內容都先記錄下來 釐清想要達到的目的，再討論可行的方式 不要預設其他人知道你在想什麼，使用實際畫面或範例解說 會議後： 除了記下會議的結果以外，討論的過程與做決定的原因也要記錄 集中整理所有會議紀錄供未來參考，避免重複討論 遊戲開發中，有很大一部分時間花在開會上，但這些會又不能不開，因此如何加速會議就非常重要， 在嘗試過各種方法以後，我這邊統整出幾個我認為非常有用的步驟： 會議前： 1. 首先，在安排會議前，要確定會議的主題是什麼，越明確越具體越好，因為我們希望在每個會議結束時，一定要有結論。 2. 再來，為這個會議抓一個預估的時間，時間到了就要結束會議，讓成員回去做原本該做的事情， 如果時間到了還沒有結論怎麼辦? 會議過程中，如果發現要討論的議題明顯比原本預估的還複雜，那就要將原本議題切分成多段來討論，這個也是結論的一種。 3. 在會議開始前，就要跟團隊預告會議的主題，讓與會成員可以提早準備，而不是到了現場才開始思考。 4. 在跟團隊預告會議時，只要求相關人士出席，但其他有興趣的人也可以自由參加，如此一來可以盡量避免有人在會議上發呆的狀況。 會議中： 1. 會議開始後，要先跟與會人員講清楚這次會議的結果可能會影響到什麼，讓團隊理解接下來的發言可能造成的結果，才能避免開始執行時後悔的狀況。 2. 會議中，一次只討論一個議題，任何離題的內容全都要先記錄下來然後回到原本主題，如果離題的內容裡面有重要的東西，則在會議結束後再安排新的時間討論。 3. 在討論一件事情時，團隊要先釐清想要達到的目的是什麼，然後再去思考要怎麼達到這個目的，而不是一開始就在討論不同做法的好處跟壞處，在沒有訂出目的跟標準以前，這些比較都是沒有意義的。 4. 討論過程中，千萬不要預設其他人知道你在想什麼，或是預設其他人知道某個詞的意思， 就像我前面舉過的例子，誰知道你說的類魂跟我說的類魂一不一樣，因此不要預設任何東西，最好是搭配實際的畫面或範例來解說。 會議後： 1. 除了記下會議的結果以外，討論的過程和做決定的原因也要一併記錄下來，這些都能方便未來出現疑問回頭檢視時，釐清當初為什麼要做這個決定的原因。 2. 每個會議的紀錄也要找一個地方集中整理，方便未來如果在討論類似議題的時候，可以回來翻閱，不要在同一個議題上重複開會。 加速決策的方式 先確認這個決定是"可逆"還是"不可逆" 可逆不可逆主要是看付出的代價有多高 只有不可逆的決定才需要仔細思考 如是可逆的，則盡快做出決定後立刻嘗試 投票前，列出所有可行方案，並讓團隊充分討論優缺 投票時，每個人都能投無限票 投完票後，從最高票的選項開始嘗試 如果出現同票狀況，則讓製作人決定 第一高票嘗試失敗後，從第二高票選項繼續嘗試 與其花時間爭論不確定的東西，不如多花時間去嘗試 開發過程中，團隊一定會需要作出大量決定， 除了前面講到可以加快會議效率的方式以外，我這邊也提出一些能加速做決定的方式： 1. 首先，團隊要先確認這個決定是可逆還是不可能逆的， 一個決定是可逆還是不可逆，主要是看團隊執行時需要耗費的時間與資源有多大，如果大到無法輕易重複嘗試，那這個決定就是不可逆的。 只有在遇到不可逆決定時，團隊才需要慢下來仔細思考， 只要決定是可逆的，團隊盡快做出決定，然後立刻嘗試往往是比較有效率的方式， 因為很多事情看到實際的結果以前，大家都只是在猜測跟想像而已，沒有人能保證做完某一件事情，一定會有某種結果， 這種情況下，不如把時間花在實際嘗試上會比較有意義，而不是把時間花在爭辯一個沒人知道結果的議題上。 2. 在投票前，我會讓團隊列出所有可行的方案，然後讓大家發表意見、充分討論， 盡量讓大家在投票前能對所有選項的優缺點都有足夠的理解。 3. 投票時，除非是要做出最後決定，不然我們都是習慣讓所有人有無限票， 如此一來才不會有被犧牲的第二名選項，投完票的結果也可以明顯看出整個團隊的喜好。 4. 投完票以後，我們會從第一高票開始嘗試， 如果有多個同票情形，我們會讓製作人做決定， 因為會出現同票的情形，通常代表這個問題沒有明顯的最優解，每個同票的選項都各自的優缺點， 那我們不如快點從第一高票開始嘗試，如果結果不如預期，那我們就從第二高票繼續嘗試下去。 — Type 1 vs. Type 2 Decisions https://kb.founderculture.net/public/posts/rmd3fjeg 營造鼓勵發言的環境 環境跟習慣都需要時間培養 每個人都有發言的機會，且不能任意打斷 所有發言都要被納入參考、記錄下來 討論時盡量不要否定他人想法，而是嘗試改善 如果有人違反上述規則，主持人必須立刻介入 決策的方式與過程要讓團隊信任 讓成員看到實際成果，讓成員知道發言真的會被採納 前面提到的會議跟決策都需要所有團隊成員的參與和溝通， 事實上，整個遊戲開發的過程就是不斷在溝通，所以也很多人會想知道怎樣讓團隊成員更願意發言， 我的經驗是，這是一個環境跟個人習慣的問題，而這兩個東西都需要時間來培養， 我們能做到的是創造一個可以自由發言的環境，個人習慣的部分則要靠每個人自己努力改變。 1. 會議的主持人要隨時確保每個人都有發言的機會， 一開始，可能甚至要先讓團隊成員一個一個輪流發言，被點到的人可以沒意見， 但任何人在講話的時候，其他人都要有耐心讓他講完，除非有違反其他規定的狀況，不然不能輕易打斷別人發言。 2. 再來，任何人的發言都要被納入參考、記錄下來， 因為好想法可能從任何地方出現，一個現在看起來很蠢的發言，可能是另一個很好的想法的起點。 3. 討論時，團隊成員要學著不去否定其他人的想法，當聽到一個想法有問題時，你要嘗試去改善它，如此一來才能繼續持續產生越來越好的想法。 4. 如果有人違反以上幾個規則時，主持人必須馬上介入，先讓原本發言中的人講完，再讓其他人發表意見， 如果做到以上幾點，至少就能保證這個討論的環境是適合發言的。 5. 在環境以外能鼓勵發言的方式，就是讓團隊成員信任做決策的方式跟過程， 以我們自己的例子來說，我們是讓所有人都能參與投票，但這比較適合小型的團隊，大一點的團隊可能只有各部門主管能參與決策， 那種狀況也可以，但還是要盡量做到讓團隊成員相信決策的過程不是某個人隨意的決定，而是眾人考量後的結果。 6. 最後，就是要讓團隊成員看到他們的討論真的會影響事情的結果，讓成員知道發言真的會被採納，如此一來，下次討論時團隊成員就會更願意發表意見。 如何打造主動的團隊 讓團隊成員對專案有擁有感(Sense of Ownership) 意思是感覺到真正參與製作，甚至擁有遊戲的一個部分 鼓勵發言的環境，任何人都能參與討論 公平公開的決策方式，結果讓人信服 明確且一致的目標，清楚可行的計畫 製作人要確保遊戲的願景一致 每個里程碑結束後的檢討與改進 歡迎任何質疑，誠實面對問題 以團隊為單位面對問題與承受決策的結果 為可能失敗的決策做好準備，以團隊為單位面對結果 最後，除了討論以外，遊戲開發很大部分的時間是在實際製作上，那要如何讓團隊成員在製作時更自動自發呢? 要做到這點絕對不是喊喊口號就能達成，下面是幾個我認為很重要的觀念： 1. 第一點，也是最重要的一點，就是要讓團隊成員對專案有擁有感(sense of ownership)， 意思是成員感覺自己真的參與製作了這款遊戲，甚至擁有這個遊戲的一個部分，而不是覺得自己只是在幫老闆或製作人做他們想做的遊戲。 要讓成員有這種感覺，最重要的就是每個人都能參與討論，而且最後做決定的方式必須讓團隊信服。 我這邊的意思不是說老闆和製作人不能提任何意見，老闆和製作人可以提出意見也可以參與討論， 但他們的工作更應該是決定專案的整體方向，而不是去計較一些小細節。 2. 第二，專案必須有明確且一致的目標，團隊要能看到一個清楚可行的計畫， 要達成這點，工作主要就落在製作人跟負責專案管理的人身上， 首先製作人要能夠清楚地理解遊戲的願景是什麼，並且在製作的過程中，盡全力讓所有開發成員都維持一致的願景。 再來就是在每個里程碑結束後，團隊要對前往願景的這個開發計劃做出檢討與改進， 隨著時間的推進，每個成員腦中的願景就會越來越一致，而且也越來越能清楚看到團隊要如何一起走到終點。 3. 在開發過程中，一定會有沒預料到的問題發生， 為了盡可能提早解決問題，或者防止問題越滾越大，團隊一定要讓任何人都可以且願意提出質疑， 在聽到質疑以後，團隊也要誠實分析與面對問題，而不是無視或騙自己沒有問題。 4. 最後，在開發過程中，一定會有很多事情在做之前是無法預估結果的， 在遇到這種狀況時，就要以團隊為單位來面對與承受決策的結果， 就像我前面提到加速決策的重點就是不要浪費時間在爭論不確定的東西，多時間花在嘗試上， 當嘗試失敗時，團隊也不能去怪當初提出想法的人，而是要慶幸學到新的知識， 畢竟當初會嘗試就是因為投票的結果，也代表團隊中大部分的人都覺得那是個好想法。 Q&A 問答時間！ 參考資料 - 其他好東西 點這裡加入IGDShare的Discord，跟其他在台灣的獨立遊戲開發者一起分享與討論 How To Market A Game by Chris Zukowski (獨立遊戲電子報、免費獨立遊戲行銷課程) https://howtomarketagame.com/ GameDiscoverability by Simon Carless (獨立遊戲電子報) https://gamediscoverability.substack.com/ TheVTran's Community Dev Newsletter by Victoria Tran (獨立遊戲電子報) https://www.victoriatran.com/newsletter ICO Newsletter (Steam熱門新品電子報) https://icopartners.com/steam-newsletter/ 如何找到適合的發行商及怎樣是合理的發行合約 by Ross Huang Youtube影片 Google簡報檔 獨立遊戲行銷，從開案到上市 by Ross Huang Youtube影片 Google簡報檔