最近工作中，又陸續發現了unreal的一些「隱藏的」東西。
例如test track整合。
例如uds：指令碼融入visual studio中。
例如sync：**合併工具。
加上之前的swarm和perforce4整合。
有時候在想，我們能在效果上超越它，能在一些具體的環節上超越它，但如果真正要完成乙個商業引擎，unreal所達到的高度，其它的引擎並不是那麼容易才能完成的。
因為它的標準並不僅僅是牛逼、炫、酷、帥，而是高速高效、高整合度的開發。
當我們還會對某個具體的技術而心動不已的時候，有時候我們可能忽視了一些東西，軟體究竟為何而做。
我們總是告誡自己說自己是遊戲程式設計師，所以我們不是程式設計師，所以不要用程式設計師那套東西來教育我們。
我們總是告誡自己說自己是引擎程式設計師，所以我們不是程式設計師，所以不要用程式設計師那套東西來教育我們。
但現在越來越覺得我們超越不了程式設計師的那些東西。
程式設計師看到需求會進行需求分析，體系設計。我見到的很多遊戲程式設計師，看到策劃需求只會有一做一，有二做二，能做到三的已經是少數。完全淪落為策劃的代工工具。我也見到過很多遊戲程式設計師，奉行的原則就是我做乙個東西，策劃你就按我這個來用吧，別掙扎了……火了我負責，死了你負責，策劃完全淪落為程式的奴隸。
這兩種開發模式都能做出優秀的專案，如此足可以證明中華民族炎黃子孫有多麼地偉大！因為在這些模式的背後，隱藏著的是無盡的迭代、無盡的推翻、重置，換句話說——這些專案無一不是依靠著已經習慣了燈火通明、滿腹虛肉、在無盡的壓力下，以近乎瘋狂的意志而堅持著的人們。
我無意將自己與這兩類思路劃清界限，身在其中，有時更能體會到局中的艱辛，很多時候不是你不想，而是你沒有時間，沒有精力，沒有好的partener，沒有乙個有耐心的投資商……
但是有時候還是想做一些新鮮的東西，因為程式本來就應該這樣。
人怕認死理兒，認了死理兒，簡單的事情就麻煩了。
是啊，程式定死，策劃打工，多簡單啊。策劃頂死，程式打工，也多簡單啊。何苦自找麻煩呢。
但設計，畢竟並非是重現需求，而是基於需求，卻高於需求。
自找麻煩，有時候只是因為本來就該是這個樣子的，沒有其他原因。
因為無論瀑布模型、極限模型，解決的都只是乙個問題——
需求的不確定性和程式維穩之間的矛盾。
簡單的開始，幾乎導致的都是乙個不可預知。
而妄圖定死未來，則除非自殺，沒有它途。
重要的不只是技術
原創 王健 一 多年以前，我有個學生在一家做 工作流引擎 的軟體小公司裡工作。他遇到了一些麻煩。什麼是 工作流引擎 簡單地說，是一種可以自動執行流程的工作元件 使用者設定好基本的引數，該元件就能按照預先設定的工作步驟和業務的流程往下走。聽起來很酷，看上去很美。學生的麻煩是 公司的產品做得歪瓜劣棗的，...
規範的不只是個性
part1 原諒我的思緒再一次天馬行空了，看完了部落格裡面的幾個鏈結後最先投射到腦海中的不是google，不是strict coding standards，而是2012年的奧運會的足球決賽。這場決賽過後，當時我所以為的毫無懸念的冠軍 巴西隊 意外地輸掉了這場比賽，當然，也許 意外 這個詞只是對我而...
本地回環位址不只是127 0 0 1
本地回環位址 loop back address 不屬於任何乙個有類別位址類。它代表裝置的本地虛擬介面，所以預設被看作是永遠不會宕掉的介面。主要作用有兩個 一是測試本機的網路配置，能ping通 127.0.0.1 說明本機的網絡卡和ip協議安裝都沒有問題 另乙個作用是某些server client的...