各位來賓,我們下一個講座極度邊緣開發方式是由臺灣遊戲工作室極度邊緣Overboard Studio的主計畫來為我們演講。 這家工作室在去年曾經發售類魂角色扮演工作遊戲《記憶邊境Demacia》,這款遊戲有優秀的關卡設計和戰鬥系統,獲得很大的好評。 他即將在這次演講中分享製作流程,如何在開發遊戲中減少冤枉路, 並且如何加速開發與討論的一些小觀念分享給大家。 我們掌聲歡迎黃士誠講師。 大家好,今天要分享的主題是極度邊緣的開發方式。 內容主要是在講我們在極度邊緣工作室的開發流程。 會想講這個主題主要是因為在跟其他開發者聊天, 或者是被人欺騙, 很多人都會想知道為什麼我們工作室只有7個人, 但可以做出像《記憶邊境》這樣的遊戲。 除了我們團隊成員幾乎都是有經驗的開發者以外, 最主要的目的是我們用了一個還不錯的開發流程, 幫我們避免掉很多問題。 絕對不是因為我們的工作效率有多高, 或者是我們加了多少班。 希望今天的分享可以對大家有點幫助。 首先我先來自我介紹一下, 我叫Ross,我是極度邊緣工作室的企劃, 我也負責專案管理的部分。 我們的第一個作品是《記憶邊境》, 目前已經上市了, 喜歡類文或動作遊戲的人, 可以購買我們的遊戲支援我們, 或者是追蹤我們的社群媒體。 在加入工作室之前, 我是美國遊戲開發研究所S&U Guild Hall畢業, 主修關卡企劃。 研究所畢業之後, 我先後待過幾間非獨立遊戲工作室的遊戲公司。 今天分享的內容最主要就是整合我研究所工作經驗, 還有自學的結果。 今天的簡報、營養者備忘稿, 還有我所有的參考資料, 未來都會跟YouTube影片一起公佈在網路上, 所以大家可以不用忙著拍照, 就認真聽,簡單做個筆記。 如果我講得夠快, 結束之後還可以進行, 接受幾個現場發問。 在進入正題之前, 我先打一記預防針。 就是今天的簡報, 其實比較像是經驗分享, 而不是專業的建議, 因為我並不是專業的專案管理人員。 然後簡報中大部分的觀念, 也都是我從書籍、網路上, 或是從其他人身上學來的。 所以如果你覺得我提到的東西, 你好像有聽過, 那你應該是對的, 我不是原創者。 我只是把我看到我覺得有用的資訊, 湊在一起, 然後再根據實際的開發經驗調整而已。 然後今天我提到的開發方式, 可能比較適閤中小型的團隊。 那我的經驗是到二三十個人都還適用。 再大的團隊我沒有帶過, 但我認為觀念上應該會是共同的, 只是可能你的執行方式要做一點改變。 那如果各位覺得, 今天聽到的東西是有道理可以使用的話, 非常歡迎大家帶回自己的團隊去使用。 但希望大家是可以理解背後的一些觀念, 再去使用, 而不是太堅持就是我提到的一些流程或細節的部分。 因為實際在開發遊戲的時候, 並沒有最好的開發方式, 只有最適合你們那個團隊的開發方式。 而且我今天講的東西, 我們自己團隊其實也沒有完全做到。 對,然後我們在開發的過程中, 我們自犯了一大堆的錯誤。 然後事實上我們到現在都還在修改我們目前的開發方式。 那首先這是今天的演講大綱。 最一開始我會先介紹一些在實際開發遊戲前, 我們要討論要釐清的東西。 接下來我會介紹我們目前使用的開發流程長怎樣。 然後我會詳細介紹說每一個階段, 你需要注意跟需要做的事情是哪些。 最後除了開發流程以外, 我還會分享一些我們在開發過程中學到 可以加速開發速度的一些觀念。 那最後如果有剩餘時間的話, 我就會開放現場問答。 首先是前期討論的部分。 那我們現在使用的開發流程是綜合多種理論跟架構的結果。 最主要是參考敏捷開發。 不過我們因為沒有完全遵守。 那這個開發方式其實很像是在, 蓋房子一樣, 一層一層往上堆上去。 那每一層都跟前一層息息相關。 因此打好基礎就非常重要。 右下角的這張圖就是一個很簡單的示意圖。 越底下的部分就是專案裡面越基礎越重要的東西。 那我後面我會仔細的解釋我們是怎麼一步一步做到 往上搭這件事情。 還有每一步背後的思考邏輯是什麼。 OK,好。 問題排除了。 好,繼續。 就是右下角這是一個很簡單的示意圖。 我後面會慢慢一步一步解釋我們是怎麼做到 就是一層一層搭上去的這個動作。 那這個開發流程最主要的目標是希望團隊可以在合理的範圍內 一起做出一個最理性的決定。 因此團隊裡面大部分的人都必須要可以理性溝通。 這個開發方式才會成立。 那尤其是帶領團隊的那個領導者必須以身作為領導者。 那我後面我也會分享如何讓團隊就是可以理性溝通的方式。 那我們從最基礎的部分開始。 就是在開發任何東西之前我們必須要理性的事情就是團隊做這個專案的目的到底是為了什麼。 是為了賺錢發大財。 還是你們是一個新的團隊。 你們在練身手。 你們在磨合。 還是你們只是一個新的團隊。 還是你們只是想要發揮創意。 還是目標是為了得獎。 在團隊沒有取得共識之前任何關於這個專案的討論都是沒有任何意義的。 因為專案的目的會嚴重影響專案中的所有選擇跟決定。 所以團隊一定要跟所有成員一起充分討論之後列出你們這個團隊的一個或多個目的。 再排出優先順序。 那為什麼要討論這個呢? 因為我前面講到的就是。 為了達到不同的目的。 專案裡面你們需要注重的事情會非常的不同。 如果你的目的是為了商業成功。 那你很有可能為了市場的喜好。 你會被迫做出很多妥協。 那這就有可能跟你的創意性有衝突。 甚至有不少的團隊會主動去做市場調查。 來調整遊戲的內容。 這件事情在可能免費手遊跟現在很流行的服務型遊戲裡面就非常的明顯。 那如果你的目的是為了練身手。 或者是為了累積人氣。 你目標是希望讓越多人看到你的遊戲越好。 那這樣子你就會考慮很低價去賣你的遊戲。 甚至免費讓玩家下載。 那這個東西就跟商業性有直接的衝突。 那第三個。 如果你的目的是以創意性或藝術性為主。 那你可以什麼都不考慮。 就跟畫畫一樣。 畫家自己覺得畫出來的東西很漂亮就好了。 他甚至不需要有別人的理解。 但是這一點就有可能跟前兩點又再衝突。 專案的目的可以不只有一個。 以記憶邊境為例。 因為我們工作是要有一定的收入才能長久的營運下去才能發薪水嘛。 但是我們所有人都已經從原本的工作辭職出來創業。 所以我們還是希望可以做自己想做的專案。 因此我們的第一個專案的目的就是希望能夠兼顧商業性跟創意性。 在開發的過程裡面。 除了一些極少數的我們堅持不能改變的東西。 以外。 我們都很願意配合發行商做的市場調查。 還有玩家測試的結果。 來調整遊戲裡面的內容。 難度或者是美術的設計。 那以最後上市的結果來看。 這些調整都是非常正確而且非常重要的。 很多團隊會把專案的目的當成理所當然。 然後不去討論。 但其實一個團隊裡面有這麼多人。 每個人心中想要過過這個專案。 達成的目的往往非常的不一樣。 那如果每個團員對專案的目的不同。 在討論事情的時候就很有可能出現。 雙方講的東西都是有道理的。 但是卻互相衝突的狀況。 那就是因為這些解法都是對的。 但是他們可能是朝著不同的目標前進。 那只有整個團隊一起討論清楚。 把優先順序排出來之後。 未來我們在遇到衝突的時候。 我們才有辦法做出取捨跟決定。 在決定完專案的目的之後。 下一個要討論的就是專案的願景。 那什麼是願景呢? 願景簡單來講就是一款遊戲完成時的全貌。 你也可以說是如何用一句話。 或是一段話。 讓別人來理解你的遊戲是什麼。 那有一些遊戲甚至會把遊戲的願景。 直接放在Steam商品頁上當作遊戲的簡介。 畫面上右上角就是記憶邊境Steam頁面上面的敘述。 大家可以跟我一起看。 首先裡面的第一句話。 我們提到了我們遊戲的型別。 記憶邊境是一個高難度的動作角色扮演遊戲。 由稱很累魂。 那玩家看到這句話。 他馬上腦中覺得有一個很基本的遊戲畫面。 第二句話。 我們提到了遊戲的玩法跟特色。 快節奏的戰鬥系統。 還有瘟疫武器系統。 那聽到這裡玩家腦中就會開始想像。 這是一款快節奏的累魂遊戲。 那它可能長怎樣? 然後開始好奇瘟疫系統是什麼? 因為他沒聽過。 最後我們則是快速的帶過一些故事跟世界觀。 基本上就是讓玩家去想像前面提到的那些東西。 是發生在怎樣的世界裡面。 那其實願景的寫法有很多種。 大家不一定要參考我們的格式。 那團隊要如何判斷一個。 一句願景是正確的呢? 簡單來講就是當團隊的成員。 看到這段話的時候。 你們心裡應該要覺得。 對!這就是我們要做的遊戲。 那團隊外的人。 聽到或看到這句話的時候。 他能夠快速的理解你的遊戲。 甚至腦中浮現畫面。 那能做到這幾點的話。 都是一個好的願景的徵兆。 那為什麼我們要討論願景呢? 願景最主要的功能。 就是確保在遊戲開發的過程中。 所有人都是往同一個方向前進。 因為像專案的目的一樣。 大家對專案完成的樣子。 其實也會有不同的想像。 那以我們自己為例。 儘管我們開發遊戲是類魂遊戲。 聽起來好像已經很清楚明白了。 但事實上市面上有很多不一樣的類魂遊戲。 光FUN Software他們自己就出過。 動作慢的魂123。 動作壞的之狼。 然後介於中間的還有血源跟奈爾登法環。 那如果團隊沒有討論清楚。 我們要做的是怎樣的遊戲。 很容易程式美術企劃。 大家腦中有不同的想法。 然後各做各的。 那遊戲開發的時候。 我們最怕的就是。 整個團隊大家像無頭蒼蠅一樣到處亂飛。 所以在開發的過程中。 遊戲製作人最重要的工作。 就是確保大家都擁有一致的。 擁有一致的願景。 除此之外。 在開發時。 因為大家都很投入在自己的工作領域。 通常只有遊戲製作人可以看到。 各個領域組合起來的全貌。 所以遊戲製作人另外一個很重要的工作。 就是確保在開發過程中。 團隊的每一個決定。 都是符合願景的。 這樣子最後我們完成的遊戲。 他才會是和諧一致的一款遊戲。 那在製作過程中。 願景是有可能改變的。 有可能是因為我們。 原本想像的設計。 實際做出來之後。 並不好玩。 或者是也有可能是很小的事情。 像是可能我們只是把。 一些我們認為優先的東西。 排到比較後面一點。 稍微改變一下。 他的順序或者是敘述方式。 也有可能是我們在開發過程中。 學到的一些新的知識發現。 原本我們想做的願景。 根本就不可能達成。 因此團隊就要。 定期的去測試。 然後去檢查。 遊戲的願景是否改變。 也要提早做好。 願景是有可能改變的。 這個心理準備。 以我們團隊為例。 我們每個里程碑結束之後。 我們都會包版本。 然後做內部測試。 除了檢查遊戲的功能性。 跟美術之外。 我們要思考說。 我們朝著這個現在。 決定的這個方向繼續前進。 是不是正確的。 如果我們有任何人。 感覺到任何問題。 我們就會提出來。 大家一起討論。 看看是這個問題是因為。 我們可能有東西還沒做完。 還是我們一開始的願景。 就是有問題的。 最好講的就是。 改變願景它並不是世界末日。 但是整個團隊必須要一起決定。 在知道遊戲完成的全貌以後。 我們就可以反推回來。 去整理出。 團隊預計達成願景。 的幾個主要方式。 那一般來講。 我們就稱這個叫做設計支柱。 通常我們會列出三個左右。 然後一樣要按照重要順序排列。 以記憶邊境為例。 畫面上的中間那個那張圖。 就是我們的願景。 那我們討論出來的。 設計支柱有兩個。 一個是流暢的戰鬥系統。 另外一個是黑暗幻想的。 美術風格。 這兩點對我們來講是最重要的。 那其他像是故事情節。 關卡設計。 對我們來講都是次要的。 那如果你有玩過我們的遊戲。 你應該可以很明顯的感受到。 那為什麼按照順序。 重要順序排列呢。 主要就是當開發過程中。 我們一定會遇到設計支柱。 互相衝突的狀況。 這個時候有順序。 我們才能夠按照順序來做出決定。 舉例來講我們在開發中期。 我們的美術為了讓場景看起來很漂亮。 很豐富。 很有生活化。 美術就在裡面堆了很多的雜物在裡面。 但是雜物一多。 就會擋到玩家的鏡頭。 或是擋到主角跟敵人的移動路線。 那最後我們為了決定。 我們決定為了遊戲的戰鬥。 它的流暢度。 所以我們必須拓寬走道。 然後我們還對就是遊戲中的雜物。 它的數量。 大小。 跟碰撞。 都做出了一定的規範。 主要就是因為我們在開發的前期。 我們就已經決定了。 流暢的戰鬥系統。 是比黑暗幻想的美術風格更重要的東西。 那這個就是順序它存在的目的。 在訂出幾個設計支柱之後。 我們還可以進一步再往下拆解。 去詳細講出說每一個設計支柱。 我們還願意預計要用哪些的系統。 跟特色來達成。 那有需要的話。 這些系統跟特色。 我們甚至還可以繼續往下拆解。 直到變成我們可以實際執行的工作事項為止。 但是在開發的前期。 我們通常是會那個就是停在細節。 而停在系統跟特色的這個部分。 剩下的細節跟工作事項。 我們可以等到後面開始寫檔案的時候。 再去討論。 那一樣我們在拿我們整個的。 遊戲當作例子。 前面講過我們的兩個設計支柱是流暢的戰鬥系統。 跟黑暗幻想的美術風格。 其實這兩點單純看起來它還是太抽象。 所以我們就把它拆解成更具體的。 系統跟特色。 那以戰鬥系統來講。 我們把它拆解成三個部分。 一樣是由上而下。 按照重要順序排列。 最重要的就是。 爽快又緊湊的戰鬥。 再來是魂系的敵人設計。 除了以上兩點以外。 我們也很想做出一個可以讓玩家高度自定義的戰鬥系統。 所以我們就寫了第三點。 自定戰鬥風格。 那以美術來講。 瘟疫是我們遊戲裡面貫穿美術跟故事的一個主題。 所以遊戲裡面的場景跟敵人設計也必須反映這一點。 最後我們就得到畫面上的這一整份文字。 從最基礎的專案目的開始。 每一步都會仔細的說明我們如何做到前一步。 那以記憶邊境為例。 我們工作室的第一個專案。 目的是為了做出一款能兼具商業性跟創意性的遊戲。 那我們要如何達到這一步。 答案就是我們要做一款叫做記憶邊境的高難度動作角色扮演遊戲。 那記憶邊境是一款怎樣的遊戲。 它是一款擁有流暢戰鬥系統。 跟黑暗幻想美術風格的遊戲。 那我們又要如何做到這個戰鬥系統跟美術風格呢。 我們就決定採用下面這些特色跟系統。 來做到。 團隊討論到這裡。 對於整個遊戲的畫面就會越來越清晰。 然後團隊也會越來越清楚說。 對我們要完成這個遊戲。 我們就需要這個這個這個。 非常清楚的內容。 那這邊讓我來總結一下。 為什麼我們前期要做這個遊戲。 為什麼我們前期要花這麼多時間在討論這些東西。 首先我們從做專案最根本的目的開始討論。 這樣子所有任何事情都會有一個共同的源頭。 意思就是說。 如果我們開發過程中有任何爭執的時候。 我們永遠都可以回頭找到當初為什麼我們要做這個決定。 再來所有事情都有上下還有優先順序之分的時候。 團隊遇到爭執就可以快速的做出取捨。 像我前面提到的。 我先給大家一個例子。 美術搭的場景跟遊戲玩法有衝突的時候。 因為我們共同決定遊戲的戰鬥。 這一款遊戲的戰鬥比美術還要優先。 所以美術在這邊他就必須讓步。 類似的東西如果大家沒有在開發的前期討論好。 很容易就會發生兩個部門各執一詞的狀況。 因為每個部門一定都覺得自己的東西是最重要的。 那無論誰被犧牲一定都會不服氣。 久而久之。 很容易就會出現問題。 不過這個方法聽起來再怎麼美好。 還是有可能遇到沒有無法解決的問題。 有可能是團隊對願景或是前面的一些設計制度的順序。 理解有誤。 或者只是單純的一些可能敘述要改變。 那這個時候就是團隊該坐下來討論跟修改的時候。 這其實也不是什麼很大的問題。 因為經過幾次這樣子的討論。 團隊就會越來越清楚。 這個團隊我們在意的共同點是哪些東西。 最後的結果就會變成團隊會有越來越多不能被動搖的共識。 那團隊對於遊戲的願景也會越來越清楚跟一致。 再來我們進入開發流程的部分。 在我們把專案的基礎。 在我們把專案的基礎釐清之後。 接下來我們就是要把前面討論的東西全部記錄下來。 畫面上是遊戲開發中一些必要的基本檔案。 我接下來會非常快速的講過每一份檔案裡面該有的一些必須內容。 首先一個專案至少會需要一份遊戲設計檔案。 裡面就是用來記錄這個專案所有的重要資訊。 那檔案的格式我會照前面討論的順序。 從最基礎的開始記錄。 像願景、設計支柱、特色、系統等等。 接著我會照著前面討論的順序繼續往下拆分。 列出完成這款遊戲我們必須要的細節設計跟規劃。 像是遊戲的玩法、鏡頭、故事的細節、美術的風格跟概念圖等等。 那根據專案的複雜程度而定,有可能你這個遊戲會需要多份設計檔案。 像是美術的風格檔案、程式的一些技術規範,或者是企劃的關卡檔案。 那我這邊沒有時間細講每份檔案裡面的需要有的東西。 大家可以上網找我範例。 那檔案重要一點是它必須要跟著專案一起更新。 如此以來,如果未來有新的成員,或者有外部的成員想要知道關於這個專案的一些事情的時候。 他們可以快速的瞭解你這個專案的全貌長怎樣。 在開發過程中,如果團隊對於任何事情有爭執的時候。 我們也可以回頭找到說,當初為什麼我們要做這個決定。 在遊戲設計檔案完成之後,接下來就是要討論遊戲開發的里程碑跟工作規劃。 那裡程碑指的是團隊根據時間或者是時間的規劃。 那裡程碑指的是團隊根據時間或者是時間的規劃。 那裡程碑指的是團隊根據時間或者是時間的規劃。 那裡程碑指的是團隊根據時間或者是時間的規劃。 Olympic Games 你們可以決定可以想 MV Anyxter 你在得ї ging rails 日債 金額 金額 內部決定的例子我後面會提供一個格式給大家參考 我這邊先跳過 那這個里程碑跟工作規劃 大家要用任何工具來記錄都可以 像我們就是簡單的用Google序 畫一個像甘特圖的表格 那大家可以看一下畫面右下角的範例圖 這份檔案就是我們團隊在使用的這個工作規劃檔案 會附在這份簡報的演講者備忘稿裡面 那未來如果大家想要使用的話 你只要建立副本就可以 在規劃里程碑的時候 團隊要先討論出每個里程碑的主要目標 然後每一個部門你再去想說 我要完成這個主要目標 我會需要哪些大的工作專案 然後我們再慢慢的逐步把它拆解成小的工作專案 最後變成可以執行的工作事項 最後我們再把這些工作事項 填到右下角的工作規劃表裡面 就像畫面上那樣 大家可能看不太清楚 那預估工時的時候 我個人的習慣是我會抓 大概額外20%左右的預留時間 給一些突發事件或者是雜事 那如果你對這個工作越不熟 你就要抓越多的預留時間 因為我們寧願事情提早做完 我們也不想要就是事情做不完 然後被逼著回頭砍東西 當我們把工作規劃表排滿之後 一定還會有一堆塞不下的事情 那這個時候我們通常會把它整理到一份 我們稱作願望清單的檔案裡面 未來如果有人事情提早做完 他就可以回來圓夢 那這樣你也可以鼓勵大家 趕快把手上的工作完成 進入工作規劃表裡面 進入工作規劃表裡面 進入工作規劃表裡面 進入正式開發以後 每個里程碑完成的時候 我們通常會花一天以上的時間 開一個會議來檢討 我們這個里程碑 任何我們覺得有問題的地方 可能是工作流程 可能是製作方式 可能是我們的預估工時誤差太多 任何事情都可以 然後在下一個里程碑開始以前 我們會盡量把這個問題修正 然後我們再重新調整 下一個里程碑的工作規劃表裡面 下一個里程碑的工作規劃表裡面 跟預估工時 這個步驟重複幾次之後 團隊的工作效率就會越來越高 然後你預估工時也會越來越準確 不過前提是團隊成員要很誠實的 面對自己跟面對這個專案 最後這個遊戲就是 做遊戲大家不是做完上架就沒事了 無論你做的是單機線上還是手遊 任何遊戲上市之後 至少都需要預留 一到三個月的時間去維護 以防萬一 以上兩份檔案都牽扯到 如何規劃一款遊戲裡面的系統跟素材 我這邊會先忽略設計的部分 單純從專案管理的角度下去 討論如何規劃 開發遊戲的時候 任何東西都需要時間或需要錢 這兩個東西是獨立開發者最缺的東西 在時間跟錢都不能增加的狀況下 如果你因為一時興起加入了A素材 那就代表有另外一個B素材 你沒有辦法做 所以我們絕對不能想到什麼就加什麼 那要怎麼加才是合理的呢 答案就是從我們前面討論過的設計支柱出發 一圈一圈的往外延伸 畫面右下角就是我拿其中一個設計支柱當作範例 大家可以看到綠色中間是寫設計支柱 那環繞著它淺灰色的地方是核心的系統 跟素材 這些東西應該是團隊討論過後 認為要完成這個設計支柱最低的需求 理論上我們完成了這些系統 核心系統跟素材之後 這個設計支柱應該就要成型了 以此類推 我們必須要確保設計支柱 一二三的核心繫統跟素材都完成了 我們才能把多出來的時間拿去開發周邊的系統跟素材 如此一來 如果我們時間不夠的時候 我們可以從最外圈開始往內砍 而不會影響到遊戲的核心部分 不過當然就算我們是說從最外圈往外砍 但也不是說隨便亂砍都可以 重點是我們要對遊戲完成的樣貌 我們要有多個計劃 大家有可能看過畫面左下角的這張 就是如何開發最簡可行產品的一張示意圖 畫面上假設就是 如果我們 我們的目標是把人從A點運送到B點 在有足夠的時間狀況下 上下兩個團隊最終他都會做出一臺汽車 但是當時間不夠的時候 就算只缺一點點 上面團隊做出來的產品 他就無法達成我們要求的目標 而下面的團隊 他們在任何一點停下來 他都可以把人從A點送到B點 那我們在遊戲開發的時候 我們要學習下面這個團隊的心態 就是我們要完成的目標 都是同一個願景 但是我們完成的方式 跟你專案的大小 可以有很多種 一樣我拿記憶邊境為例 前面說過我們的核心繫統 核心有兩個 一個是流暢的戰鬥系統 一個是黑暗幻想的美術風格 那我們認為要完成戰鬥系統最核心的部分 就是主角的戰鬥系統 還有魂系的敵人設計 因為你只要有主角跟敵人 你就可以玩了 只要再搭配上幾個BOSS房 那我們就製作完成一款專門打BOSS的遊戲 事實上記憶邊境最一開始的規劃 就是隻開發一年半 然後內容只有BOSS在 我們是在開發一段時間之後 我們確定了我們擁有足夠的時間跟能力 來完成核心的部分 然後後來我們又得到發行商的幫忙 我們才決定把 遊戲的內容往外擴充套件 在戰鬥的部分 我們新增了第三點 制定戰鬥風格 也就是遊戲中後來的 瘟疫武器系統跟天賦系統 然後在美術的部分 我們增加了連結BOSS房之間的 可探索關卡 不過這個不代表 我們沒有砍掉任何東西 事實上我們原本打算製作 更多的關卡跟更多的BOSS 但是因為時間不夠 我們被迫縮減好幾次 我們還砍掉了 一個貫穿遊戲的系統 因為我們在製作過程中 我們沒有自信 也沒有時間做到 讓我們自己滿意的程度 但是就像我講的 團隊要對遊戲完成的樣貌 有多個計畫 然後隨時根據你們的開發狀況 來做調整 而不是說堅持要製作一個 心目中完美 但是你永遠做不完的那個遊戲 最後一份檔案是 金流跟預算規劃 這部分我們也只是簡單的用 Google訊加在一起而已 那這邊就沒有翻例給大家看 我非常建議大家一定要把 開發時的所有開銷都記錄下來 而且每一筆支出 都要有很明確的原因 如此一來才不會莫名其妙 就開發到一半沒錢了 那團隊也可以在資金用完之前 及早去找錢 除此之外 無論你是學生團隊 或者是新創團隊 我都建議每個人都要資心 就算你拿的是最低薪水也好 因為這樣子才能讓團隊 有一個正確的金錢跟預算的觀念 記錄金流一段時間之後 通常是完成幾個里程碑之後 團隊就能知道開發時的可能開銷 那我們就可以根據這些開銷 去做一個估計 知道完成整個專案需要的 開發方式 費用大概是多少 未來無論你要找投資人 或找發行商 他們一定都會問你的預算規劃 跟你的金流 那如果你講不出來 或你跟對方說 我沒有資心 我們是靠熱情在做 你很難說服對方 你們是一個認真 而且有經驗的團隊 這個時候對方要嘛是不理你 要嘛他就會開出一個 非常不合理的投資方案 那如果這個時候 你們沒有正確的 金錢跟預算觀念 你們很容易就把你們 辛苦做的遊戲 賤賣給別人 最後就算你不需要投資人 也不需要發行商 只要你的工作室 想要長期的營運下去 預算規劃跟金流控管 也都是必要的知識 你現在不面對 你未來遲早還是要面對 準備完以上的那些檔案 我們總算可以進入 正式開發階段 那我們就來看看 我們總算可以進入正式開發階段 我們總算可以進入正式開發階段 那我們總算可以進入正式開發階段 那我們總算可以進入正式開發階段 那畫面上的是 就是我剛剛前面提到的 一些正式開發階段 內部的Milestone 就是里程碑的分類 那每個公司其實都有 自己的分法跟名稱 那我這裡只是介紹其中的一種 這並不一定是正確 首先最前面的三個階段 概念發想 概念驗證 還有技術驗證 有時候不會被認為是 正式的開發階段 有時候不會被認為是正式的開發階段 因為在這三個開發階段裡面 團隊通常還不知道 自己要做怎樣的遊戲 而且前面我們提到的 願景還有設計支柱 也都是在確定了 遊戲的基本概念之後 我們才會去討論 不過這不代表說 這三個階段不重要 相反的這三個階段 是非常重要的 因為很多事情 我們在這裡釐清了以後 我們就可以省去後面 進入正式開發 浪費了大量時間跟金錢 第一個概念發想 團隊可以用任何 你們喜歡的方式去做 我這邊就先直接跳過 那第二概念驗證的部分 重點就是 團隊有一個喜歡的 遊戲idea之後 你要試著使用最簡單的方式 在最短的時間內去驗證 這個概念是不是真的好玩 還是隻是聽起來很有趣而已 舉例來講 如果你們在做一款敘事遊戲 那重點當然就是故事 這個時候你應該至少寫出 一個章節的故事 然後拿給團隊成員 拿給認識的開發者 或拿給身邊的親朋好友看 你們要確定你們有能力 寫出好故事 你們才有繼續開發一款 敘事遊戲的本錢 如果你們的遊戲玩法 核心是你們的玩法 那你們也要找到最簡單的方式 來驗證這個玩法好不好玩 這邊說的驗證 不一定代表說 我們馬上要開始寫程式 開始馬上做 我們要開始研究 很多的遊戲玩法 尤其是像是一些卡牌 棋牌類的那種遊戲 其實你只要用紙筆 或者是玩角色扮演 你就可以驗證 原本的想法是不是可行的 就算你沒有辦法真的玩到 你跟同事之間 一起來模擬一下 你們想像的遊戲流程 你們可以快速看到一些 光用口頭討論 沒有辦法想到的缺點跟漏洞 第三 技術驗證 當團隊已經確定某個概念是好玩的 那在正式開發前的最後一步 就是確保團隊有完成這個概念的 技術跟能力 以記憶編輯來講 我們要做一款類混遊戲 那我們認為最重要的東西是戰鬥 所以我們一開始製作的 就是一個BOSS戰的DEMO 當然很多問題 有可能是你在開發過程中 你才會發現 我這邊也不是要求大家說 一定要在開發過程中 在開發前花大量的時間 在做技術研究 但是團隊不一定要把東西做出來 但是你一定要花時間去研究 你們想做的東西 看團隊是否有能力做到 看團隊是否理解背後的技術 團隊是否腦中有一個很清楚的路線圖 而且可以在合理的時間內 完成這個遊戲 驗證完概念之後 接下來是白盒階段 這階段最重要的目標是 確認關卡裡面的規格 像是主角的身高 跳躍的長度 一個門的寬度 一個房間的大小等等 到一整個世界要多大 我們最好都可以在 盡量在這個階段裡面 就抓出我們需要的大小跟規格 那有些遊戲 它沒有明確的關卡之分 我們可以用章節 或者某個遊玩片段 像是可能15分鐘來檢視 就算你是做單純的視覺小說 或者是戀愛遊戲 你也要確定遊戲裡面的每個UI 然後還有你每一張美術圖 在畫面上的位置跟比例 程式它才知道怎麼寫code 那美術也才知道怎麼出圖 然後還有它才知道說 它出來的圖會怎麼樣被使用 這個階段最主要的工作 會落在美術跟企劃的身上 因為無論遊戲是2D或3D的 遊戲裡面的規格都會有一個規格 會影響美術出圖的東西 美術出素材的規格這樣子 那還需要注意的是 這個階段的重點是規格 所以搭建關卡的時候 我們只要用很簡單的幾何圖形就好 千萬不要在這個階段浪費時間 在一些視覺美感或是玩法上面 那程式在這個階段 它除了幫忙確定規格以外 它就可以先去開發 遊戲核心相關的功能或是玩法 確認完遊戲的規格之後 接下來我們就要確認遊戲的玩法 這階段最主要的目標就是 遊戲的核心玩法或功能初步完成 那初步完成的意思就是 我們未來還會持續的開發跟更新 然後但是我們會希望這個階段 至少一個關卡要可以從頭的 簡單的從頭玩到尾 那程式在這個階段它的目標 就是初步完成核心的玩法跟功能 讓團隊的成員可以試玩到 就是我們討論中的這個製作中的這個遊戲 那企劃則是要把程式完成的功能 放到關卡裡面 盡量讓一個或是多個白盒關卡 可以從頭玩到尾 美術則是要看著這些可以玩的白盒關卡 或者是根據企劃提出的需求 來製作核心就是遊戲核心相關的美術素材 再來是垂直切片的遊戲核心 就是遊戲核心相關的美術素材 那這個就是我們在這個階段 我們在這個階段的概念階段 那這個階段是我認為除了前三個概念驗證階段以外 最重要的開發階段 但是也是我就是看到很少有臺灣團隊 知道要做的階段 這階段最重要的目的就是把遊戲中的一個部分 開發到接近上市時的完成度 這邊的一個部分通常指的是一個關卡 一個章節或者是像我前面講的一個片段 這個結段這麼重要 因為這個階段可以讓團隊第一次碰到你要完成這整款遊戲的所有東西 美術UI特效音效所有東西都應該要做到 如果有任何東西你做不到 或者是他所需要的時間遠遠超過團隊的想像 在這個階段你就會卡住 所以團隊立刻必須要立刻馬上坐下來檢討問題出在哪裡 此外這個階段也是一個很重要的一個關卡 這是團隊可以一窺遊戲願景的最好機會 因為在前面的概念發想啊白盒啊遊戲階段 如果你覺得遊戲不好玩你可能還有理由 有可能是東西沒做完 但是到了垂直切片 理論上我們已經把一個關卡所有東西都已經做到完成的品質 如果他還不好玩那你就很大的問題 因為我們的下一個階段就是量產階段 團隊必須要在進入量產階段投入大量的時間跟金錢以前 我們要理清不好玩的原因是什麼 我們絕對不能硬著頭皮做下去 然後期待未來遊戲會突然變好玩 對那是不可能的事情 程式在這個階段是要做要做到的事情是把遊戲從開始到完成指定的關卡 過程中所有碰到的功能都要完成 包含主選單 關卡讀取 核心玩法 基本UI 或是打包一個可以執行的執行檔 那美術跟企畫的目標是什麼呢 最重要的就是盡量把這個關卡組裝成上市時的完成度 在完成垂直切片這個階段之後 因為是團隊第一次知道完成這款遊戲的一個關卡需要多少時間跟金錢 所以完成這個階段的檢討會非常的重要 最後垂直切片的成品 因為他的完成度夠高 所以他其實非常適合拿來找投資人 找發行商 或者是你可以把這個版本放到STEM上面吸引玩家 或者是你可以用已經開發完成的遊戲內容 可能是圖片 可能是玩法內容 你可以剪預告片 開始記憶你的社群媒體跟你的STEM頁面 那以我個人的經驗來講 我認為只有成功透過垂直切片的專案 才是真的進入遊戲的正式開發 接下來是量產階段 這個階段就很直白 基本上就是延續前面的規劃 然後再經過垂直切片的磨練之後 繼續把剩下的專案完成 通常我們會根據開發的時間或者是內容 再切出多個檢查點 像是可能每幾個月檢查一次 或者是每完成一個關卡我們回頭檢討一次 以記憶邊境為例 因為我們在前一個階段垂直切片階段後面的關卡 我們會再檢查一次 我們把所有的東西做出來 所以量產階段我們也是每三個月 我們設定一個檢查點 每個檢查點結束之後 團隊一樣我們會打包版本 測試檢討會議 因為我們要避免在量產階段 有任何隱藏的問題 就是躲在裡面 然後拖慢我們的開發進度 最後一個階段是打磨階段 這階段最重要的重點就是不能再新增任何的部分 這邊講的資源包含程式的功能 包含遊戲的關卡包含美術的素材 所有更新都只能是為了修BUG 或者是讓遊戲的體驗更好 從這個時候開始團隊應該要非常頻繁的進行遊戲測試 事實上我前面就講過 我建議大家每個里程碑結束 都至少要進行一天的內部測試跟檢討 這樣子大家才能夠盡早發現問題 盡早解決 依據我剛剛講的 以我個人的經驗 我認為團隊要保留總開發時間的20%到25%給打磨階段 舉例來講 如果你的開發時間是一年 那你可能需要保留2到3個月的時間來打磨 那如果你的開發時間是兩年 那可能需要6個月的時間 因為你的開發時間越久 通常就代表說你的專案裡面的東西越多 系統之間的相關性也會越複雜 所以你可能出問題的地方會越多 那需要打磨跟除錯的時間 就會需要越多 在這個階段團隊就是不斷的打包 測試 檢討 修正 然後重來 我會建議團隊在可行的範圍之內 重複越多次越好 那除了團隊自己進行內部測試以外 還有找一些身邊的親朋好友來幫忙 如果可以找到自己遊戲的目標客群 來測試是最好的 不過因為獨立團隊通常沒有資源來做到這一點 那我的建議是 大家可以找身邊認識的開發者幫忙 那最好是找有相關開發經驗的開發者 或者是你知道他喜歡玩你這型別遊戲的開發者 因為他們通常可以給你比較好的建議 除此之外 現在Steam每年有三次的新品節 也是非常好的測試機會 因為除了你可以拿到大量的目標客群的回饋以外 你還可以趁機累積你的願望清單 但是大家要注意 大家要記得就是 一款遊戲你一生只能參加一次的新品節 所以我會建議大家參加遊戲上市前的最後一次就好 這樣才可以確保你DEMO的版本 跟上市的品質是最接近的 那你測試的效果也會是最好的 在遊戲開發完之後 除了該要做的showbug還有更新以外 專案的事後檢討也很重要 那我這邊會寫 我習慣從三個方向下去討論 第一個是做錯什麼 首先因為這個東西是最簡單的 就是大家就開始舉說 我們覺得這個專案我們做錯了什麼東西 有可能是美術風格選錯 所以我們素材很難製作 也有可能是專案的規模太大 所以我們做不完到時候一直砍東西 也有可能是我們的辦公室位置不好 我每天上班要通勤兩個小時 對任何東西都可以 那如果大家覺得太廣泛 你想不到要怎麼開始 你也可以從遊戲開發的每一個里程碑去檢討 你也可以從遊戲的每一個部分去檢討 第二點就是做對了什麼 在講完壞事之後 團隊也可以討論一下說 那我們開發過程中 哪些事情我們覺得我們是對的 這邊跟上面一樣 我們可以分享任何事情 最後我們就總和上面的兩點 我們開始以團隊來整理說 我們學到了什麼東西 一般來講我們會把事情整理成 未來我們該繼續做哪些事情 還有未來我們該避免做哪些事情 就跟每個里程碑 我們結束之後做了檢討會議 可以讓你下一個里程碑更好更順暢 你一個專案結束的檢討會議 也會讓你的下一個專案更好 接下來我會分享一些 我們自己在開發的過程中 學到可以加速開發的一些小觀念 在遊戲開發過程中 很大一部分的時間會花在開會上面 但是這些會你又不能不開 因此如何加速會議就非常重要 在嘗試過各種方法以後 我這邊統整出了幾個 我認為非常有用的步驟 首先在會議前 大家要確定會議的主題是什麼 越明確越具體越好 因為我們希望在每個會議前 結束的時候都要有結論 再來這個會議要抓一個預估的時間 時間到了我們就要把會議結束 然後讓成員回去做他們原本該做的事情 而不是為了一個會議討論不出結果 就在那邊耗一整天 那如果時間到了 我們東西還沒有討論出來怎麼辦 如果我們在會議過程中 發現原本要討論的議題 比我們想像的還要更複雜 那我們就可以把原本的議題 切分成好幾個不同的片段 來討論 這個也是結論的一種 在會議開始之前 團隊就要預告 我們會議的主題是什麼 這樣子其他的人 才可以在參加會議之前 就提早準備 而不是到了會議 你跟他講主題 他才開始想 這個主題我要什麼 這個是浪費時間的行為 最後在團隊預告會議的時候 我們只會要求 就是跟會議主題有相關的人出席 但是其他如果你有興趣 你也可以參加 舉例來講 假如說我們要討論一個戰鬥系統 那有可能就是企劃動作美術 跟程式三個人是一定要參加 但是如果我們的美術 它是一個類魂愛好者 那他也可以來參加 提供一些意見 但是我們不會強迫他一定要 就是我們不會強迫所有人都要參加 因為這樣子我們才可以避免 在會議上面 不會有人在那邊發呆沒事做 會議過程中 我們也要先跟開發 那個參加的人員講好 這次會議討論出來的結果 有可能會影響到哪些地方 這樣子團隊才會理解說 我接下來的發言 有可能會對什麼什麼造成結果 這樣也可以避免 會後我們在執行的時候 開發成員有後悔的狀況 會議中我們一次只討論一個議題 任何離題的內容 都要先被記錄下來 然後繼續回到原本的主題 那如果離題的內容是很重要的東西 我們可以在會議結束之後 再安排一個新的會議討論 在討論一件事情的時候 團隊要釐清你們想要達到的目的是什麼 然後我們再去討論 我們怎麼達到這個目的 而不是我們一開始就討論 如何就是不同的做法 它的好處跟壞處 因為在我們沒有定出目標 跟我們的標準之前 我們討論 不同方法的好處跟壞處是沒有意義的 最後在討論的過程中 千萬不要預設 其他人知道你在講什麼 你也不要去預設 其他人知道某個詞的意思 因為就像我前面舉的例子 誰知道你說的類魂 跟我說的類魂是不是一樣的 你覺得太快 我覺得太慢 那我們這邊預設是沒有任何意義的 最好的狀況就是我們直接 搭配實際的畫面 或者範例 我們來配合我們講的東西 來討論 在會議後 除了我們要記錄會議的結果之外 討論的過程 還有做決定的原因 我們也要記錄下來 因為這些都能夠方便我們未來 如果出現疑問或衝突的時候 我們可以回頭看 為什麼當初我們會做這個決定 那每個會議的記錄 也要找一個地方集中管理 未來如果我們在討論相關的議題的時候 我們可以快速的回來 翻閱以前討論過的東西 以前找過的資料 我們就不用在同一個議題上面 一直重複的浪費時間 一直開會 在開發的過程中 團隊一定也會需要做出 很大量的決策 那除了前面講到一些 就是加快會議的方式以外 我這邊也提出一些 加快大家做決定的方式 首先團隊要先確定 這個決定是可逆 還是不可逆的 一個決定是可以的 一個決定是可逆還是不可逆 主要就是看團隊在做這個決定的時候 你需要耗費的時間跟資源有多大 如果要耗費的時間跟資源 打到你沒有辦法 一而再再而三的一直重複嘗試 那這個決定 對團隊來講就是不可逆的 只有在我們遇到不可逆的狀況的時候 團隊我們才需要慢下來 仔細的去思考 只要他的這個決定是可逆的 那團隊盡早做出決定 然後趕快嘗試 往往會是比較有效率的方式 因為在遊戲開發的過程中 很多事情我們在沒有看到實際的結果的時候 很多事情我們在沒有看到實際的結果的時候 我們根本就不知道他的效果是怎樣 我們根本就不知道他的效果是怎樣 其實大家都只是在猜測跟想像而已 沒有任何一個人能夠保證說 做了這個東西遊戲就會變好玩 絕對沒有人能夠做出這樣的保證 絕對沒有人能夠做出這樣的保證 那在這種情況下面 你與其把時間花在爭辯一個沒有人知道結果的議題上面 你與其把時間花在爭辯一個沒有人知道結果的議題上面 不如我們把時間花在實際的測試上面更有意義 不如我們把時間花在實際的測試上面更有意義 不如我們把時間花在實際的測試上面更有意義 在開會的投票中 我們也會讓團隊先列出所有的可行方案 然後讓大家發表意見 充分討論 盡量讓大家在投票之前 對所有選項的優缺點都有足夠的瞭解 對所有選項的優缺點都有足夠的瞭解 在投票的時候 除非是做最後的二選一三選一的決定 不然我們都是習慣讓所有人有無限票可以投 不然我們都是習慣讓所有人有無限票可以投 只要你覺得這個選項是你可以接受 你覺得是好的你就可以投 如此一來才不會有被犧牲的第二高票 如此一來才不會有被犧牲的第二高票 投完票的結果我們也可以看出 整個團隊的喜好是怎樣 整個團隊的喜好是怎樣 投完票之後我們會從 最高票的選項開始嘗試 如果有出現多個同票的情形 如果有出現多個同票的情形 我們就會直接讓製作人決定 我們要從哪一個選項開始執行 因為會出現同票的情形 就代表說這一個問題 它沒有明顯的最優解 每一個同票的選項它一定是最優勝的 每一個同票的選項它一定是最優勝的 就跟我前面講到一樣 在這個狀況下面我們不如趕快 從第一高票開始測試 如果結果不好 那我們就再從第二高票第三高票輪流測試下去 我們就再從第二高票第三高票輪流測試下去 前面提到會議跟決策 都需要團隊成員的參與跟溝通 事實上整個遊戲開發過程 就是團隊成員不斷的在溝通 所以很多人會想要知道 怎樣的環境會讓團隊成員 會讓團隊成員更願意發言 會讓團隊成員更願意發言 我的經驗是這是一個環境 跟個人 相輔相成的問題 我們能做到的事情就是讓 環境變成一個更 適合發言的環境 個人的習慣部分我們只能 期待個人慢慢改變 期待個人慢慢改變 首先會議的主持人要隨時確保 每個人都有發言的機會 在一開始 實行的時候 甚至要一個一個成員點出來 讓他發言 被點到的人 沒有意見 但是他一定要有發言的機會 然後任何人在講話的時候 其他的人都要有耐心讓他講完 除非有違反 下面的一些規定的狀況 不然不能輕易打斷其他人發言 再來就是任何人的發言 都要被納入參考 都要被記錄下來 因為一個好的想法 很有可能從任何地方出現 一個聽起來很蠢的發言 有可能是另外一個很好想法的起點 在討論這個問題的時候 團隊成員要試著學習 不去否定其他人的想法 當你聽到一個想法 你覺得有問題的時候 你應該要試著去改善它 如此一來團隊裡面才能一直產生 越來越好的想法 那如果有人違反上面提到的幾個規則 主持人就必須馬上介入 讓原本在發言的人 繼續講完 其他人才能再發表他的意見 如果我們做到以上的幾點 至少我們就可以 把這個問題解決了 我們可以保證 這個討論的環境是適合發言的 那在發言的環境以外 我們還有很多可以 鼓勵發言的方式 第一個就是讓團隊成員可以信任 做決策的方式跟過程 以我們的例子來講 我們就是讓所有人都可以參與投票 那大家都看到投票的結果是怎樣 但是這可能比較適合 小一點的團隊 如果你是一個三五十人 大一點的團隊 有可能只有各部門的主管能夠參與決策 那其實也是可以做到這一點 但是我們要做的目的就是 我們要希望讓團隊成員能夠相信 就是這個專案在開發過程中 他的決策的過程 不是某一個人 就是一時興起的決定 而是我們眾人一起討論 一起投票的結果 最後就是要讓團隊成員看到 他們的討論 真的會影響事情的走向 這樣子久而久之 團隊成員知道說 我講的話真的會被做出來 那時間一久 在下一次會議團隊 就會越來越願意發表意見 最後除了 以上的討論之外 還有很多是在 除了討論的過程還有很多是在製作的過程中 那很多人也會想要知道 如何讓團隊的成員在製作的時候 更自動自發 那下面這幾點是我認為 很重要的觀念 第一點也是最重要的一點 就是要讓團隊成員對這個專案 有一個擁有感 那這個意思就是團隊成員 會感覺自己真的參與製作這個遊戲 甚至是 擁有這個遊戲的一部分 而不是覺得說我在幫老闆打工 或是我在幫主計劃打工 那你要讓成員有這個想法 最重要的就是 我前面提到的那幾點 每個人都要能夠參與討論 而且每個人 那個講出來的東西 都真的有可能會影響 事情的結果我這邊不是說 老闆跟製作人 不能夠提他的意見 老闆跟製作人要提的應該是 專案的大方向 而不是去計較一些 開發中的一些小細節 第二就是專案 必須要有一個明確而且一致的目標 團隊才能看到一個 清楚可行的計畫 要達成這一點最主要的目的 就落在製作人跟負責 專案管理人身上 首先製作人要能夠清楚的理解 遊戲的願景是什麼 在製作的過程中 要不斷的努力讓所有開發成員 都擁有一致的願景 再來就是在里程碑結束的時候 團隊要對 前往願景的這個計畫 進行檢討跟改進 這樣子隨著時間的推進 每個成員腦中的願景 就會越來越一致 而且也能越來越清楚看到 我們整個團隊是要如何 一起走到這個終點 那在開發過程中 一定會有沒有預料到的問題 發生 為了盡可能讓事情能夠提早被解決 或防止問題越滾越大 團隊一定要營造一個 任何人都能夠 提出而且願意 提出問題的一個環境 那在聽到環境之後 聽到質疑之後 團隊也要很誠實的分析跟面對問題 絕對不是無視 或者是騙自己沒有問題 最後在開發過程中 一定會有很多事情是在做之前 你沒有辦法預估的 所以在這個狀況 必須要以團隊為單位來面對 這個決策的結果 因為就像我前面提到的 為了加速決策的過程 我們不要浪費時間在那邊 爭論一些不確定的東西 把時間花費在嘗試上面 會比較有意義 當你嘗試失敗的時候 團隊其實是學到了 這個東西真的不能這樣子做 所以團隊絕對不能夠去怪 當初提出這個想法的人 而且因為當初 那也是大家投票的結果 那就代表說團隊裡面大部分的人 都沒有預想到會有這樣的結果 那團隊應該要學的事情是 如何以團隊為單位 去承受這個結果 而不是去怪當初提出 那個想法的人 好 我的分享到這裡結束 好像時間剛剛好 對 謝謝大家 謝謝大家 touchdown 謝謝大家 謝謝 謝謝 非常感謝 讓我們我同學 anal everything 感激的 平上 跟 особ 而且 的過程當中 你們團隊遇到 最大的問題是什麼 是在哪一個階段呢 然後原因是什麼 因為我們是一個 全新的團隊 對 所以其實 沒有什麼太大的問題 對 然後我們算是運氣蠻好的 就是團隊的成員 都算是很理性 可以溝通 然後大家也蠻相信我 所以基本上就是 我們就是不斷的 適用 然後修正 對 就是 這真的要講 其實沒有什麼太大的問題 對 謝謝 謝謝 左邊那位 你好 謝謝你的分享 我想請問的是 假如在開發過程中 你們想到了一個 很符合你們專案願景的feature 例如可能是 更進階的敵人AI 或是 更好的場景渲染效果 但是現階段團隊裡面 並沒有 可以勝任這項 開發工作的人力 那這個時候 你們可能就面臨幾個選擇 例如說 你們是要找更多人加入 找外包 或是請現有的成員去學習 或是就直接放棄這個功能 那想請問你們有沒有在開發過程中 遇到這樣的經驗 那你們是怎麼做評估的 謝謝 OK 我們沒有遇到類似的經驗 但是我們在開發的過程中 是有遇到幾次 就是遊戲玩法 尤其是核心的戰鬥 大砍 我們至少大砍三次 對 那這時候的狀況就是我們 就像我前面提到的 我們在包完版本測試之後 我們認為 我們做出來的東西 沒有達到我們想要的需求 因為我們前面提到 我們想要一個流暢的戰鬥系統 而且我們想要有一個 就是這個戰鬥系統 它是有一個足夠的深度的 那我們做出來測試了 我們覺得它的深度不夠 或者是它玩起來不夠流暢 那我們就是以整個團隊 重新做下來 就是我們去思考說 好 那我們要怎麼樣做到一個流暢的戰鬥系統 就是我們去 可能是重新做下來的戰鬥系統 就是我們去思考說 我們去思考說 我們去其他遊戲去參考 或者是我們從現在遊戲裡面 我們覺得會卡的地方去做修改 對 所以像你提到的那個問題 我認為是 如果真的有一個東西 可以大幅度的增加遊戲的 就是品質 那團隊的確是要坐下來去討論說 OK 我們做了這個東西 對遊戲的整個專案的幫助有多大 那我們需要 可能多花多少錢 多少時間 我們來做到這件事情 對 就是 我們的遊戲 我們的遊戲 以我們的例子來講 我們做了至少三次這樣子的狀況 那就是像我講的 就是團隊要以一個 那個 整個團隊當作一個單位 去承受 來做這個決定 然後團隊要一起去承受 你們做的決定的這個的後果 因為有可能你找了新的人進來 但是他要多付錢 或者是這個人 他可能跟團隊的氣氛不合 這都是有可能的問題 那團隊要在 就是做決定之前 就要想好說 OK 我們願意承受這個結果 我們再去做這個改變 好 謝謝 感謝分享 老師你好 那個我想要詢問的是說 如果說你今天是一個 這個團隊中的 比較一個基層的成員 或是一個比較 沒有這個管理職的 這個成員的話 你要如何去協助這個團隊 或者說你要如何去說服 這個上面的人 去實踐這樣的一個流程 OK 這個其實我有經驗 因為我最一開始也不是說 一進來就是什麼主企劃 或一進來就是製作人 我一開始也是從 就是最基礎的企劃開始做 那我的建議會是 你可以看我這份簡報裡面 你認為 馬上可以應用在 你們團隊裡面的一些東西 例如你可以試著從 一個討論的環境裡面 開始改善 就你不用急著 把整個流程全部翻掉重做 但是你可以試著說 我們在討論的過程中 我們在討論的過程中 假如說 有人打斷其他的發言 那你可以試著讓主持人 或者是如果運氣好 你就是主持人的話 你可以試著讓他去 營造一個 就是更適合發言的環境 那你可以慢慢 一步一步的往外擴散 就是從這份簡報裡面 你覺得有幫助的點 一點一點慢慢的去執行 對 OK 好 謝謝 你好 謝謝你的分享 那個其實感同身受 我就覺得說 其實引領 團隊到達同一個目標 製作人在一剛開始 把拼圖畫清楚 讓大家去供購這個拼圖的過程 其實是相當重要 但是就是想請問一下就說 因為我覺得遊戲產業與一般工作 它有個最大不同點 在於說遊戲是跟大家生活 非常貼近的一部分 所以很多人在 製作人表達願景的時候 他可能心中已經有一套 他自己未來想象遊戲的樣子 那我想問一下 你們在開發過程中 有沒有碰過這樣的團隊成員 然後是怎麼樣去解決這個問題 謝謝 OK 這個問題非常常見 對 就是在我們自己團隊裡面 就是我跟製作人 或是可能像我們其他城市或美術 我們其實 前面我們雖然說 我們是很理性可以溝通的人 但其實我們都非常的 有自己的想法 對 要不然我們不可能說 會就離職出來創業 對 所以像你講到的這個狀況 製作人要做的事情就是 你要 讓大家的意見能夠統整在一起 那你也要讓大家知道說 為什麼 為什麼要 做你現在的這個想法 就是你要去試著去說服大家說 你的這個想法是對的 但是反過來 當我們的測試結果 或你做出來的結果 證明了你的想法是錯的時候 你也必須要去承認說 對 我原本的想法是錯的 那我們來試試看A的想法 我們來試試看B的想法 或者是我們來討論出一個 折中大家共同喜歡的想法 這樣子 對 那我想問一下就是 在這個找想法的過程中 會不會耽誤到 開發的程序 大概會Try and Error 可能會花費太多的時間這樣 我只能說 以 就是遊戲製作來講 有一個正確的方向 其實比開發的速度還要重要 對 因為你往一個正確的方向 你可以做出一個很好玩 很小很精緻的遊戲 但是你往一個錯誤的方向 你可能做出一個很大 不好玩的遊戲 對 那團隊你可以自己去選擇 你要做的是哪一個 那我個人的習慣是 我們 我身邊跟 我們認識的人 都是喜歡小而精緻 然後就是內容很一致的遊戲 對 就是這個的 耗費的時間是一定會有 這個是不能避免的 對 謝謝 我也覺得就是引領團隊 在一個共同的氣氛下 有熱情的去鑄造一款遊戲 它會是一個很好作品 謝謝 好 謝謝這幾位來賓的問題 也謝謝講師的分享 那我們再一次掌聲 謝謝今天的黃思成講師