WAERO

幾乎都出沒在噗浪:https://www.plurk.com/DigitalLover

2015年5月14日 星期四

【遊戲開發】遊戲開發日誌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

4 則留言:

歡迎轉載,但請務必註明來源:http://waeroblog.blogspot.tw/