總結開發者在合作過程中的典型交流方式

openkk 12年前發布 | 7K 次閱讀 程序員

        英文原文:Cliff Bleszinski's Game Developer Flashcards

        作者:Cliff Bleszinski

        到今年夏天,我從事職業游戲設計就到第 20 個年頭了。我曾領導團隊設計平臺游戲、FPS、單機游戲、多人游戲等等。我曾和一些最令人嘆服的程序師、美術人員、動畫師、寫手和制作人共事。這 20 年以來,我注意到創意人員經常使用的交流方法。

        我知道雖然開發人都非常高明,但有時候他們并不敢肯定與同行相比自己能有多聰明。我曾看到開發者在留言板上對百萬美元的游戲大作、獨立游戲寵兒 等過度分析、吹毛求疵。我們總想證明自己比其他人有先見之明,或者引用一個例子,說明那個創意已經被嘗試了、能成功、會失敗或行不通等。

        開發者們為了“贏得”得談話,經常會使用一些討論、爭論和辨論方式。本文要介紹的就是這些常用手段。

        以下說法和綽號沒有惡意地針對誰;事實上,有幾個方法確實是因為有理有據才被使用的。例如,樣式對比可以避免制作出派生產品;邊界案例有時候可以抹殺可靠的想法。以下就是我所謂的交流“技巧”。

        “樣式對比”

        這是指開發人為了否絕一個創意,立刻在他的頭腦中檢索他的游戲/流行文化庫,然后找出最接近的想法作為比較對象(常常是糟糕的或失敗的案例)。

        以《阿凡達》為例,“你想制作一部關于藍皮膚的人在叢林中對抗壞人類的軍隊和機器?什么,藍精靈叢林大戰外星人?”不恰當地類比,《戰爭機器》 可以看作是 80 年代的低級恐怖電影《C.H.U.D》(游戲邦注:在電影《C.H.U.D》中有一種生活在城市底下的基因突變人,以食人肉為生,而《戰爭機器》中也存在 類似的怪物)。

        “邊界阻塞”

        這是指用一個邊界情況來否絕可能很了不起的想法。例如,舉出邊界情況的人可以否定在《天際》中創造一個大世界的想法,因為擔心玩家要走回原來的地方,且步行太老套。清楚明確的修改方法如“快速旅行”的可以輕易地解決這個大世界問題。

        邊界阻塞有變體:

        “交際人”:這是指因為某個想法在邊界情況或特定的合作模式中不成立就否決它——這是邊界阻塞的變體。“《英雄本色》的慢動作怎么可能在合作模式中起作用?不可能!”

        “完美主義者”:類似于邊界阻塞。這是指開發者發現在某種情況下,一個很不錯的設定可能看起來并不完美。比如,格斗動作有時候會導致角色發生微小的變化。

        “從來沒見過做得好的”

        這句話的意思也就是“我以前從來沒見過這種想法行得通或做得好的。所以,我們不應該這么做。”這是一種相當不言自明的論斷,事實上,這也可能是為什么應該執行某個想法的理由。按這種邏輯,所有創意都只能是雷同的。

        比如,在《戰爭機器》中設定了一種生活在地下的 Locust 人,這個設定行得通的原因有很多,但我們仍然對它持保留意見。畢竟,這個設定使該游戲從其他帶有常規外星人的游戲中脫穎而出。

        “故意唱反調的人”

        為了保全顏面,大多數開發人經常故意唱反調,甚至在他們自己也相信這個想法時候。律師經常使用這一招。

        “不過是X+Y罷了”

        這是指開發者懷著酸葡萄心理貶低其他成功的作品,因為他可以輕易地看出其中的原理。事實上,正是因為游戲原理非常簡單明顯,才使游戲如此成功。

        例如,《Words with Friends》:“不過是異步拼字游戲罷了。”是的,正是如此,所以它成功了。

        “以后再說”

        當開發者聽到一個想法——無論好壞,就說這個想法很適合之后的版本或續作。這句話的真實含義是,“我認為這個想法不值一試,所以我們放棄吧,我說以后再說是為了讓你不難受。”

總結開發者在合作過程中的典型交流方式

tower of babe (from gamasutra)

        “通天塔”

        這是當開發者在一個本來很簡單的設定上堆砌太多額外的小東西時,但這些小東西最終危及整個設定。這座“通天塔”是被自己的重量壓跨的。

        “雪崩效應”

        之所以用這個方法否絕一個想法,是因為這個想法需要許多其他部門(游戲邦注:如動畫、UI 或美術)做更多工作。通常,有趣或值得嘗試的特點都會牽涉到更多部門,因為涉及多個學科的知識。

        “過度分析”

        這個常用的詞是指過分考慮某個想法,以致于一事無成。

        “試什么試?”

        換句話說,“我們怎么跟別人比?”因為在某個方面面臨激烈的競爭,開發者就這么問,以免嘗試。

        “他們有N個開發者啊!”

        當開發者說到某個競爭團隊的規模有多大時就會這么說,說完這句話以后緊接的就是上面那句。為了高效地工作,Epic 公司總是讓最好的人從事同一個任務,用最好的工具。

        “保守主義者”

        “但是我們一般都是這么做的啊!”在娛樂行業,特別是與技術有關的行業,為了生存,創意和反思是非常必要的。自滿和墨守成規必然導致失敗。

        在某個常規行業工作 20 年可能是個優勢,但在技術行業,這可能會成為你的絆腳石。作為開發者,越要保持眼界開闊,要活到老學到老。

        “但我們是 XXX(“XXX”指工作室名稱)

        當工作室準備將自己的名譽押在某個項目的成功上時,就會發出這樣的戰斗口號,還自認為很強大。當工作室的人這么說的時候,你就知道這個工作室離內亂的日子不遠了,因為更年輕的新員工滿懷夢想,總是想取代老員工、創造新的輝煌。

        “我們以前就試過了”

        為了否定舊想法的替代方案(可能行得通),就提出以前嘗試舊想法失敗的經歷。

        “太先進了”

        你的想法太棒了!事實上,這個想法太前衛太創新了。所以,我們不應該嘗試,因為聽起來挺費功夫的。

        “按我們這行的話說……”

        這是指,為了在爭論中占上風,開發人拋出只有他自己專業的人才懂的術語,使不同專業的其他開發人不知所云。例如,程序員用代碼的原理跟美術人員討論,設計師用設計行話向動畫師解釋。

        “部落首領”

        當開發人固執地信仰自己的專業(美術、編程、設計等),而排斥工作室里其他專業的人的見解。

        “不在范圍之內”

        “這個想法很好,但不在我們的項目范圍之內。”很不幸,有時候,最好的想法不會在原本的計劃之內。

        “測試把戲”

        開發人為了否絕某個新設定、新武器,就強烈建議“和諧”它,他的方法是在測試時變更它,這樣游戲就按著他的思路設計了。有時候,人們為自己的想法付出了很多努力,結果卻被別人破壞了,遇上這種情況,看開了就好。

        “學舌”

        這是指一類人,他們聽到你的想法,反而像從來沒聽過似的,用自己的話把你的想法當成自己的說出來,還忘記自己是從哪聽到這個想法。這從根本上說沒什么大不了的,只要這個創意行得通就行了。

        “長篇大論”

        這類人用三頁長的郵件回應設計建議或討論。

        每次都是這樣,最終,你得為這個人設一個專門的文件夾。

總結開發者在合作過程中的典型交流方式

e-douche (from gamasutra)

        “郵件盲”

        這類人在郵件方面似乎總像個徹頭徹尾的傻冒,即使他們并不是故意的。

        “哥拉斯”

        因為主觀地認定一個想法不好,這類人莫名其妙地就叫停所有進程,提出自己全新的想法,最終所有人都不得不重新開始。

        “懷疑論者”

        這類人沒有任何明確的理由就拒絕一個想法,他們的說法是“對此,我不知道……”,卻往往很管用。

總結開發者在合作過程中的典型交流方式

the prophet (from gamasutra)

        “先知”

        這類人對一個想法懷有一時的沖動熱情,但從未站在設計或其他學科的角度考慮它。這類人單純地希望所有人都相信這個想法會成功,而不是根據它做出原型。這往往是年輕的、沒經驗的設計師的舉動。

        “亞哈船長”(游戲邦注:這是小說《白鯨》中的人物,固執地想找白鯨復仇。)

        這類人拒絕承認某個想法行不通,同時不斷地嘗試,不惜浪費珍貴的代碼和美術資源,妄想有一天,這個想法會成功。

        “數據控”

        這類人出現的情況是:“這個表格中的數據客觀公正地表明,你的想法永遠不會成功,你會使很多人不愉快,這個方向我們不能走。”

        “精神期望”

        這是指一個程序師拒絕理解被提出來的設想,直到這個設想以程序師自己想的方式被要求執行時。

        “無視”

        這類開發人有意(或無意)地忽略可能會成功的想法。

        “事不關己”

        這類設計師口口聲聲說想要創意,聽了別人的想法后又默默地忽略任何不是他自己想出來的東西。

總結開發者在合作過程中的典型交流方式

the gardener (from gamasutra)

        “園丁”

        園丁早早地種下了想法的種子,然后多次在會議上提起,甚至與他人閑聊時也不忘說上一句。最后,這個想法開始在其他人心里生根發芽,直到它成為游戲中的一部分,都沒有人記得這個想法最初是從哪冒出來的。這確實是個實用的技巧。

        “漏洞仔”

        當進程中出現一個設定,設計師不考慮這個設定的目的或作用,只顧著指出明顯的錯誤,而這些錯誤顯然是最終能解決的。

總結開發者在合作過程中的典型交流方式

multi boss (from gamaustra)

        “多個頭領”

        當一個人沒有明確的頂頭上司,不知道該聽誰的發號施令時,他往往會聽從多個人的指揮。設計總監、執行制作人和董事可能各有自己的觀點,讓沒有明確上司的員工感到困惑不堪。

        “打包票”

        這個詞是指發言人向媒體承諾某個設定,讓團隊不得不按他放出的話來做。

        “隨大流”

        創意人員看到最近游戲的游戲中有什么,他就采納什么,心想這樣就可以做出好游戲,也省了想法子創新。

        總而言之,以上就是我這些年見識過的開發人的個性的交流“技術”。多謝了在 Epic、ChAIR 和 People Can Fly 的同行們為我提供的材料。我希望有遠見的開發人可以意識到這些問題,并相應地改正。我也希望此文能讓博得創意人員的會心一笑。

來自: gamerboom.com

 本文由用戶 openkk 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!