創作內容

48 GP

[ 論遊戲 ]以專案開發概念管理遊戲製作-《進程篇》

作者:哈利菠菜│2013-09-23 09:58:34│贊助:96│人氣:3718

圖片引用自 HJL

在上一篇文章《工作劃分篇》中,我提到了在遊戲中設定需求項目的方法,而這次要把小圓圈再放大,工作劃分除了細節的描寫外,更重要的是如何安排每一個階段的進程,在這裡我導入的是敏捷開發專案管理框架「Scrum 」的觀念

過去工作分派後,日常生活會呈現兩種情況,一種是緊迫盯人,每天照三餐問對方東西作好了沒,一種是放牛吃草,反正等時間到了東西有出來就好

在工作分派前,整個遊戲製作沒有任何明確排程,好比遊戲什麼時候作好,遊戲什麼時候要做到什麼樣的地步,都沒有統一的規範,甚至有明確排程的情況還比較像是,「程式向美術要元件,問美術什麼時候可以作好」的時候。多半情況下,美術不知道遊戲到底整體作得怎樣,程式也不知道美術進行到哪,如此沒有章法的作法,很容易拉長遊戲製作的時間,甚至最終產出了只作出一半的作品



老實說,我沒有辦法提出讓遠程工作的夥伴,能夠永遠為一個專案無條件犧牲奉獻的方法,好比某A突然收到兵單,總不可能在他隔天去火車站的路上綁架人家吧,所以異地工作的無酬方式,本身就存在各種不定的風險 。・゚・(つд`゚)・゚・

但如果大家決定一起坐下來完成某件事情,最後卻因為怠惰、茫然、混亂等管理不當的因素導致拆夥,我認為這是非常可惜的事情,台灣也因此少了一個有潛力的新星,倘若導入專案管理的方法,或許就能夠降低風險,這就是為什麼哈利菠菜要提出一個遊戲團隊管理模式的原因了



關於敏捷開發與「Scrum」的詳細內容,可以到 Wiki 上檢索,畢竟是非常成熟的軟體管理框架,網路資料眾多所以我在這裡僅就適合遊戲開發團隊的方法作分享

不管你的遊戲有多大,在遊戲製作開始都要設定一個「進程」,而團隊必須要在進程裡面完成開始進程前所設定好的需求項目,這個進程的長度多半是兩週到四週




當然我的意思不是要團隊爆肝,幾週就把東西全部生出來,而是透過一個進程一個進程的連接,慢慢把遊戲作好。但遊戲的事情這麼多,我們要怎麼決定進程裡面該做哪些事情呢? 該從哪一個項目下手比較好?

在這裡,我會建議優先以「讓遊戲可以展示」為最高準則,也就是想辦法先完成最小可行性產品,在那之前團隊要先討論出最小產品應該要有哪些功能,並針對這些功能設定需求項目

在以「最小產品先行」的前提下,程式端負責的需求項目可能如下(建議需求項目不要一次開很多,因為進程完畢之後一定還會再回頭修正):

ID 名字 重要性 備註 時間
101 玩家可以看到開始畫面的背景與4個按鈕
按鈕分別是重新開始/讀取存檔/工具/人員名單
90 需導入背景圖像
4個按鈕圖像
5P
102 玩家可以點選重新開始按鈕進入遊戲 80 進入遊戲後先展示一張jpg底圖 1P
103 玩家可以點選讀取存檔進入遊戲存檔介面 80 需導入界面圖像 1P
104 玩家可以聽到開始畫面的背景音樂 80 需導入音樂 2P
105 玩家可以點選工具調整音樂、音效、畫面品質選項 80 需導入介面按鈕 4P
106 玩家可以看到場景上的主角 80 需導入人物圖像 4P
... ... ... ... ...

美術端的需求項目可能如下:
ID 名字 重要性 備註 時間
201 玩家可以看到開始畫面的背景與4個按鈕
按鈕分別是重新開始/讀取存檔/工具/人員名單
90 背景大小JPG1600*900
4個PNG按鈕大小100*80
詳細位置參考9/18的會議檔
4P
202 玩家可以看到進入遊戲後的第一個場景 80
背景大小JPG1600*900

4P
203 玩家可以看到存檔的介面 80 背景JPG1600*900
1個PNG按鈕返回大小100*80
詳細位置參考9/18的會議檔
2P
204 玩家可以看到工具的介面 80 背景JPG1600*900
3個PNG按鈕返回大小100*80
3P
205 玩家可以看到人物站在場景上 80 45張序列圖,各單位大小300*200
圖檔不可超過800KB
7P
... ... ... ... ...


經過第一次開會後,團隊決定好首個進程要花10個工作天的時間來執行,所以美術跟程式都各有10P的時間單位可以用,程式的話可以選擇作101+102+105的選項,這樣加起來的時間單位剛好是10P,而美術的話可以完成201+202+203的需求項目

在這裡建議美術與程式都要開一個雲端協同工作 ( ex.Dropbox ) 的資料夾,只要美術一有新的東西更新到裡面,程式就可以直接套用,免得每次作好東西還要打擾正在工作的對方




兩邊如果有完成該項目的需求時,可以用協同工作表 ( ex.Google 文件 ) 中的試算表進行管理,把需求項目後面再多一個完成與否的欄位,只要完成一項需求就先把該需求作標記,以方便管理跟檢查



進程中,我會建議團隊所有成員,每天都要花15分鐘的時間用 Skype 開視訊會議,主要討論昨天作了什麼事情,時間盡量不要太長,如果少於15分鐘也可以,這樣的方式可以確保團隊的默契,同時讓整個進程步上軌道,當然能用視訊討論是最好,如果不方便,隨便用一個線上聊天室都可以

當進程結束後,團隊要開一個 Demo 的常會,檢討進程中的問題,好比說程式發現某個功能實作要花比較久的時間,屆時後面的某個項目時間就要修正,而美術可能也發現作某個東西的時間不必要這麼久,於是把一些時間單位再作縮短,或是說
Demo 的時候發現程式出現某個bug,倘若該bug沒有在未來的需求項目中,就要安排到下一次的進程



Demo 結束後設定下一個進程的時間跟內容,就這樣反覆的進程>Demo>進程>Demo...,遊戲就可以慢慢成型囉!   (๑•̀ㅂ•́)و✧



看到這裡,你可能會想說,每天說自己昨天作了什麼事情很重要嗎?
「是的,非常重要」這時候某個路人甲跳出來「要監督大家有沒有作事情 ( • ̀ω•́ )」
首先謝謝路人這位熱心的路人甲 ( 喂 ),其實....這是非常錯誤的心態 ( 打臉 ),所謂監督是建立在不信任的基礎,如果團員存有貳心,那我建議拆夥算了,作遊戲的確會有壓力,但如果變成罪惡感,對團隊、對整個遊戲都不好 (。ŏ_ŏ)

遠端工作建立在團員的高度"自律"上,所以每天15分鐘討論的重點不是在於檢查有沒有作事,而是讓整個團隊參與過程,讓程式知道原來美術要做這些事情要這麼多心力,美術知道
原來程式要建立一個功能是多麼傷腦,每日會議因此增加了團隊凝聚力


中國獨立遊戲 《雨血》

另一方面,如果有問題也可以在現場提出來,倘若專案開發有兩個美術,那美術可以跟企劃討論風格統調的問題,即早先作修正,程式如果發現該功能開發有困難,可以討論是否要選擇折衷的方式開發 ( 當然這要看折多少,如果把 RPG 折成 AVG 就折的稍微大了一些 ( ºΔº |||))

一個進程結束後的 Demo ,其用意在於隨時讓產品處在完整階段,藉此增加團隊的信心跟士氣,「喔喔喔! 人物可以在上面移動了耶」、「沒想到介面放上去看起來好屌」,美術會看到自己的東西馬上被實作的樣子,有些時候「東西能不能跑」比美術畫很漂亮或程式碼寫得很完善要重要許多,有了成果後,也更願意持續投入心力在遊戲創作中了





無論如何,管理只是一種工作的方法,並不是萬靈丹,不是導入管理就可以百分之百完成遊戲,身為製作人/領導人的你,還必須隨時扮著黑臉與白臉,隨時激勵大家的士氣,某些時候要很樂觀,有些時候要比任何人都看得見痛處,必須要能夠統御大家完成作品,並以身作則,要比團隊中的任何人更遵守管理的章法,在大東京玩具箱這本漫畫第五集裡是這麼說的 :

『只有一個人的自我、能量是大不到那裡去的。唯有把所有人的自我都融合在一起,才能完成一款遊戲。所以才會有人說,電玩不是一個人能做出來的。』( 圖文截取自 銀狐 Silver Fox 的碎碎唸 )



在進程篇中,大家是不是比較清楚管理遊戲的專案了呢? 相信導入這樣的管理模式,可以很快讓遊戲製作步上軌道,如果手上已經有遊戲開發計劃的朋友,可以開始試著把加進自己的團隊中喲,另外如果團隊還不明白要怎麼作,我也很樂意參一腳當個小顧問,聽聽你們的狀況或想法,台灣萬歲、獨立遊戲製作萬歲 ヽ(●´∀`●)ノ   

---
歡迎各路好手踢館討論  (*´艸`*)
---
引用網址:https://home.gamer.com.tw/TrackBack.php?sn=2182012
All rights reserved. 版權所有,保留一切權利

相關創作

同標籤作品搜尋:專案開發|遊戲設計|自製遊戲

留言共 7 篇留言

Kaine
我認為先提交出能讓人知道「我們想做出什麼」的內容很重樣
在作品為完成之前都是需要保留的,沒有人會曉得你們在做什麼
但同時你也必須做出一定的宣傳動作,這就是先行發表的內容。
經常看到某些團隊(不管事社會還是學校),拼死拼活的要趕出「完整」的作品
結果反而是本末倒置,不僅作品不夠完整,而且還很潦草無章
很多時候都是自己逼死自己,但實際上有進行規劃排程
工作就能很順利的進行,作品也能呈現給大家完整的面貌。
其實講到回想昨天做了些什麼,我覺得自己的個性好容易怠惰啊(艸
有幹勁的時候就異常勤奮,沒幹進就癱在地上跟軟泥一樣(?)


https://truth.bahamut.com.tw/s01/201309/0c56246b166ea8d6ed21729704a02c1f.PNG?w=300
您這縮圖感覺就好像想騙人進來閱讀一樣XD

09-23 10:32

哈利菠菜
是阿是阿,所以不能讓成員有一種
「不管我們做多少,怎麼都看不到成品」的感覺 _( :3┘)_

很多人也都會有益興闌珊的時候~ 這是正常的XD
所以才要有些壓力跟規範囉 09-23 16:51
哈哈小熊
GOOD

09-23 12:26

哈利菠菜
3QQQQQ~~~~ 09-23 16:48
非無也
太好了,正好專案在寫遊戲,請問可以引用您的好文嗎XDD

09-23 16:45

哈利菠菜
當然可以啊XDDD 歡迎引用啦~~ 如果有人有提出不同的見解,還請務必跟我說 (握手)09-23 16:47
啾比❖咩
一個好的團隊的領導,必定是擅長整合團隊,能夠看大局,以及有責任感的人
哈利菠菜的文章很多都很專業啊XD
一直以為你真的有進過遊戲公司工作過XD

09-23 19:22

哈利菠菜
最近看半澤直樹,他就是很好的榜樣耶~
這些都是興趣啦,會打這些文章主要是給正在製作遊戲的團隊一個參考
能夠讓已經在業界的你有共鳴,真的是很開心 : )09-23 20:25
啾比❖咩
然後公司的雲端非常重要...要保護公司的資料之外,也要確保內部員工的東西能減少傳檔案的時間,有效率的做事方式一直都是業界很重視的~
Dropbox不太建議說...以前待過的遊戲公司有用過,太小了XDDD
而且任何人都可以隨意更動檔案不太安全

09-23 19:24

Wei
上禮拜就看到這篇,好想回覆,思考了很久@w@"

我沒有參加過大型團隊的遊戲開發,都是和很少數人一起合作的。
自己其實不喜歡所謂的"管理",但是隨著人數增加,確實有人要負責搞清楚狀況,那又很難不扯到管理。

每個團隊應該都有自己適合的方式,我覺得要做專案管理最重要的事有兩個:
1. 讓合作夥伴信賴,也相信合作夥伴。
2. 清楚了解一起合作的夥伴們(也就是整個團隊)的狀況。
Scrum的部分,我覺得重點是在他的精神,實際上的做法還是要看團隊而定。
Google Doc和Dropbox(或GoogleDrive)就沒話說了XD 好東西,推薦 +1!

09-29 21:59

哈利菠菜
沒錯...隨著團隊壯大,想要讓作品更好
要嘛就專職,要嘛就找更多人XDDD 人越多,就更要管理
要管理就會碰到很多麻煩麻煩的事情 Q^Q
你提到的那兩個軟體都超好用的哈~ 我們公司用doc做人員的班表
讓人員自己在家裡就可以查閱班表了~ 類似這種小功能
卻也減少公司許多的成本 (紙張成本、時間成本、人力成本...等等)
當然管理也要精簡,不過我的認知是
簡單的管理,背後是各種嚴格的控制與要求 才能達到「簡單」09-30 03:58
┌♥ ┤厘子├♥┐
其實我總覺得,私底下就是自製遊戲這種是無酬又需要靠熱情來支撐的事物
有時候有些人會認為....需要搞得這麼多步驟嗎?這麼系統化看起來就好麻煩="=
怎麼感覺跟上班開例會一樣,怎麼感覺跟上課交作業一樣讓人提不起勁ˊˋ

但事實上,沒有這些循序漸進的規則在潛移默化地引導大家~
真的很難完成一件事情....如果常常一事無成或是虎頭蛇尾的人就會知道了XD

10-08 17:44

哈利菠菜
哈哈哈,我可以完全體會 虎頭蛇尾這句話 (掩面)
以前總想一個人做什麼大事,後來有機會與大夥共事的時候
我才發現一群人作事情,大家互相激勵 互相往一個地方邁進時
感覺比較不那麼容易放棄XDDD 不過終究是感覺啦
如果有人要擺爛也沒辦法(嘆)....
系統化是一種管理的作法、模式~~~並不是說非常必要
但不失為可以增進效率的手段10-08 19:13
我要留言提醒:您尚未登入,請先登入再留言

48喜歡★a7701032002 可決定是否刪除您的留言,請勿發表違反站規文字。

前一篇:[ 論遊戲 ]以專案開發... 後一篇:[ 論遊戲 ] 企劃遊戲...

追蹤私訊

作品資料夾

Kyc763929知道的人
哪邊有在賣顯卡? 螢幕時常跳掉黑頻啊啊啊啊啊啊!!!!!!!!看更多我要大聲說8小時前


face基於日前微軟官方表示 Internet Explorer 不再支援新的網路標準,可能無法使用新的應用程式來呈現網站內容,在瀏覽器支援度及網站安全性的雙重考量下,為了讓巴友們有更好的使用體驗,巴哈姆特即將於 2019年9月2日 停止支援 Internet Explorer 瀏覽器的頁面呈現和功能。
屆時建議您使用下述瀏覽器來瀏覽巴哈姆特:
。Google Chrome(推薦)
。Mozilla Firefox
。Microsoft Edge(Windows10以上的作業系統版本才可使用)

face我們了解您不想看到廣告的心情⋯ 若您願意支持巴哈姆特永續經營,請將 gamer.com.tw 加入廣告阻擋工具的白名單中,謝謝 !【教學】