End the line…and the Endless development

到現在爲止，如果沒有奇蹟發生，那麼我過去一段時間內所從事的項目，可以說是走到了它的終點。


雖然感到委屈，但是這也是無奈的事實，中國的這個環境裏，你可能能遇到各種各樣以人類的思維所無法預知到的、卻是客觀存在的事實。一千多年帝國的統治，使得儒家變成儒教，仁、義、禮、智、信從這個民族的基因裏徹底毀滅、蕩然無存，在這樣的環境下出現這樣的結果，也只能是一笑了之了吧？說中國人沒有信仰，那中國人是從近代開始纔沒有信仰的嗎？家都能變成教，教卻再也沒能變回家，一千多年沒有信仰的生活，出現任何情況都不值得奇怪。


End the line……


but not the end of hope, and life……


 


無論如何，回頭看看也總會感謝這段經歷。在這之前，我的經歷多能證明自己是一個北京圈裏、傳統意義上的引擎程序員，然而強制地將項目與引擎割裂的這種的傳統做法，我自己卻並不能表示完全認同。


形成這個想法主要是因爲再之前所參與的那些項目。因爲06年曾經在上海待過一段時間的經歷，所以更多也能夠比較一下雙方對待遊戲項目、對待遊戲引擎上的思維差距。傳統意義上、被人爲割裂的引擎，貌似只存在於中國這片大陸，而我們發現真正我們引擎的出發點——我們所參考的那些歐美引擎的設計思想，卻並沒有這種人爲的割裂。無論是Cry、虛幻、Source還是Doom，其引擎和上層結構全都是互相補充，相互關聯，構成一個有機整體的。OGRE？倫家本身只是一個圖形引擎好伐？用過OGRE做過項目的老師們不妨想想，我們到底修改了多少東西，才使得這個本來不是遊戲引擎的所謂遊戲引擎能夠去真正製作一款遊戲？


這足以引起反思，這種割裂，究竟是否有所必要？


究竟什麼級別的軟件工程，纔可以被叫做是引擎？


廣義地說，能夠加速遊戲開發過程的整套流程、工具、插件的集合，都可以稱之爲引擎，卻爲何在耳熟能詳的範圍裏，引擎卻總是囿於圖形、物理、資源、腳本，最多再加上一個在他們外面所包裝的編輯工具集合？


那麼，項目本身何在？


這樣一個工具集合，是否能夠承擔項目開發的全部需求？以及全部需求的變化？


 


筆者參與過的項目，很多都遇到過一些同樣的問題。


每次立項結束後，整個應用程序框架就會完全重寫一次，遊戲上層的控制系統、物件系統……越偏上層的東西，就越難共用，每次都要重新設計，重新實現。而且在不同的地方，對其的實現方法和風格也完全不同……然而這些概念真的不能共用嗎？我總是感覺在不同的地方，我們似乎在重複着同樣的工作，一遍又一遍。


在三個不同的項目裏，同一個功能模塊，我看到了六種完全不同的實現，只是在最後一個項目裏我就看到了三次較大規模的結構調整。爲什麼這些功能不可能一步到位？呃，因爲策劃的需求變了。這就好比一個傳統軟件的程序設計師說“因爲用戶需求變了，我們設計師的結構也變了”，這像是一個學過軟工的程序設計師該說的話嗎？


而且，爲了通用性而設計的傳統引擎本身，每到一個新的項目，難道真的就能夠“通用”嗎？很難，每個項目的需求都會有少許的不同，這都會牽扯到引擎本身的一些改動。有些遊戲適用於大規模的地形Occlusion優化，有些遊戲則更需要狹窄空間內複雜的光照計算，有些遊戲卻對紋理本身的調度提出了更高的需求，通用的場景圖、通用的管線、就意味着無法做到有效的配合，很難針對具體的環境進行變化……。VT、LPV、DS……說到底，這些都只是工具，是否適合於項目，只有項目才能決定。你一個雙人格鬥的項目做什麼VT和Occlusion呢？重點明顯應該放在物理、動畫、表情和IK上好伐？同理，一個手機遊戲你做什麼DS呢？一個卡通風的遊戲你做什麼LPV呢？就是這個道理。從引擎出發，也就限制了項目本身的活力。喜歡做卡通風的日本人，即便選擇了虛幻三做的也是《失落的神蹟》，而不是《勇者鬥惡龍》。爲什麼別人都是先選項目後選引擎，我們卻偏偏要先定引擎後做項目呢？虛幻三做卡通風，如果用材質變換的方案，則費性能。如果用Post Pixel方案，材質系統的大部分好用的功能都用不上，何苦不專門搞一個性能高又面向需求的呢？


不僅如此，傳統的工具製作方法，幾乎是跟引擎本身嚴格相關的，這也導致了因爲不同的項目需求，工具幾乎必須全面推翻重來。


當然，我曾經也認爲這本來就該是這樣，是必然的道路，直到我膝蓋中了一箭。


因爲跟虛幻打了6年的交道、跟WPF打了3、4年交道，所以發現，這樣的問題，明顯是可以避免的。


 


於是就有了這個項目的各種嘗試：


1、傳統的引擎是功能的提供者，它的地位不能，也絕不應該高於項目本身、也就是整體解決方案的需求。


按照系統論的觀點，系統的構成第一個主要原則就是系統的每個部分必須在整個系統的大方向下服從整體的需要。如果整個項目必須依照傳統引擎來構建，這就相當於引擎系統變成了遊戲系統的核心，底層功能本身替代了內容成爲了遊戲系統的核心，最後做出來的系統，必定處處體現這個原則，並不是說這樣就做不出好的項目，因爲中國人民總是能夠創造奇蹟的，但是我們去創造這樣的奇蹟的必要性何在？以一個完全錯誤的出發點，作出一系列錯誤的事情，即便結果正確了，除了說明這些人都是牛人之外又能說明什麼？


傳統引擎的目的是爲了輔助完成項目的所有功能需求，解決方案纔是最終整體性的東西，接下來的問題只是在於：如果這個解決方案只能適用於一個遊戲或者一類遊戲，那麼它就可以自我強化爲重點完成此類遊戲。如果這個解決方案足以應付大多數遊戲需求，那麼它就可以面對各種不同類型的遊戲需求。


2、上層遊戲邏輯完全是物件系統本身的邏輯，其在程序結構完全可以，也應該被簡化爲完全使用同一類結構。就是，最好沒有Actor和Trigger的區別，沒有Player和Monster的區別，沒有Building和Unit的區別。軟工一個最主要的原則就應該是歸納法——從看似不同的對象中間，抽取出同樣的功能構成，來完成一套基本的層次結構。只有有了歸納出來的原則，才能更靈活地在此層次下去做出演繹。我們所處這個次元、所有的自由都是由那些不能自由的“原理”來提供基礎的。離開了這些基礎，自由本身毫無意義。海平面上100度的水你能煮飯，喜馬拉雅山上88度的沸水你還能煮飯嗎？煮出來的就是夾生飯。就是這個道理。


3、有了歸納出來的層次，則儘可能讓之後的活動由策劃來主導，而非程序來主導。理由很簡單：程序有程序BUG，而策劃只有邏輯BUG。傳統工作流下，策劃提供需求，程序實現需求，再小的模塊，穩定下來也得一個多月。如果把邏輯工作交給策劃去做，程序只是實現模塊化好的、接口化好的功能，那麼，程序的BUG可以用瘋狂組織的單元測試對其進行驗證。而從策劃的角度來說，可以在不等待程序參與的情況下開始驗證自己的思路和思想，也可以鋪更多的人手來進行具體的驗證工作。這就好比說我們程序定下了海平面附近，100度時水能沸騰的大原則，而具體是用100度去煮大米飯還是大麥茶，那是策劃的事情了。讓程序從邏輯工作中解脫，並且去追尋程序真正該追尋的東西，因爲那纔是程序本身應該去做的工作。


我看過很多程序寫過傷害數值計算公式，就是被動地把策劃的公式拿過來鈔謄一遍，何苦呢？先不考慮人力成本，程序寫的東西一定不會出BUG嗎？平白無故多出來的這個單元，需要組織單元測試嗎？難怪老外的程序可以每天朝九晚五，而中國的程序都得天天加班，這明顯不該咱程序做的東西，咱幹嘛攬過來做？提供個通用數值工具讓丫策劃自己搞去！


 


如果好好考慮一下，其實還有很多可以做的東西，比如工具化——在這個原則下，工具應該怎麼組織之類的問題。很多問題我們都考慮過了，卻沒有機會實現了。


可以說這三點都做到了，都邁出去了，可惜，沒能走到最後。


雖然無法驗證說這條道路究竟是否是正確的，但是，只是基於自己的理解，卻還是覺得這條路應該繼續走下去。


寄希望於他人，不如寄希望於自己，相信自己所選擇的道路，並堅持下去。


 


具體的項目中總會有無盡的問題，技術所能解決的問題在其中最多隻佔兩成，那八成是因爲各種人的問題所造成的。然而，人的問題，卻因爲人羣的構成而變得不可捉摸，也讓技術本身總是在風險和迷霧中前行，找不到屬於自己的理想鄉。


嘛，無所謂了。


這就是現實，Avalon畢竟只是Avalon，只能存在於傳說和幻想中的東西。


Hope 也不過 is just hope。


那又如何呢？


有了希望的存在，也不需要因爲挫折而選擇放棄。


“End the line” is not “end of the world”.


前面，仍然是一條Endless的道路……