2019,聊一聊國產遊戲研發圈裡目前主要存在的幾個問題吧
不希望這篇東西變成一個發洩負面情緒的導火索,所以還是先講一些其實和本文無關的內容吧:
手遊賺錢不是廠商不做單機端遊的原因。這是兩個不同的產業。就算軟體300%的利潤,硬體5%的利潤,也還是有人會去做硬體。
手遊不是一本萬利,成都當年號稱有上千家遊戲公司,現在存活的估計不到100家。
手遊的成本已經不再低廉,目前大型MMO手遊的開發成本已經有奔著兩億去的。
國產手遊的玩家並不是喂屎都吃。13年的時候手遊一個使用者幾毛錢,19年的時候手遊一個使用者幾十塊上百塊。這背後的邏輯其實就是手機使用者正在學著分辨遊戲,並不像以前看到一個廣告就點進去玩。
手遊並不是沒有技術含量,手遊也有上得了檯面能到GDC宣講的技術。
閒話扯完,開始本文的主題吧。
簡單的來說,我想聊一聊在2019這個時間點,國產遊戲研發圈裡主要存在的幾個問題,或者說,我主要期望能夠變得更好的地方。
一、成本控制
成本控制主要體現在三個方面,一是決策目標是否明確,二是專案管理,三是工具鏈。前兩個是雷區,展開完全可以另寫一篇萬字長文,我就不多談了。
我們直接假設有一個領導決策英明,專案管理井井有條的團隊。然而這樣的團隊,在成本控制能力上仍然會遠遠落後於國外頂尖團隊,其原因主要就在於工具鏈。
工具鏈在遊戲開發領域主要體現在編輯器和程式化資源處理/生成。
編輯器的典型例子是War3 Editor,設計師可以不經過程式,自己做出一個Dota。
程式化資源處理/生成的典型例子如基於Houdini的大地形解決方案。在前期環境搭建完成之後,設計師只需要勾勒出簡單的地形要素,標記好道路和建築區域,就可以自動生成包含植被等各種環境細節的高精度場景。
毫不誇張的說,工具鏈的差距會導致有時候國外團隊花1000w能完成的工作,國內需要花掉1億。當然,一線團隊並不會說真的就把省下來的錢削減掉,而是可以把這些省下來錢花到細節的雕琢或是更多內容的鋪量上。所以有時候表面上看到的是遊戲品質有差距,實際上根源是成本控制能力有差距。
那麼為什麼國內的工具鏈如此薄弱呢。
首當其衝的原因就是國內遊戲開發團隊穩定性太差。國內遊戲開發人員的平均跳槽時間小於20個月,而工具鏈的開發迭代需要在長期穩定的團隊裡才能發揮作用。
第二是國內太過缺少能夠以資料驅動的思維來設計編輯器的遊戲設計師。
第三則要現實一點,工具/編輯器開發的職位薪水往往都不夠高。不要笑我把遊戲開發這麼“夢想”的事情說得這麼現實,國產遊戲這幾年渲染水平以肉眼可見的速度飛速提高,說到底還是圖形工程師/他的錢給得足夠多。
二、世界構建(World Building)
世界構建這個事情往廣了說可以分為兩個方面,一個是設計,一個是實現。
設計層面的敷衍大家都比較容易理解,對於世界構建目前很多團隊大抵的流程不過是文案寫設定,寫故事,提需求,美術根據需求實現。還有不少團隊是美術已經做了一堆東西,專案已經做了一版Demo,然後文案組才到位,然後根據已有的資源來寫一版故事包圓。
志同道合的遊戲設計師和美術坐在一起一同構思一同迭代出一個世界的景象恐怕短時間內還是很難看到。
然後是實現方面,這方面的源頭其實要追溯到上一條成本控制能力。
因為成本控制能力不足,所以所有的研發經費就必須都花在刀口上。長期積累下來的結果就是國內極少團隊有細節雕琢的經驗。比如複雜行為的AI,可互動動作,音效與氛圍的烘托,非人形生物動作,這幾個領域可以說都是重災區。
像頑皮狗曾經因為嫌物理效果不可控不夠美觀,以動畫師手動製作的方式實現了多組不同的物理動畫。這些動畫可以根據玩家的觸發區域和方向進行融合或是倒播。這種騷操作與其說國內團隊不會,倒不如說是在基本框架的成本控制能力得到提升之前,國內團隊都不會有機會去嘗試。
這些種種瑣碎的開發經驗累積下來,形成的結果就是國內目前幾乎沒有團隊有構建大型高模擬世界的能力。
三、跨職能配合
遊戲開發其實是一個需要高度協同合作的工程。這意味著如果任何一方不能理解另一方的工作,開發效率都會被極大的拖慢。
在程式的角度,如果程式不能理解遊戲概念,遊戲術語,那麼和策劃的溝通交流時間就會成倍增加。
在策劃的角度,策劃組不用每一個人都懂程式,但如果整個策劃組連一個懂程式的都沒有,那就意味著策劃內部通過的方案被程式打回重寫的概率非常之高。如果策劃不能理解網路通訊的概念,不能理解資料的數量級,不能理解3D渲染和3D物理的基本常識,那麼策劃自己的構思和最終實現出來的效果之間恐怕就很難對應的上。如果策劃不能理解3D美術資源製作的基本流程和輸出結果,那麼隨意提出的需求很可能就會導致遊戲的包體和成本失控。
在美術的角度,如果美術無法理解PBR工作流,無法理解固有色其實本質上是反射率而不是顏色,那最終出來的效果很可能就會與預期相差甚遠。如果美術無法理解某些美術資源配置的程式意義,那資源規範的推進也就會困難重重。
此外還有某些專業性較強的工具,或是某些高效的工作流,本身就是以團隊記憶體在跨職能人員為前提的。而這方面可以說國內仍然還有非常大的人員缺口。
四、策劃的篩選標準
其實所有的問題都是有解決的可能性的,但前提是能篩選出有能力解決問題的人。
對於程式來說,知識的深度和廣度,解決過的問題,在硬體層面體現出的效能指標,都是可以量化的。程式圈子裡當然也存在靠口才和交際上位的人,但整體而言,一個程式的段位還是容易判斷的。某個老闆再寵一個小程式,也不敢把一個大型專案主程的位置給一個小程式。
而美術可能還要更簡單一些,一個人的作品擺出來,在專業的人眼裡就有一個標尺在那裡。
但策劃就不一樣了,首先遊戲設計是一個很務虛的東西,也很難說得清對錯。但國內遊戲的情況糟糕就在於連互動藝術的知識體系都沒有,以至於策劃連可靠的基本功篩選尺度都很難拿出來。
舉個更現實一點的例子,對於一名程式來說,僅僅依靠技術部落格和GayHub就已經可以大致判斷出段位。在知乎我所關注的程式裡面,有一位目前仍是學生,就已經收到了多家頂尖遊戲公司的邀約,甚至受到了Milo Yip這樣級別的人的關注。如果他想去國內任何一個遊戲開發團隊,基本上都可以暢通無阻。而對於策劃來說這基本就是天方夜譚了。
這個問題的影響,往淺了說是很難分辨出優秀的策劃。往深了說,如果一個行業的專案成功率極低,而除了成功專案之外又很難有確實的、能分出高下的評判標準,那麼會不會導致一些原本很優秀、喜歡遊戲設計的人,在選擇行業的時候就卻步了呢?
似乎也沒用什麼好再總結的了,就這樣吧。
作者:江流
專欄地址:https://zhuanlan.zhihu.com/p/67011041
相關文章
- 面試官:聊一聊索引吧面試索引
- 聊一聊MySQL索引失效的問題MySql索引
- 聊一聊黑客是如何思考問題的黑客
- 聊一聊Integer的快取機制問題快取
- 日誌?聊一聊slf4j吧
- 聊一聊搭建一個網站到底有幾步?網站
- 聊一聊 GDB 除錯程式時的幾個實用命令除錯
- 聊一聊我在 B 站自學 Java 的經歷吧Java
- Hi,我們再來聊一聊Java的單例吧Java單例
- 聊一聊Redis熱點key儲存問題Redis
- 來聊一道前端面試題吧前端面試題
- 聊一聊前端業務開發前端
- 聊一聊在阿里做了 8 年研發後,我對打造大型工程研發團隊的再思考阿里
- 聊一聊 React 中更新 ui 檢視的幾種方式ReactUI
- 聊一聊Oracle的Tablespace(一)Oracle
- 聊一聊 JVM 的 GCJVMGC
- 聊一聊 RestTemplateREST
- 聊一聊 cookieCookie
- 聊一聊我對測試開發的看法
- 簡單聊一聊 Android App Bundle 的話題AndroidAPP
- 單例模式(下)---聊一聊單例模式的幾種寫法單例模式
- 單例模式(下) - 聊一聊單例模式的幾種寫法單例模式
- 單例模式(下) – 聊一聊單例模式的幾種寫法單例模式
- 聊一聊遊戲的壓測遊戲
- 聊一聊 Javascript 中的 ASTJavaScriptAST
- 聊一聊 TLS/SSLTLS
- [貝聊科技]一個頁面阻塞問題的排查過程
- 聊一個複用元件中使用debounce時遇到的問題元件
- 聊一聊圖資料庫的發展現狀資料庫
- 聊一聊目前國內IDC主機管理系統現狀和使用感受
- 聊一聊幾種常用web圖片格式:gif、jpg、png、webpWeb
- 面試官:我們來聊一聊Redis吧,你瞭解多少就答多少面試Redis
- 聊一聊Java的列舉enumJava
- 聊一聊Redis的離線分析Redis
- 聊一聊MySQL的字符集MySql
- 聊一聊MySQL的儲存引擎MySql儲存引擎
- 簡單聊一聊Vuex的原理Vue
- 聊一聊Javascript中的Promise物件JavaScriptPromise物件