Unity3D遊戲開發之路：一月工作總結，unity3d遊戲開發

Unity3D遊戲開發之路：一月工作總結，unity3d遊戲開發

不知不覺已經在公司上班一個月了，在這一個月裡每一天發生的事情是我平凡而普通的生活。作為一名有節操的程式員，當我大學的同學開始稱我為程式員的時候，我知道我即將在這條路上踏下一個屬於開始的足跡。和我大學的同學相比，可能我會顯得幸運而孤獨吧！我不用像他們一樣到各種工廠裡採樣、監測，可是與此同時我會因為離大家越來越遠而感到孤獨。每天下班做公交車回到住處，簡單地料理著我一個人的生活，不緊不慢卻永遠是一個人在摸黑趕路，這是我自己選擇的路，我從來不曾後悔，即使在這段時間和美術各種鬧彆扭，我相信這些都會是暫時的，以後總會變得越來越好。

第一份工作沒有想象中的高大上，這是一個融合了3D漫遊、Web和電子商務的綜合項目，可我想說我在努力地做好這件事情。當互連網+的概念被人們所熟知以後，傳統行業和互連網的結合讓人們對未來的生活充滿了遐想，因為在這個過程中不斷湧現出想要迫切進入互連網+時代的傳統行業。可是當傳統行業試圖進入互連網行業的時候，我不知道傳統行業經營者心中到底對互連網行業瞭解多少。我的第一份工作在家人的口中被演繹出了三個不同的版本，我想這就是傳統行業對互連網行業認識的一種縮影吧，那就是傳統行業並不瞭解互連網行業，當他們想要做互連網+的時候可能更多的是腦海中一閃而過的熱情吧！

我的一位朋友告訴我，當你處在傳統行業和互連網行業的十字路口的時候，你首先要虛心地瞭解和掌握傳統行業的運作模式，然後再嘗試將其和互連網結合起來。可是更為實際的情況是當這些傳統行業的經營者有了進入互連網行業的想法以後，可能並不會從互連網的行業來看待這個想法，甚至片面的認為這個項目已然成竹在胸我們需要的僅僅是兩三個懂技術的人就好了。這種想法其實是特別可怕的，以公司為例，從我進公司以來，公司從未對即將要做的項目進行過技術上的評估和立項討論，公司的大部分美術甚至都不知道有這樣一個項目存在、更不知道做好的模型要運用到一個怎樣的技術上去以及最終會以什麼樣的方式呈現給使用者。我所看到的情況就是公司裡沒日沒夜的做模型。我想這就是領導腦袋一熱的結果吧，大概知道要做一個什麼樣的東西，可是對具體怎麼實施這個項目、實施這個項目需要哪些資源卻沒有詳細的思考。我進公司這麼長時間，基本沒有看到過成文的策劃或者是方案，更多的時候是大家在一塊兒做，然後做的過程中發現有什麼問題再返回去改，領導的態度從來沒有準，覺得什麼東西可以借鑒過來就要求程式和美術去實現，計劃朝令夕改內心深處就不知道自己想做什麼。我在公司從法律上來講應該是一名普通員工，可是在很多時候我不得不擔當專案管理者的角色。或許在這樣的情況下，我可能會收穫比普通員工更為豐富的除技術以外的經驗，可是從長遠發展的角度來看，只會讓我內心更加厭倦目前的生活，希望早一天離開這家公司！

1、項目該誰說了算？

在一個沒有策劃的團隊裡，美術和程式就像水火不容的兩股勢力此消彼長。雖然說作為一名有節操的程式員，我的內心是拒絕讓策劃來領導程式的。因為在遊戲網遊化的今天，在國內基本是找不到多少對曆史、人文、宗教等領域都有研究的策劃的。在過去開發一款遊戲，可能在遊戲的世界觀的構建上都需要花費很長的時間去研究相關的資料，可是在策劃辦公軟體化的今天，策劃關注的重點早已不再是遊戲的世界觀這些深層次的內容了，大家的關注點在什麼地方呢？可能都在關注遊戲的盈利和各種遊戲系統數值的設計上吧，這一點我不想做太多的說明，因為大家都明白是怎麼回事啦！好了，那麼現在的問題是我們處在一個沒有策劃的團隊裡，如果程式按照美術的思路去做，可能程式會在修改了若干次項目以後對美術的要求失去信心，因為相對於程式解決問題而言，作為美術的普通人提出需求的難度顯然更低。可是如果按程式的思路去做，可能美術不大會接受程式的審美，因為從我自己的角度來講，程式更喜歡純粹而簡潔的東西、更看重能否解決問題，好不好看通常都是在考慮了這些問題後再去考慮的。

我進公司以後，基本經曆了這樣兩種做事方式的洗禮，剛開始技術這邊和我說了大概思路，然後我做出了第一個原型(1.0版本),結果這個思路和公司的思路完全是兩個東西，因此1.0版本就在這樣被扼殺在繈褓中。接下來，美術提出了先做UI,然後我們在等待她們做UI的過程中重新審視了這個項目，那段時間天天往隔壁辦公室跑，搞得那個辦公室裡的妹子每次看到我進去都要抬起頭看一下。每天跑來跑去做什麼呢？答案是溝通，和領導溝通、和美術溝通，目的是在相互溝通的基礎上加深對項目需求的理解。等到美術的UI做出來以後，我們就準備做UI了，結果做到一半的時候，領導說UI設計不合格，被打回去重新做，然後我們花了一周時間開會討論，我從一開始沒有資格參與公司會議變成了每次會議都要參加，我不知道這對我是好事還是壞事，說好事吧是因為我終於有發言權了，說壞事吧是因為經常和美術爭得面紅耳赤，總之每次開完會我都忍不住要吐槽下。

那麼好了，各位看官，說到這裡我無非是想告訴大家一個簡單到不能再簡單的道理：凡事預則立，不預則廢。這就是說我們在做一件事情前一定要做好規劃，遊戲開發是一個特別考驗團隊合作的工作，如果在這個過程中我們沒有在項目立項前做好充足的準備，就會很容易出現上面的問題。當我瞭解到仙劍項目立項就需要三個月的時候，我深深地感受到了這些傳統行業經營者們的腦門一拍的決定是多麼的不靠譜啊。在知乎上曾經看到過說”項目萬事俱備，再差個程式員就好了”的類似言論，其實說這句話的往往就是這些自命不凡的傳統行業經營者們，當你覺得一個項目僅僅需要若干個程式員就夠了的時候，恰恰說明你還不夠懂互連網行業！

2、豬一樣的隊友

我身邊許多玩LOL的人都在吐槽打匹配的時候遇到的都是豬一樣的隊友，這種情況在項目開發中則更為常見。我不知道美術出身的領導怎麼會認為程式員越多項目進度就越能趕上。做項目不是大家一塊兒做模型，每個人分給幾個然後用著破解版的3DsMax就搞定了。程式在我看來更應該在保證人員配備合理的基礎上保證品質。

首先第一條，人員配備合理就是說程式員的數量要合理，其次大家的層次差別應該不會太大。因為人多了的話，對項目代碼的影響可能更大，尤其是當大家編程的風格和技術水平存在差異的時候，體現在項目中就是各種未知的Bug。為什麼要求大家的層次差別不大呢，因為層次差別太大，首先團隊內溝通就是問題，以我為例，我手下的兩個人都是培訓班培訓出來的，基本上就是老師給一套視頻然後照著視頻做出一款遊戲就結束了，我一直反感用視頻的方式來學習遊戲開發，因為你是在學習一個遊戲引擎而不是在學習一個工具軟體，雖然Unity3D提供了可視化編輯器，可是在我眼裡它始終都是一個遊戲引擎，而非一個類似Office或者是3D軟體的東西。那麼我想說的是什麼呢？我想說的是不要把編程當作一種固定的套路，經常有人直接抄我部落格裡的代碼直接運行項目，然後出了各種問題再來問我怎麼回事？碰到這種情況我首先問的第一句話是你能不能明白這個代碼是幹什麼的？如果對方不理解，我一般會先讓它搞懂這些代碼的意義。

我們公司裡的美術都不願意碰Unity3D，因為他們覺得這個遊戲引擎會增加他們學習軟體的各種成本，可是事實是這個遊戲引擎比我見過的Max、Maya、Blender等軟體都簡單啊，而且Unity3D免費版的就可以開發簡單地遊戲，比之美術口中各種不擇手段的盜版、破解軟體不知道要乾淨了多少？歸根到底一句話，美術不願意嘗試新的東西，美術總認為Max裡的模型匯出到Unity3D後材質啊、燈光啊會丟，美術總認為Max渲染的效果要比Unity3D好許多，可是既然你選擇了這個引擎來做項目，我覺得美術是有責任來瞭解這個引擎的，你讓程式員幫你拼UI我可以接受，可是你讓程式員幫你打燈光、修改材質、擺情境，這是程式員該做的事情嘛?我說虛幻四這樣的引擎都是由策劃來編輯關卡的，為什麼你們美術就不能嘗試瞭解下這個引擎呢？得到的答案是我們要做模型，顯然當美術的眼睛只盯著手頭的那幾樣工具軟體的時候，你和他們間的差距已經拉開，如果有能力、有時間的話，不妨嘗試下將編程以外的能力整合到自身的體系中，未來是屬於全能型人才的！

3、怎樣讓項目流程化

我覺得像遊戲這樣負責的軟體工程，在立項之初就應該明確美術、策劃、程式各自的責任。我的想法是美術來製作素材、程式來編寫相關邏輯和外部工具、策劃使用外部工具來編輯關卡。

在我來公司前，曾看過一位前輩寫過的關於這個項目的一個Demo，當初這個Demo裡只有兩個情境，我最初是對這位前輩頗為敬重的，因為感覺這個Demo的表現還不錯，甚至覺得如果能夠得到這個前輩指點一二，實乃三生有幸啊。可是當我和這位前輩聊過以後以及看過他寫的代碼，我對他的敬重慢慢地變成了鄙夷。這是為什麼呢？因為他向領導提議使用硬代碼來編寫項目，通過研究他寫的項目，我發現他的項目確實使用硬代碼寫成的，你能想象在一個指令碼中並列7個if僅僅是因為它們的tag不同嘛，你能想象在一個指令碼中的命名都是漢語拼音的變數定義嘛。

拋開他寫的項目不說，從規模和負責程度上目前這個項都比他的Demo有難度，首先我們大概需要製作35個情境涉及到上千種模型和貼圖而非Demo中的兩個情境，其次我們最終的發布平台是Web平台而非Demo中的PC平台。寫硬代碼意味著放棄複用和擴充性，顧及目前而不考慮以後。可是我們這個項目肯定是需要擴整規模的，難道每次添加一個新的情境都需要把代碼重新寫一遍，因此這個方案在和他交流的時候我當著他的面就給Pass了，然後他說我們先做個Demo看看，因為在前面我們已經積累了部分代碼，所以在這部分代碼的基礎上我們迅速地完成了一個較為靈活的架構。整個架構是將模型單獨打包後和貼圖一起存放在伺服器上，因為模型和貼圖對不同的戶型來說都是通用的，因為使用設定檔設計了一個類似資料庫的結構，這樣當我們在程式中需要某些模型和貼圖的時候只需要下載就可以了，因為模型和貼圖都被存放在伺服器上，本地僅僅存放相關的戶型模型和設定檔，因此項目的體積被大大地壓縮，從而可以解決Web平台瀏覽器的壓力，因為所有的情境都是使用設定檔來定義，因此當需要更新項目的時候，只需要補救伺服器上的模型和貼圖以及設定檔即可，提高了項目更新得速度。總體來講，我對我設計的這個架構表示滿意，因為它讓硬代碼的優越感蕩然無存。同時為了減少人工編寫設定檔、打包等過程的工作量，通過為Unity3D編寫外掛程式的方式實現了整個過程的半自動化。為什麼是半自動化啊？因為人在做事情的時候沒有統一、規範的習慣或者說難以統一和規範。我一直強調統一和規範，可是美術總認為程式的要求過於苛刻，可是事實上懂得編程的人都明白電腦程式不過是對某個過程的一種類比，而且這個過程是有限狀態的，因此當美術說需要XXX功能的時候，程式員的內心其實是拒絕的，因為為了這點需求，他可能需要寫十幾行重複的代碼，為了滿足使用者的懶惰和弱智，領導讓我們將戶型內的物體盡量全部實現動態化，要給使用者最大的自由，結果卻是剝奪了程式員的自由寫了若干個if或者是重複調用相同的方法，這簡直是惡魔啊！

好了，寫了這麼多，大家可能覺得這不符合我作為一個有節操的程式員的風格，說好的每周一篇技術部落格呢？其實技術運用的好壞，完全取決於運用技術的人，所以我們不能僅僅關注技術的高低，更要關注怎樣讓整個團隊高效率、高溝通率的執行下去，因為千裡之堤，毀於蟻穴啊，雖然團隊間溝通這些東西看似都是些政治或者是形式的東西，可是實際上會佔到整個項目開發中相當大的一部分，所以希望大家在看了今天的部落格後能夠有所啟發吧，好了，睡覺，哈哈！今天居然寫到了這個時候！