圖片引用自redjuice999
最近看到巴哈姆特有一個自製遊戲的公會，哈利菠菜身為老屁股不加一下實在說不過去XD，稍微瀏覽公會內容，在不斷有老手新手加入更新的情況下，資料蘊藏十分豐富，而且公會幹部們都十分熱心。在這裡特別呼籲後進，如果有興趣往這方面走，可以加入一下自製遊戲公會，除了是學習的機會，也是值得磨練武技的道館
另外我也發現一個現象：有蠻多遊戲開發的團隊，成員組成多半不是很熟的人 (´⊙ω⊙`)
很多情況是在網路上號召不同領域的網友合作，某A會美術那就幫忙畫元件，某甲會程式那就幫忙code，某子會音樂那就幫忙編曲，有很多成員是彼此未曾謀面，不像古代結識豪傑"不打不相識"，當然現在也是打，只是從打拳變成打鍵盤了，儘管網路加速製作團隊的磋合，但團隊的默契不佳，尤其大部分情況又是遠距分工，容易產生一些隱憂：
1.信任度低 ／ 2.穩定度低 ／ 3.管理不易
我自己過去無論參與或組織團隊，也遇過不少問題，好巧不巧，都是因為某些必須要達成的目標而半強迫組織在一起，最近看了一些開發管理的文章有些心得，於是我把過去開發經驗跟管理的概念融合，希望讓各位開發者不要再這麼累的通通自己來，也可以不要看著延宕的進度唉聲嘆氣，當然以下的管理方法或工具還沒有經過實測，但有興趣的朋友歡迎導入自己的團隊，倘若有任何建議或指教，歡迎跟我討論喲，我很樂意與您暢談任何一個細節（＜ゝω・）
※
所有多媒體設計領域裡面，「遊戲」絕對是最複雜的產品之一，因此在製作的過程，除了長時間企劃、系統的發想，更重要的是怎麼去管理這些複雜的進程? 以及維持進度穩定?
我就先跳過去企劃跟發想這部份的環節，直接到開始工作的部分，因為進入正式的開發進程時，團隊基本上應該要對整款遊戲想要賣給誰、想要做什麼樣子都已有共識，倘若連共識都沒有就貿然「畫地圖」，只怕大家點頭不交心啊....
首先每一個製作遊戲的團隊，都至少要能夠繪製下面這種架構圖，其實說是架構圖，也可以看作是遊戲開發前的必備地圖
這是桃轅傳的系統架構圖，只要可以畫出這張圖，就基本能掌握遊戲的架構，總體而言桃轅傳會有以下幾個系統
一、主要介面
二、戰鬥系統
三、場景環境
四、事件處理
五、動畫處理
六、音樂處理
七、狀態系統
這七個主要區塊架構起桃轅傳，想當初還不知道作這種架構的時候，悶著頭把東西做出來，就像蓋房子不打草稿一樣，因為邏輯混亂、加上沒有規畫，花了兩三個月作的東西還是打掉了，尤其是戰鬥系統，又再花了三個月才重新組好。所以千萬不要鐵齒，就算是作很簡單的小遊戲，都應該要有這種地圖的架構才行
系統設定出來後，就可以去評估每一個環節應該還要再細分做多少事情，並且設定每一個細小的項目大概需要多少工時的時間。以戰鬥系統來說還可以再分為：
回合系統－時間軸計算
－常態增加的屬性計算
能力血量計算－人物屬性換算攻擊、防禦、血量等戰鬥用屬性
－敵方屬性換算攻擊、防禦、血量等戰鬥用屬性
特殊系統－角色的特殊狀態反應（中毒、催眠）
－角色使用道具
－角色逃跑
敵方－呼叫敵人的圖案到場景上
－設置行為偵聽（受傷、攻擊、死亡、詠唱等行為）
我方－呼叫我方的圖案到場景上
－設置行為偵聽（受傷、攻擊、死亡、詠等行為）
如果你像我一樣把系統細分成上面這副德性，其實是大錯特錯...我也相信有些一踏入門作遊戲的人，在分程式架構的時候都是像我這樣的分法，看起來專業不過暗藏危機
※
儘管這樣的畫分法符合邏輯，但有些功能之間其實是有鏈結的，好比說呼叫敵人圖案跟呼叫我方圖案，這兩個可能只是在變數上作調整，沒有必要再拆分進來。同時這種拆法，除了當初設計的我看得懂之外，其他人應該只『看得懂字面上』的意思，甚至還會想為什麼哈利菠菜要這樣分？倘若今天換成另外一個程式負責人來看這個架構，大概會翻白眼
畢竟每一個人看待「地圖」的方式不同，好比說有人看台灣地圖是橫的，有的人看直的
為了讓整個功能設計變得更客觀，我們要換個角度來思考系統的架構，要怎麼換呢？我們要從玩家的角度去想功能的設計，請熟悉這個句子：「玩家可以...」。以桃轅傳戰鬥系統這個例子來說，大概可以分為下面幾個
玩家可以進入戰鬥場景
玩家可以看到對面的怪物
玩家可以看到戰鬥中的界面
玩家可以看到敵我雙方的血量
玩家可以在戰鬥場景中使用普通攻擊
玩家可以看到自己被打時的受傷效果
玩家可以看到敵方被打時的受傷效果
玩家可以體驗到時間軸的即時戰鬥
玩家可以在戰鬥場景中使用特殊攻擊
玩家可以在戰鬥中使用道具
玩家可以在戰鬥中逃跑
玩家可以在戰鬥中使用援助攻擊
玩家可以聽到戰鬥的音效
.....
這樣以功能來作為系統製作的基準，是不是比上一種方法明確許多?而且這樣的好處是，你可以把自己當作玩家，客觀地融入到遊戲創作裡，從進到場景首先看到場景上的背景，再看到怪物，接著看到敵我雙方的界面....如此一來，當團隊在想要加什麼元素進去的時候，也變得更大膽更直覺
所以我們可以為戰鬥系統作一張需求項目表格
| ID | 名字 | 重要性 | 備註 | 時間 |
| 201 | 玩家可以進入戰鬥場景 | 80 | 需導入背景圖像 | 5P |
| 202 | 玩家可以看到對面的怪物 | 80 | 需導入MON圖像 | 3P |
| 203 | 玩家可以看到戰鬥中的界面 | 80 | 需導入界面圖像 | 3P |
| 204 | 玩家可以看到敵我雙方的血量 | 70 | 2P | |
| 205 | 玩家可以在戰鬥場景中使用普通攻擊 | 80 | 需導入特效圖像 | 6P |
| 206 | 玩家可以在戰鬥中使出QTE 必殺技 | 30 | 待討論 | 10P |
| ... | ... | ... | ... | ... |
ID不是很重要，就是編號的一種。而重要性那欄位的數字有高有低，高就是重要低就是相對次要，但重要性跟實作排序性不同，他是一個相對數，好比用 QTE必殺技「相對於」其他幾個功能都不是那麼重要，所以會等其他重要性比他高的功能作好後，再來考量到重要性低的功能
由於大部分開發的工作者，鮮少是全職開發，每天能分配到的工作時數並不長，所以時間的換算應該要有一個共識，大家盡量每天抽多少時間來作這個東西，而為什麼會用P的原因是，P是一個時間單位( 當然你也可以取作3D或3Y )，好比1P等於2、3HR這樣，該功能評估需要3P，就可以看作需要3個工作天，用時間單位的作法也比直接用工時換算來得彈性
※
當然有些人會說，怎麼好像都沒有提到美術的工作，畢竟我在作桃轅傳的時候是程式人員嘛，不要這麼計較嘛 ( 淚奔 )，其實上面的區分法，也同樣可以用在美術身上囉，以桃轅傳的戰鬥系統來說
玩家可以看到第一關的戰鬥場景
玩家可以看到人物基本待機呼吸的樣子
玩家可以看到戰鬥中的界面
玩家可以看到普通攻擊的特效
玩家可以看到人物被打的特效
同樣也能作出一張表格出來
| ID | 名字 | 重要性 | 備註 | 時間 |
| 301 | 玩家可以看到第一關的戰鬥場景 | 80 | 圖張大小JPG1600*900 | 1P |
| 302 | 玩家可以看到人物基本待機呼吸的樣子 | 80 | 45張序列圖，各單位大小300*200 圖檔不可超過800KB |
5P |
| 303 | 玩家可以看到戰鬥中的界面 | 80 | 圖張大小PNG1600*900 | 1P |
| 304 | 玩家可以看到普通攻擊的特效 | 80 | 20張序列圖，各單位大小60*60 圖檔不可超過100KB |
2P |
| 305 | 玩家可以看到人物被打的特效 | 80 | 10張序列圖，各單位大小300*200 圖檔不可超過800KB |
5P |
| ... | ... | ... | ... | ... |
如此一來，美術就可以知道要交什麼東西出來了，同時也因為備註仔細的說明，只要隨時交出進度，製作人統一看過OK後，就可以馬上交給程式作出最小可動的產品出來了喲 (๑•̀ㅂ•́)و✧
※
看到這裡，不知道有沒有朋友開始摩拳擦掌，要開始把自己的作品拆分各種細節了呢? 還請稍安勿躁，目前還僅止於把遊戲架構細分的工夫，這些工作其實有點像是針對美術的會議、或是針對程式的會議所製訂為其量身訂作的功能表，但實際上身為製作人的你，還必須要把自己放到更高的地方才行一但你真的把幾百個需求項目全部畫分出來，也只怕面對滔滔海量的表格躊躇不前，所以為了讓團隊可以盡快步上軌道，我們還必須把整個遊戲拆分成更大的進程，並設定一個短期的製作進度，在時間結束時內部展示、檢討修正...這，就是 敏捷開發
聽起來很酷對不對ヽ(●´∀`●)ﾉ 有興趣的朋友可以接著看《進程篇》
---
歡迎各路好手踢館討論 (*´艸`*)
---
