最近工作中，又陸續發現了Unreal的一些“隱藏的”東西。
例如Test Track整合。
例如UDS：腳本融入Visual Studio中。
例如Sync：代碼合併工具。
……
加上之前的Swarm和Perforce4整合。
有時候在想，我們能在效果上超越它，能在一些具體的環節上超越它，但如果真正要完成一個商業引擎，Unreal所達到的高度，其它的引擎並不是那麼容易才能完成的。
因爲它的標準並不僅僅是牛逼、炫、酷、帥，而是高速高效、高集成度的開發。
當我們還會對某個具體的技術而心動不已的時候，有時候我們可能忽視了一些東西，軟件究竟爲何而做。
我們總是告誡自己說自己是遊戲程序員，所以我們不是程序員，所以不要用程序員那套東西來教育我們。
我們總是告誡自己說自己是引擎程序員，所以我們不是程序員，所以不要用程序員那套東西來教育我們。
但現在越來越覺得我們超越不了程序員的那些東西。
程序員看到需求會進行需求分析，體系設計。我見到的很多遊戲程序員，看到策劃需求只會有一做一，有二做二，能做到三的已經是少數。完全淪落爲策劃的代工工具。我也見到過很多遊戲程序員，奉行的原則就是我做一個東西，策劃你就按我這個來用吧，別掙扎了……火了我負責，死了你負責，策劃完全淪落爲程序的奴隸。
這兩種開發模式都能做出優秀的項目，如此足可以證明中華民族炎黃子孫有多麼地偉大！因爲在這些模式的背後，隱藏着的是無盡的迭代、無盡的推翻、重置，換句話說——這些項目無一不是依靠着已經習慣了燈火通明、滿腹虛肉、在無盡的壓力下，以近乎瘋狂的意志而堅持着的人們。
我無意將自己與這兩類思路劃清界限，身在其中，有時更能體會到局中的艱辛，很多時候不是你不想，而是你沒有時間，沒有精力，沒有好的Partener，沒有一個有耐心的投資商……
但是有時候還是想做一些新鮮的東西，因爲程序本來就應該這樣。
人怕認死理兒，認了死理兒，簡單的事情就麻煩了。
是啊，程序定死，策劃打工，多簡單啊。策劃頂死，程序打工，也多簡單啊。何苦自找麻煩呢。
但設計，畢竟並非是重現需求，而是基於需求，卻高於需求。
自找麻煩，有時候只是因爲本來就該是這個樣子的，沒有其他原因。
因爲無論瀑布模型、極限模型，解決的都只是一個問題——
需求的不確定性和程序維穩之間的矛盾。
簡單的開始，幾乎導致的都是一個不可預知。
而妄圖定死未來，則除非自殺，沒有它途。