曾經(jīng)參與的項(xiàng)目上線了，特別看了玩家的各方評(píng)價(jià)，雖然對(duì)于個(gè)人關(guān)注的內(nèi)容上少有評(píng)價(jià)但根據(jù)游戲截圖也能評(píng)斷些許。對(duì)于當(dāng)時(shí)項(xiàng)目的美術(shù)需求工作流仍不斷反思，當(dāng)前游戲研發(fā)的作業(yè)流程分工細(xì)膩而繁復(fù)，然而這樣過于細(xì)膩的流水線與KPI綁定時(shí)則產(chǎn)出了異端卻人之常情的工作心態(tài)。

現(xiàn)代工序的專業(yè)分工將以往眾多工項(xiàng)由單一雇員憑借經(jīng)驗(yàn)累積所能完成的過程，拆分為眾多工項(xiàng)分別由眾多雇員單一專職完成，以此大幅降低多任務(wù)項(xiàng)經(jīng)驗(yàn)門坎且專精于單一工項(xiàng)的技術(shù)累積。工作流本身的理念沒有問題，問題在于如何實(shí)踐工作流，中間產(chǎn)生了多樣態(tài)的可能性，也會(huì)憑借著各團(tuán)隊(duì)不同的條件限制而有著不盡相同的匹配模式。在管理學(xué)中有著系統(tǒng)思考的課程，專門藉以工作的狀態(tài)以問題核心本身提出適合的解決方式，管理學(xué)所衍生出來的學(xué)門眾多然而實(shí)踐上仍相當(dāng)考驗(yàn)性格與觀念。

總歸而言，我認(rèn)為當(dāng)時(shí)所運(yùn)作的美術(shù)需求工作流程擁有許多阻力，導(dǎo)致‘一群跑車跑起來像蒸汽火車一樣’，舉個(gè)例子也是曾經(jīng)參與某個(gè)項(xiàng)目發(fā)生的狀態(tài)，實(shí)際的內(nèi)容就是《游戲研發(fā)的設(shè)計(jì)規(guī)范03》這篇文章。這篇文章的內(nèi)容是沒有被采納的方案，乃因于當(dāng)時(shí)的部分人員認(rèn)為工作量巨大以及包體巨大。當(dāng)時(shí)就知道這兩問題都不存在的，一是結(jié)果論來說工作量是極度縮減，頂多起步需要多些累積，或者對(duì)方的擔(dān)憂是工作被取代了，而實(shí)際上為了滿足多樣性仍然有適量且技術(shù)含量的工作需要推進(jìn)；二是當(dāng)時(shí)所運(yùn)用U3D而言這樣的制作流程并不會(huì)增其包體大小甚至大幅縮減，何況當(dāng)時(shí)為2.5D游戲模式，以制作流程來說總美術(shù)資源包體可以降至一半以上都綽綽有余。最終無法推行的原因自然而然是前述所提及的‘異端卻人之常情的工作心態(tài)’，于是我只能讓步了，導(dǎo)致后來工作進(jìn)度推展一直受限于資源匱乏而迭代緩慢，每每想起這些過往都只能閉目思索曾經(jīng)學(xué)習(xí)項(xiàng)目管理課程的彭湃然后輕輕嘆息。

暴走的巫師：游戲研發(fā)的設(shè)計(jì)規(guī)范03

場景需求規(guī)范

通常項(xiàng)目中的策劃提出場景需求是具有規(guī)范的，然而部分中大型廠商會(huì)額外設(shè)置美術(shù)中心的部門統(tǒng)一著手多項(xiàng)目的資源需求時(shí)，我認(rèn)為美術(shù)需求規(guī)范的標(biāo)準(zhǔn)格式理當(dāng)由美術(shù)中心發(fā)起，乃因于個(gè)別項(xiàng)目的美術(shù)需求不盡相同但對(duì)口于美術(shù)團(tuán)隊(duì)分工卻是一致的，比如原畫、模型、UI或特效等等。由個(gè)別游戲研發(fā)團(tuán)隊(duì)各自發(fā)起，糟糕的狀況是有多少個(gè)策劃就有多少種需求規(guī)范；正常的狀況是有多少項(xiàng)目就有多少種需求規(guī)范，當(dāng)然針對(duì)不同游戲項(xiàng)目的特殊需求也需要具有一定的開放性，但起始的需求標(biāo)記理當(dāng)是統(tǒng)一規(guī)范的，否則對(duì)于美術(shù)團(tuán)隊(duì)都具有一定程度的理解成本，導(dǎo)致好似專業(yè)分工了，個(gè)別工項(xiàng)的進(jìn)度也有顯著的效率，但時(shí)間通通被溝通成本稀釋了，次數(shù)一多就會(huì)發(fā)現(xiàn)原先個(gè)別工項(xiàng)的高效進(jìn)度也漸漸失效，而后‘螺絲釘’言論就會(huì)灑滿了全項(xiàng)目組，這時(shí)候最糟糕的形式大致就是開始打雞血吧，因?yàn)橹螛?biāo)不治本更導(dǎo)致人心渙散。

對(duì)于小團(tuán)隊(duì)而言，好處就是溝通成本并不算高，雖然前述上線的項(xiàng)目也是小團(tuán)隊(duì)，但糟糕的工作流仍然發(fā)生了，初始問題也正是流程規(guī)范乃自于綁定KPI引發(fā)的劣化狀態(tài)，實(shí)際上研發(fā)的工作繁多也并非每種類型的工作出現(xiàn)的延遲或偏差就會(huì)導(dǎo)致研發(fā)失當(dāng)，依然可以倚靠其他優(yōu)勢(shì)彌補(bǔ)，工作中失誤很正常的，踩坑后學(xué)習(xí)并成長并匯整經(jīng)驗(yàn)，可能比起不曾踩坑來得更可貴。當(dāng)然也有聽過相當(dāng)規(guī)范的工序，多發(fā)生在運(yùn)營已久的項(xiàng)目以及目前的項(xiàng)目（富強(qiáng)、民主、文明、和諧、自由、平等、公正、法治、愛國、敬業(yè)、誠信、友善）。

參考與類型組構(gòu)

以下內(nèi)容是早上制作的，藉此論證《游戲研發(fā)的設(shè)計(jì)規(guī)范03》中所提及的部分內(nèi)容，先引用偶像的名言做為開場‘巨大的建筑，總是由一木一石疊起來的，我們何妨做做這一木一石呢？我時(shí)常做些零碎事，就是為此。’

魔鬼橋，引用自百度圖片

想制作一個(gè)金拱門式的場景需求，于是乎尋找了金拱門的參考圖片，曾經(jīng)在歐洲拱結(jié)構(gòu)的橋梁被稱之為‘魔鬼橋’，因?yàn)楫?dāng)時(shí)的人們不知道拱結(jié)構(gòu)的力學(xué)原理而懷疑這是魔鬼的力量，拱結(jié)構(gòu)在部分古文明中都有類似的紀(jì)載，當(dāng)時(shí)的建筑技術(shù)多半為垢工，乃自于拱結(jié)構(gòu)的運(yùn)用改變了承重墻的限制，建筑的出發(fā)點(diǎn)終究是優(yōu)先于滿足功能的，當(dāng)然有部分老百姓不明所以，以為建筑設(shè)計(jì)就只是美美的。然而悲慘如我，尋找的參考圖都是當(dāng)代混凝土的建筑因應(yīng)造型本身而制造，也或許是百度圖片實(shí)在不給力。

根據(jù)偶像的名言，想利用這些參考圖制造出場景白模進(jìn)去走走，因此將所尋找到的參考圖片解構(gòu)為可用的一木一石，我們何妨做做這一木一石呢？所以零碎事通常都是我來做，我就根據(jù)參考圖中的拱結(jié)構(gòu)大致區(qū)分為幾個(gè)可用的對(duì)象，為了滿足這些對(duì)象可以通用，所以改變了些尺寸比例，當(dāng)中自然可以發(fā)現(xiàn)伊東的多摩藝術(shù)大學(xué)圖書館的結(jié)構(gòu)方式較為繁復(fù)，并不適用于此次的內(nèi)容，因此有了較多的簡化。

叁考圖與場景物件

運(yùn)用參考圖所分析出的類型進(jìn)行簡單的排列組構(gòu)，這里可以根據(jù)不同游戲類型的需求可以有進(jìn)一步的規(guī)范以滿足玩法上的規(guī)則限制，這里就不多討論。當(dāng)排列組構(gòu)完成可以導(dǎo)入引擎中往前走走，或者一開始就將各對(duì)象導(dǎo)入引擎中搭建場景，理論上這才是較為嚴(yán)謹(jǐn)?shù)淖鞣āＴ诔跏级x尺寸比例時(shí)便應(yīng)該相當(dāng)規(guī)范，才足以保證后續(xù)各類型對(duì)象量產(chǎn)時(shí)都通用，而制定規(guī)范通常各類型游戲即使是換皮游戲都應(yīng)該有套自身量身訂做的基準(zhǔn)表，畢竟研發(fā)條件及水平其實(shí)都有不小的差異，這些初始內(nèi)容也沒打算詳加說明。

叁考圖到白模規(guī)劃

引擎中體驗(yàn)與優(yōu)化

雖然前文強(qiáng)調(diào)著制作規(guī)范的重要性及工作流程中的影響，但是實(shí)際研發(fā)過程中也很有可能是不斷迭代更新的過程，自然有時(shí)候會(huì)因?yàn)槌跏荚O(shè)計(jì)的限制而窒礙難行，這也是每每設(shè)計(jì)過程考慮后續(xù)發(fā)展及擴(kuò)展性對(duì)于經(jīng)驗(yàn)與技術(shù)積累的重要性。因此快速體驗(yàn)并迭代可以有效避免隱性的失誤，這時(shí)候搭建模型走走便是有效的方式之一，如果可以讓搭建的流程精簡而高效時(shí)，也許可以多少減少《彩虹六號(hào)：圍攻》中謎之裂縫的產(chǎn)生，將場景對(duì)象類型化的優(yōu)勢(shì)在于快速捕捉部分誤差的成因。

引擎中運(yùn)行走走

引擎中運(yùn)行走走

UE4在不同軟件中轉(zhuǎn)換上提供了相當(dāng)良好的插件，以減少了轉(zhuǎn)檔中可能遇到的問題，實(shí)際上良好的研發(fā)流程是所有雇員在相同工項(xiàng)中所運(yùn)用的軟件及版本皆為相同是較為良善的方式，否則工作流也可能產(chǎn)生轉(zhuǎn)檔或操作過程許多難以避免的失誤，這問題看似邊緣實(shí)則影響巨大，如果將版權(quán)議題納入將相當(dāng)能體現(xiàn)出軟件與操作平臺(tái)一致性的重要性。

因此在引擎中運(yùn)行走走，看看一木一石怎么迭起來的，藉此可以論證草稿上的假說，修正理解并優(yōu)化規(guī)范內(nèi)容，隨著研發(fā)過程與規(guī)則的日漸明確也會(huì)有諸多調(diào)整，但理當(dāng)都能保有定質(zhì)的產(chǎn)出。

引擎中運(yùn)行走走

結(jié)論

當(dāng)代工作中的專業(yè)分工本身是整體社會(huì)飛速進(jìn)步的要素之一，但是這是對(duì)于客體而言如此，也就是工作容器本身。對(duì)于雇員而言，專業(yè)分工的目的是服務(wù)于工作，而非個(gè)人成長，因此往往會(huì)產(chǎn)生畫地自限的思維，這是對(duì)自我最大的鄙視，甚至產(chǎn)生專業(yè)鄙視鏈，這都是相當(dāng)糟糕的結(jié)果，更可怕的是專業(yè)分工的思維是至上而下的推行。

前文所提及的項(xiàng)目的狀態(tài)是預(yù)研期時(shí)研發(fā)團(tuán)隊(duì)與美術(shù)是分開作業(yè)的，導(dǎo)致當(dāng)場景需求推導(dǎo)出的制作規(guī)范在初期等于是閑置狀態(tài)，理論上需求與制作是密不可分的，否則都可能有其中一方完全返工。因此在研發(fā)初期對(duì)于參考乃自類型組構(gòu)中都應(yīng)該是迅速的團(tuán)隊(duì)參與后迭代，好讓溝通成本降低，否則一旦蒸氣火車開始奔跑了，很多時(shí)候已經(jīng)承受不起太大幅度的改善了。

來源：游資網(wǎng)

新浪聲明：新浪網(wǎng)登載此文出于傳遞更多信息之目的，并不意味著贊同其觀點(diǎn)或證實(shí)其描述。