【遊戲開發】遊戲開發日誌Vol.6

CreSpirit是個以美術為主的遊戲開發工作室團隊，

就連負責當前專案的程式Jimbow，也是由美術轉職而成，

在此綜合兩邊經驗，分享其至今開發遊戲所歸納出的看法，

如果有朋友初學但想嘗試遊戲開發，或許會是不錯的參考：

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

【程式叭啦叭啦－Jimbow】

安安我是嬸婆，負責此專案的技術美術、遊戲前端、遊戲後端、

專案管理、規格撰寫、行銷規劃…等等剩下的不用畫圖的工作ㄏㄏ

（下列為測試畫面，實際物件圖於最後才置換）

這個案子的核心在個人評估來看，主要是有幾個核心原則：

1. 展現視覺
2. 玩家體驗：多汁、忙碌但愉快、操作單純，卻策略思考
3. 程式品質：穩定、優雅
4. 社群要素：真人、故意、針對個體

－－－－－－－－－－－－－－－－－－－

1.視覺表現：

　　本團隊在美術上有相當的品質（自己講），
故在程式執行面上，「達成視覺」是第一要務；
將視覺優點發揮到極致、配合美術輸出的檔案、
多樣的豐富的武器動作、換服裝、大量的奇怪愚蠢的武器設定、
沒有意義的跳舞功能等等，這些為最優先項目。

－－－－－－－－－－－－－－－－－－－

2.使用者體驗：

　　接下來是使用者體驗，「豐富」「多汁」等等高回饋的遊戲模式，
讓玩家進行少量的操作，卻能得到一連串、連鎖、放鞭炮的回饋：
例如玩家點個攻擊，角色會作開槍動畫、槍枝會調出彈殼、彈殼掉滿地會燙人、
敵人會有受傷音效、濺血、不同多樣的受傷動作、被擊飛、爆炸分屍。
或是戳畫面上的路人，會抖一下或叫一下這類愚蠢的回饋，也是很有用的。

　　玩遊戲最基本就是殺時間，所以讓玩家忘記時間流逝的黏著度是很重要的，
直接的實作方法就是「一直有事作」「必須親自決策的事」「沒有我不行」這類。
動作遊戲本身就是「放著不動主角會死」所以要減少自動攻擊的砲台、
靈氣效果這種「沒有玩家操作也無所謂的」設計。
在其他動作遊戲的 boss 關卡，也常會出現強力的地圖攻擊，
逼迫玩家必須走位移動的，是負向驅動的例子；
掉落道具若一段時間不撿的話就會消失，則是正向驅動的例子。
驅使玩家「不得不做」的動力，是一個遊戲性重要的要素。

　　操作簡單卻需要策略思考，則是用「時機」來達成。
例如玩家行為一樣是按攻擊鍵而已，但滿血的時候按、
硬直得時候按、受傷的時候按，出來的效果卻不一樣。
這種決定按的時機，是需要思考的，但執行方式卻都一樣只是按同一顆攻擊鍵。
好處是操作門檻降低，三歲小孩都會按；但同樣都是按，
菜逼八按的結果卻跟老鳥按的不一樣。
兼顧深度與廣度的一個設計，也是本專案追求的。

－－－－－－－－－－－－－－－－－－－

3.程式品質：

　　程式的品質穩定，則純粹是一個用時間磨出來的。
debug 的時間預留的愈多，當然玩家遭遇閃退的機率就低了、
相容的機器就多了、fps 就高了、效能就全開了。
除了程式功能的達成之外，用更聰明的方法達成同樣的結果，我個人稱之為優雅。
例如我從其他網站點選了 facebook 的連結，
跳到 facebook 網站之後會自動從 cookie 判斷該使用者是否曾經登入過，
而不是傻傻的再逼使用者登入一次，就是優雅的表現。

－－－－－－－－－－－－－－－－－－－

4.社群要素：

　　社群要素，純粹貼文分享是個糟糕設計，
其他人只會看到一個透過軟體貼到你塗鴉牆的廣告，而沒有任何效果。
真正的社群功能設計要來自「自然人」「故意」
「有意識的行為」「針對某人」才有廣而宣傳的效益。
例如前陣子大流行的臉書偷菜遊戲，你的菜被偷，
是被你的朋友「本人」「有意識的」「故意」偷「你的」菜的，
所以你才會覺得生氣、度蘭、報復心態，而不是只是貼到塗鴉牆的一則廣告。
社群要素說穿了就是激起玩家的情緒，讓玩家覺得有同儕壓力、
競爭、報復、嫉妒、羨慕等等情緒波動，效果才會出來。

　　「針對某人」也是社群很重要的因素，
例如 candy crash 可以跟朋友索取愛心，但如果是跟「所有朋友」索取愛心，
這個被索取的朋友就會愛理不理的「反正不是針對我」，這功能等於就沒屁用。

－－－－－－－－－－－－－－－－－－－

★.執行層面：

　　網路上常有文章說明老鳥與菜鳥的差異，老鳥規劃多，菜鳥執行多。
但，要怎麼作規劃？有哪些項目需要規劃？我規劃了要怎麼跟其他人溝通？
或，真的需要規劃嗎？

　　規劃的存在感最高的時候就是，多人合作。而台灣的風氣是自幹，
所以這方面的資料與觀念一直很缺乏。
每個人背景知識不同，要怎麼把動畫分資料夾？圖片怎麼命名？
我要怎們跟介面設計師溝通？美術丟過來的圖根本沒去背？
後台資料庫跟前台欄位不一樣？以上種種煩惱，皆因沒有規格書，
也沒有寫規格書的人。什麼是規格書？

（右鍵另開啟可放大）

　　上圖是本專案 unity 場景的流程圖。在圖中分四個大區塊：
stage managr, battle manger , game logic sections , static enviroment .
一旦把區塊分出來了，光靠這張圖，就可以一個 unity 場景分工給四個人去執行了。
那成員之間怎麼交流資料呢？就是用圖中的那些箭頭，
stage manager 會呼叫 battle manager 的某些函式，
game logic 有哪些函式是給誰呼叫的，用一張圖就可以清楚的規劃出來。
當某人呼叫了他不該呼叫的函式時，就可以用這張流程圖去幹他，叫他重作；
當實作時發現規格書規劃錯誤，就去幹寫規格的人叫他重改，
選個良辰吉日公布規格修改。

　　一旦牽扯到多人合作，寫規格書、流程圖等等文件工作是很重要的。
他是成員之間討論的依據、視覺化的圖表更有助於非相關背景知識的人員理解、
促進美術與程式的良性合作。也是驗證成員之間執行錯誤與否的法源依據：
要幹你的同事，除了大聲之外，還得靠這份規格書。

－－－－－－－－－－－－－－－－－－－

　　目前進度還不適合貼出來，下次輪到我寫日誌的時候，
希望已經有 gameplay 影片能釋出了，敬請期待：D

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

【關於主題】

Jimbow在兩者結合這塊有相當強的溝通理解與執行力，

如果有接觸獨立遊戲開發，過去多多少少也應該是看過他的作品，

雖然在本隊扮演唯一程式，卻懂得何時該自幹何時該運用資源，相當優秀，

也因為是從美術轉型、能獨立完成專案之故，本身也具一定程度的審美能力，

與主美在溝通上較能達成共識，要我自己說嘛…都是難能可貴的開發戰力！

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

【製作叭啦叭啦】

Jimbow過去也是個美術，直到膝蓋中了一箭…

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

前方傳送門：遊戲開發日誌Vol.7

後方傳送門：遊戲開發日誌Vol.5