2014年6月日志

20140609

嗯啊= =

总之最近还在彷徨期。但大致的路明确了~~先用半年时间来确认下自己想法的可行性。

首先自己继续独立游戏，要进一步进入美术工作，并且将策划细节加强一下。例如火箭的尾部粒子特效，怪物被打击位置分离为头身（目的是headshot机制增加），修改弓箭的弹道同时增加显示机制，考虑增加出兵对抗，考虑增加一些基本的对白以填补剧情这些，总之吧，一步一步完善自己的小游戏。

这些都是业余时间进行。顺道找下合适的移动平台2D游戏开发引擎，替代cocos2dx。

然后在公司的话，走另外一条路，纯技术走走看，不过要记得，把一个东西弄到极致并有很强的扩展能力，以适应更多的变化，这块可以继续的沉淀。同时，公司里面的U3D这块继续学习沉淀下。

记录下就这样。开工~

20140619

前一阵子，整理了下《程序员编程之道》这本书。其中印象最深的有两点：一是多考虑沉淀复用，不许凑合；二是自动化，自动化生成代码也好，自动化下载编码测试发布也好，都是强调尽可能的减少手工，交由机器负责。

最近又一直在接触U3D，这东西就是个编辑器，用多了发现丫的整个就纯是个编辑器。没错，它有自己的一套机制，对象管理也好，消息分发也好，资源管理也好，但因为不开放源码，我们无法调整。而且许多需求它几乎无法满足，例如热更新资源等（当前国内许多游戏是边运营边开发），它在这块做的相当不好，另外其渲染效率也只能说是一般般。

看起来上面说的两个话题有点风牛马不相及，其实一个道理，都在追求快。自动化的目的主要是快，当然还有一定的安全；U3D的存在目的也是开发便利（导致开发快，见结果快）。

我临时扯远一点。我想到最近接触U3D的一些感想：首先U3D本身很容易理解，但隐藏过多，定制性很差，部分项目只能轻度使用其编辑器，而更多利用其API，弄的很cocos2dx有点像了，蛮尴尬的。但就因为这么搞，结果大量的时间都在C#编码上，其中利用的U3D API还好，我之前做引擎的，理解起来不难，只是C#这块实在头疼无语，各种奇怪的底层库和奇怪的语法，理解起来要消费好多时间。结果我看代码就成了“代码设计思想很容易理解，架构轻松看懂，但一到细节编码，立马跪了”的状态，和同事一说，他们笑话我是“王语嫣”……于是我在抽烟时候想到了武功，又想到了“天下武功，唯快不破”这么个事，才扯到了上面的“快”的话题。

好，回来继续。U3D因为开发快有优势，但渲染效率不佳；C语言因为效率快有优势，但编码膨胀过大，开发慢。如果说我们找到“快”的方法，在开发效率和运行效率找到一个组合点如何？（显然，我不认为这两点是相悖的。）这或许是应当追求的一个方向吧。以后选择引擎和语言甚至平台的时候也就更加明确了一些吧。

另外最近接触了一种思想，现在很觉得可以在其上发散一下。就是游戏的特点不仅仅从策划层面走（加入奇怪的新玩法，设定的一些组合等），或者走美术（例如很有特色的水墨画风，和风等），其实从程序层面也可以找找个性特点，而且或许更好。

具象化一些举例，例如minecraft的大世界生成，Diablo的随机迷宫，光效组合等，看似策划设计，其实程序也可以考虑。（当然，上面说的或许都不是很新潮的技术）但是像时空幻境等游戏还是在走这条路的。

最近有个《龙之皇冠》的游戏，看到它的表现细节时候真的是大吃一惊，如果这个游戏是3D的，那么我可能毫无感觉，但是2D，其水面，其背景，其光影效果真是让人震惊，然后到IGN排行榜搜索了一下，前几名的游戏几乎个个都能在其程序表现上找到极明显的技术性。

用同事一句话来说“放心，任何一个精品游戏，其引擎和技术都是定制的，通用的引擎永远只出平凡的游戏”。（啊啊，某志再补充下，他这是在说国外，这条在国内不适用）

我现在的确觉得是这个味。