Management

走入荊棘堡壘@政治大學


對話編輯器(Providing editor for Windows x86):https://drive.google.com/open?id=0B08NI1xol314N2lGVEpGNExYS3M

對話編輯器(Providing editor for Mac osx 64):https://drive.google.com/open?id=0B08NI1xol314bkRGWjNHd1lfZXc

20171105

釋出版投影片(slide):https://drive.google.com/open?id=1Ir6myX29mcAzSriLfmN4QRCZeWt0l0qd

演講版文檔(speech article):https://drive.google.com/open?id=1OCgpcyRT23_300FHrOG7Tps1R6GsRJHl

本篇短網址:https://wp.me/pBAPd-yx

以下是"超出完整"題詞稿,注意,本版本可能會有演講沒有提到的段落補充說明。

走入荊棘堡壘,從文案作家到遊戲開發者:如何與技術人員合作,如何實質貢獻開發進度

各位好,我是NDark.我是遊戲程式.

以往我多半都是針對技術議題或是管理議題做心得分享.

這次關於企劃的題目,會引起我的興趣,其中一個原因其實是因緣巧合:因為前些日子,才在網路上跟人筆戰相關的話題.有人說寫作可以整理思緒,所以今天剛好趁這次機會整理一下我的想法.

簡單來說...

之前我曾經說過一個關於如何進入遊戲產業的笑話,也就是"進入遊戲產業之上中下三策":如果你想進入遊戲產業...

舉例:<莽荒纪/我吃西紅柿>:炼气流功法 炼体流功法 神通 剑招 法门 秘术 武器 法宝;后天生灵 先天生灵 紫府修士 万象真人 元神道人 返虚地仙 金丹天仙 纯阳真仙 大罗祖仙 永恒帝君 至尊 混沌宇宙掌控者。

我想大多數人應該覺得上策好像在開玩笑,

以至於都沒注意到是其實我是很正經地諷刺了一個現象.

當我們覺得上策是不可跨越之壁=寫暢銷小說是一件很困難的事情=也就是說相對來說切換自己的專業改跑來遊戲產業比較簡單(或是我可以做得比較好)=遊戲產業做這件事做得沒有我好=遊戲團隊需要我(比我需要他們多).

 

接著我會試著用我的經驗來說明以下這些項目

前半段,嘗試讓大家了解從遊戲產業專案運作的情況,問題或困難.

後半段,介紹開發者實際在處理的資料,有時間的話我會透過一些簡化的情境說明如何跟開發者相處.

 

我希望今天各位最終可以理解,文案作家與遊戲開發者的差異.

 

不免俗的在這些議題之前我先自我介紹...

以時間為軸,我分享的主題從軟體專案管理,品管,團隊,最近一篇文章是關於如何面試程式人員.

雖然職能是程式,但是從我分享過的題目可以觀察到,我越來越不重視技術的問題.

慢慢的我越來越不覺得我在做產品,我開始覺得我的職業是為公司內部提供軟體服務.我也變為內包人員.

前一陣子我去面試工作的時候,我跟面試我的面試官討論到一個話題:技術對我而言是不是重要的...

 

對我來說,或是對每一個專案及團隊來說,其實最大的難題在於團隊運作.

 

有些朋友說:大公司太政治不喜歡,可是從我的經驗來說小公司也有政治問題,小公司因為人少,只要因為政治問題而少一個力量,案子就會直接面臨悲劇=案子做不下去了.

很有趣的,我們都認為大公司應該比較有制度,但是就我的經驗大公司反而可以容忍因為人員離開而導致時程的延遲.

我的觀察是,政治問題是逃不了的,只能選擇要不要面對.不想面對可以逃,但是有人就有江湖.

 

所以我才會說出:

“第一線的基層人員,也應該關心團隊政治,或是說關心團隊運作,甚至說關心你的同僚."

順帶一提這邊所謂的政治並不一定是負面的.政治,管理,製程,開發方法,組織動員對我來說意義相同.

 

這邊舉一個例子:從<遊戲專案為何成功>專案的幕後談起...

即便解決問題的關鍵不盡然是我們所做的事,但卻因為團隊沒有滅團才能堅持到有果實的那一刻.

 

接著我們嘗試揣摩一下組織內的團隊像甚麼樣?是怎麼運作的?

在此之前我們解釋一些名詞

文件=文案/腳本=設定表格/程式腳本/軟體遊戲

開發者/企劃

 

幾個網路上的文章或影片描述團隊的運作看似誇張戲謔,但其實是"比想像中都來的真實".

 

  1. 工程師的日常(The Expert):https://www.youtube.com/watch?v=YUdRneClY28
  2. Scott Williamson, Expert:https://www.youtube.com/watch?v=B7MIJP90biM
  3. 阿婆問路,以及常見的工期預估盲點:https://www.projectup.net/article/view/id/13265
  4. 用這個開發坦克的影片來解釋那些開發中遊戲為什麼會變成災難:https://ndark.wordpress.com/2015/02/26/%e7%bf%bb%e8%ad%af-%e7%94%a8%e9%80%99%e5%80%8b%e9%96%8b%e7%99%bc%e5%9d%a6%e5%85%8b%e7%9a%84%e5%bd%b1%e7%89%87%e4%be%86%e8%a7%a3%e9%87%8b%e9%82%a3%e4%ba%9b%e9%81%8a%e6%88%b2%e7%82%ba%e4%bb%80/
  5. <烈火突擊隊>Pentagon Wars – Bradley Fighting Vehicle Evolution:https://www.youtube.com/watch?v=aXQ2lO3ieBA 11+driver+機槍 => scout tower (hide) + hole(week armor) +  cannon(space for ammo instead of man, big target) + swim (aluminum -> weak armor) + anti-tank missles => commander gunner driver + 6
  6. The Expert (Short Comedy Sketch):https://www.youtube.com/watch?v=BKorP55Aqvg
  7. 撞牆理論:https://www.facebook.com/permalink.php?story_fbid=805468942966587&id=100005104664045&pnref=story

 

The Expert 的分析:

  1. 老闆只關心能不能做完,對於實質遇到的困難並不在意。
  2. 會議中提出的疑慮沒有解決。
  3. 專案經理過於強調正面的對話及禮貌,避免觸霉頭。
  4. 提出需求的人不願意放下柵欄進入專業的世界。
  5. 嘴巴說願意聆聽意見,但是根本沒有聽進去。
  6. 沒有進入狀況的人,提出了不相干的意見,扯離了討論的主軸。
  7. 追加規格被認為是符合原本的規格。
  8. 提出規格的人其實也不太在意規格到底是甚麼?
  9. 公司其實並不這麼在意人力資源的使用效率。

 

即便是在大公司,只要是"專案"就是這樣混沌的狀態.在遊戲產業又異常的混沌.

 

科技產業及娛樂遊戲產業對於產品又有著根本上的差異.

簡而言之娛樂遊戲產業的核心是文化與愛,我舉個明星志願二(1998)的例子...

在團隊運作上,科技業的團隊全都是技術人,而且有著使命必達的執行者的概念.

也就是說在科技業所謂的設計及執行,兩個角色區分得相當清楚.

 

在遊戲團隊其實跟科技產業非常不同,任何一個開發者都有可能或是想要在開發的過程中,把自己的靈魂注入到產品中.而且遊戲團隊多半不是依照設計vs執行來區分團隊成員.在我遇過的遊戲團隊中,每個開發者都有可能是設計者.在每次會議的討論中都有可能貢獻自己意見.當然有另一個可能性是:自由派的開發者,都厭惡單純只是執行者的場域,而投身了娛樂遊戲產業,因為這個產業才有機會讓他們發揮自己可能是設計者的機會.如果遊戲團隊,卻依照"我講你做"的模式運作,其實就跟外包沒甚麼兩樣.這個我把它叫做內包.只是坐在你身旁的外包人員.

 

遊戲團隊大致上由企劃,美術及程式不同職能的人員組成,團隊溝通的複雜度其實是非遊戲產業所難以想像.

 

網路上有一篇關於Trivago文章,有稍微簡化地描述到這個現象.

以宴會讓員工融入的 Trivago 公司文化:https://ndarkmsnlivespace.wordpress.com/2016/05/07/%E7%BF%BB%E8%AD%AF-%E4%BB%A5%E5%AE%B4%E6%9C%83%E8%AE%93%E5%93%A1%E5%B7%A5%E8%9E%8D%E5%85%A5%E7%9A%84-trivago-%E5%85%AC%E5%8F%B8%E6%96%87%E5%8C%96/

這篇文章中這間德國公司把工程師跟業務人員分別叫做木頭腦與嘴皮腦.為了融合這兩種公司成員,他們每年都舉辦長時間的員工旅遊...

 

所以我們可以對遊戲團隊的運作做一個總結,人很複雜,管理跟溝通需求非常高,團隊內都是設計者,至少要讓團隊成員自認為自己有一定程度對設計的掌控度,團隊必須決定個體發揮創意的運作方式.也就是團隊跟成員必須針對決策模式達到一個平衡.如果能在找人的時候就找到適合團隊文化的人更好,而在此之前更重要的是自己的團隊文化到底是甚麼?

 

一個極端是菁英獨裁制,元老院的人負責決策,大多數的其他成員都是內包,這樣其實也是一種運作方式,只要找人的時候知道自己要找的人是願意接受這樣運作方式的人就好.

 

回到上中下三策.文案作家跟開發者(企劃)的差異除了工作內容之外,其實最重要的是心態.文案作家或文件作家的角色在遊戲團隊是一個困窘的存在,因為一開始就把堡壘的界線畫好了.遊戲的好壞成敗是與我無關的.等於是站在一個很安全位置的外包.如果這是我們想要去的地方,那麼與其等待遊戲團隊不知道何時會外包文字工作出來,不如採取上策反守為攻.但是當心態變化進入遊戲案,企劃開發者仍然可以或必須做文案工作,但是開發者直接貢獻了遊戲進度,所以就必須學習開發遊戲的專業,關心團隊成員,關心團隊的決策及困難.

 

 

接著我們就來聊聊企劃

 

企劃分野 -[翻譯] 企劃的種類 https://ndark.wordpress.com/2015/06/21/%e7%bf%bb%e8%ad%af-%e4%bc%81%e5%8a%83%e7%9a%84%e7%a8%ae%e9%a1%9e/

 

用資歷分:企畫助理/助理企劃/企劃/資深企劃/主企劃/創意總監

用工作內容分:關卡/場景/任務/系統/戰鬥系統/經濟系統/小額付費/平面介面設計/使用者經驗/謎題/敘事設計劇情作家/音效

 

How To Start Your Game Narrative – Design Mechanics First – Extra Credits: https://www.youtube.com/watch?v=22HoViH4vOU

Player, choices, interactions. != Story, dialogs

 

Designing game narrative: How to create a great story: http://www.develop-online.net/opinions/designing-game-narrative-how-to-create-a-great-story/0185460

“One of the basic principles in writing is to show, don’t tell. If you want to convey that a character is nimble, don’t explicitly say “Bob is nimble,” show it: “Bob dodged the falling boulder.” In games, the principle should be to do, don’t show. Don’t just show a cinematic of your character dodging a falling boulder, do it: have the player dodge the boulder himself. Now it is the player themselves who feels nimble, instead of just his avatar. This conversion of character development into personal development is the key to immersive storytelling in games."

“That’s a real story. Maybe it doesn’t sound that exciting when you put it in words, but in the player’s mind, it’s a fully developed experience with a real conflict, climax, and conclusion. It’s felt deeply by the player, because it’s something that happened directly to them.”

 

各種企劃書的比較:

紙上作業 Document Spreadsheet “Axure RP" Video

 

[註] Bilo是一個跨國的創業團隊,他們開發智慧玩具一個類似積木的玩具,協助老師及家長在幼童的數理及認知學習。

 

[例子] 技能需求/技術可行性/實質填入資料/測試/除錯修改/測試

 

各種腳本的介紹

介面編輯器 介面腳本

對話腳本 小林丸指揮官

對話編輯器 填入實作

 

走入荊棘堡壘-真正貢獻進度

我不斷強調"開發者"這個定義.沒有人規定企劃不能寫程式,沒有人規定企劃不能畫圖.所以企劃其實是個假議題,或是說是一個現況.理想是沒有企劃,都是開發者,每個開發者的貢獻,都應該像倒水一樣注入專案的完成度上.

[例子] 挖透明色

文件及規格,溝通及討論,都是很重要的前置工作,但是都沒有注入專案的完成度.完成了文件並不能夠代表我們完成了專案.以數值設定來說,訂出怪物的欄位有攻擊力,生命值,種類,屬性,大頭像,模型,甚至背景故事是規格,訂出欄位之後我們才知道表格上有多少欄位要填實,表格仍然是文件作業,真正以某種形式(腳本/資料庫)填到遊戲中,也就是今天填實了一個怪物,遊戲玩起來是不是就出現了一個怪物,填實了一百四十七隻怪物,遊戲怪物的進度百分比就到達百分之百,在遊戲中可以看到那些不同的怪物.這才代表真正貢獻到遊戲進度.

寫文件很重要,文件做為一個共同討論的定案有其契約上及心理上的重要性.

但寫文件就是個寫手,跟部落格食客沒兩樣,

真正困難的是如何落實文件,真正貢獻到專案完成度上,真正在遊戲中玩到這樣的內容.

遇到開發困難的時候,該如何調整,該如何說服團隊成員這樣改並沒有違逆或背棄先前的承諾,沒有朝三暮四.

 

走入荊棘堡壘-如何與程式溝通

[技巧] 不是每個人都關心專案是否成功(每個人都會說自己為專案盡心盡力),應該說所謂的成功其實有很多種,每個人心中的定義都不太一樣.

[技巧] 開發者都有脾氣或地雷:開發中不喜歡別人打擾/明確的規格/喜歡邊做邊改/不喜歡做文書工作/規格不減反增/回饋慢/接急件.

[技巧] 不想做VS不能做.搬石頭的例子.

[技巧] 移除VS改.錯誤訊息的例子.

[技巧] 盧(用時間換取空間)VS讓(朝三暮四).吃完再加班的例子.

[反技巧] 革命不是請客喝酒.

我觀察到在科技業跟遊戲業還有一個差別,也就是兩種產業對於專案經理(PM)的看法有異.

這個角色在不同的公司有不同的名稱:製作人/編導/專案經理/專案負責人.主要的工作是負責銜接各項職能,協調部門間的資源.確保專案準時達陣.

對遊戲業來說其實PM比較像隊長的角色,隊長必須知道所有事(甚至說在關鍵的場合中沒有任何情況被允許說:不知道),也最好必須具備程式及美術的職能.既然像是隊長,那麼處理團隊成員間的溝通問題,甚至是情緒問題,也都是隊長的工作.

[技巧] 程式通常是接最後一棒,程式也不喜歡每次都打槍.容易改的VS不容易改的 => 不容易改的 => 改規格

[例子] 有時候A改成B比起全部打掉重新做B還要難,打比方說蓋五樓公寓加電梯.

[例子] 一個情境是PM開會的時候希望決定下一個周要做甚麼,所以他問了底下的工程師,你接下來要做甚麼?工程師卻很納悶,你是PM應該是公司告訴我接下來要做甚麼怎麼會是反過來問我.PM只好說那下禮拜能不能在App新加一個第三方套件?工程師說這個第三方套件我沒接過,我無法評估要做多久,萬一這個套件有問題,接不起來,那怎麼辦?

[例子] PM看了目前的畫面說為什麼這兩個介面的是否按鈕裡面的字型大小不一樣大?因為他們是依序建立的,建立第一個介面的時候並不知道有後面有多少這樣的介面的存在,所以並不會想到要設定幾種標準的尺寸(大中小),或是設定不同尺寸該用程式的方式讀表設定?還是在拉介面的時候開發者拿著表輸入?也不知道該設計幾種?第二個介面建立的時候也沒有人去指定到底第二組介面在做的時候的大小.當兩個介面都做完,這時候就會發生砍誰都傷感情的困境.接水管的例子.

[例子] (星露谷物語) 遊戲中有商店老闆,玩家只有走到商店,點擊在櫃檯後面的商店老闆才會觸發購物面板(特色A).但是遊戲中有另一個特色是商店老闆禮拜三會放假跑掉(特色B).如果有一個重要主線任務(特色C)是禮拜一接到,只能在禮拜三去找商店老闆購買一個道具,禮拜四任務就過期,接任務的角色也跑掉了(不能重複接重要任務).這樣就會導致遊戲無法繼續進行下去.ABC可能是依序設計的所以沒有考慮到會同時影響到.如果要依照瀑布式先設計仔細再進行,那麼可能會需要半年把所有文件生出來,這半年沒有任何實質進度,可能不是一般台灣公司或團隊可以承受的事情.

[例子] 周一派了郵件訊息工作,工程師說要做四天,依照此回報管理層,週五說做完了,檢核的時候才發現做成聊天室功能,其實郵件還要有夾帶附件功能.所以原本答應的進度四天完成郵件系統就延遲了.接著該怎麼辦?

[例子] 有時候沒規格,或是沒有人有時間出規格,所以這時候該罷工?這時對我來說站在旁邊口述歷史,也算是一種規格.

[例子] 美術做了全螢幕的背景,在背景上做了邊框.當畫到遊戲中的時候感覺有邊框就沒有全螢幕的感覺.所以這時候有兩個做法:(A)美術重新出一張沒有邊框的圖.(B)程式把遊戲中畫布的尺寸稍微放大,超出螢幕的範圍.到此問題其實不大.但是若是選擇(B)的一個月後,新的美術重新換了一張背景圖,但是這次沒有做邊框圖面的細節直接延伸到邊緣,直接換圖.因為整個進度已經做到其他地方了,就不會有人回頭過來看這個細節.此時就會發生這張圖因為原本被程式放大,所以新的圖的邊緣細節其實是超過螢幕外面的現象,這時候又會面臨(A)(B)的問題.到底要請美術再出一張圖?還是程式要改程式碼?重新出一個版本?

 

[翻譯] 敏捷方法如何毀掉你的專案:https://ndark.wordpress.com/2015/08/06/%e7%bf%bb%e8%ad%af-%e6%95%8f%e6%8d%b7%e6%96%b9%e6%b3%95%e5%a6%82%e4%bd%95%e6%af%80%e6%8e%89%e4%bd%a0%e7%9a%84%e5%b0%88%e6%a1%88/

“團隊是依賴不同的專家提供的建議。但當一個跨領域的團隊不知道怎麼在不同專業間溝通時問題就會浮現...如果團隊中沒有人願意出來協調,缺乏專業的主管將無法將專案導回正途"

“真正的管理者是一個精密手表的製作者。他們會協調上百個工作,知道每個工作的功能,工程師如何有效率工作。他們會試圖了解每個製程的部分,把無效率的部分移出。問問題,找問題,找方法..."

 

另一種PM通常是來自於科技產業的習慣,在遊戲產業也會發生這件事,就是當代理商派了一個人來督軍的時候,這個人也會掛PM的職銜.美其名這個人的功用是負責關照這個遊戲能順利發行.就我觀察,說難聽點,這個人的功能就是負責點餐.點餐=我說你做=用嘴巴寫程式.

 

[技巧] 開發者都不喜歡碰到有點餐心態的人,如何避免讓人有點餐的感覺?成為開發者掃除障礙.讓.盧.

 

結語

 

原來的問題加上人的問題就會變成新的問題.這是為什麼在上中下三策之間仔細想想,講老實話,其實上策才是正解.

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s