最近工作中，又陆续发现了Unreal的一些“隐藏的”东西。
例如Test Track整合。
例如UDS：脚本融入Visual Studio中。
例如Sync：代码合并工具。
……
加上之前的Swarm和Perforce4整合。
有时候在想，我们能在效果上超越它，能在一些具体的环节上超越它，但如果真正要完成一个商业引擎，Unreal所达到的高度，其它的引擎并不是那么容易才能完成的。
因为它的标准并不仅仅是牛逼、炫、酷、帅，而是高速高效、高集成度的开发。
当我们还会对某个具体的技术而心动不已的时候，有时候我们可能忽视了一些东西，软件究竟为何而做。
我们总是告诫自己说自己是游戏程序员，所以我们不是程序员，所以不要用程序员那套东西来教育我们。
我们总是告诫自己说自己是引擎程序员，所以我们不是程序员，所以不要用程序员那套东西来教育我们。
但现在越来越觉得我们超越不了程序员的那些东西。
程序员看到需求会进行需求分析，体系设计。我见到的很多游戏程序员，看到策划需求只会有一做一，有二做二，能做到三的已经是少数。完全沦落为策划的代工工具。我也见到过很多游戏程序员，奉行的原则就是我做一个东西，策划你就按我这个来用吧，别挣扎了……火了我负责，死了你负责，策划完全沦落为程序的奴隶。
这两种开发模式都能做出优秀的项目，如此足可以证明中华民族炎黄子孙有多么地伟大！因为在这些模式的背后，隐藏着的是无尽的迭代、无尽的推翻、重置，换句话说——这些项目无一不是依靠着已经习惯了灯火通明、满腹虚肉、在无尽的压力下，以近乎疯狂的意志而坚持着的人们。
我无意将自己与这两类思路划清界限，身在其中，有时更能体会到局中的艰辛，很多时候不是你不想，而是你没有时间，没有精力，没有好的Partener，没有一个有耐心的投资商……
但是有时候还是想做一些新鲜的东西，因为程序本来就应该这样。
人怕认死理儿，认了死理儿，简单的事情就麻烦了。
是啊，程序定死，策划打工，多简单啊。策划顶死，程序打工，也多简单啊。何苦自找麻烦呢。
但设计，毕竟并非是重现需求，而是基于需求，却高于需求。
自找麻烦，有时候只是因为本来就该是这个样子的，没有其他原因。
因为无论瀑布模型、极限模型，解决的都只是一个问题——
需求的不确定性和程序维稳之间的矛盾。
简单的开始，几乎导致的都是一个不可预知。
而妄图定死未来，则除非自杀，没有它途。