读代码

上周基本上把交待的任务做完了，今天交给游戏策划人员们测了一下，除了界面上的一点小调整，其他都pass通过了。略有一点点意外，提交了代码没反馈什么bug，还真有点不习惯，呵呵。于是，今天继续开始学习过程，学习这个游戏的架构和盖子大叔的360开发工具包，还有不少没看完（主要是看了就忘了，不转化成实践经验真的记不住多少东西，说实话）。
看别人写的代码多半都会有一种感觉，就是觉得自己能比这个写得更好，这次我也有点这感觉，不过很快就把它压下去了，因为我知道自大会给我带来什么。
我觉得我似乎有点反主流思想。软件我学了有几年，也做了有几年，windows的开发几乎从来没怎么碰过。唯一一次的windows项目，还是把系统相关的部分（说白了就是mfc, win32）分给了其他同仁做；唯一的一次windows编程（win32）选修课，还是因为任课老师是我的熟人，过了；目前买的唯一一台笔记本，也不是wintel的——你说我是linux爱好者？你太抬举我了——我买的苹果电脑，ibook。之所以买它，是因为它是苹果里最便宜的，其实当时我看上了12寸的powerbook，不过官方价比ibook要多6000，心疼，没舍得买（实际上更主要的原因是没那个耐心存钱）。
跑题了，说到正文上来。粗粗看了一下代码，马上对这哥们佩服得五体投地，消息机制用得太熟了，宏定义得太遛了，严格的说使用了不少的花式技巧。我这样说的意思并非贬意，但也不是完全的褒义，因为凡事都有两面性嘛。说它设计的好，主要在于充分利用了消息机制的优势，在某种程度上来说方便了开发；但就游戏设计本身来说，尚有不少欠缺之处。以前在游戏公司呆的时间不长，但对游戏的基本结构也有所了解和体会。这个项目缺乏必要的状态机会，在添加和维护功能的时候不得不出现大量的新的变量，导致整个数据结构的膨胀；而且对于一个新加入的人员来说，真的是不容易摸清它的脉络——这与我以前看过的游戏程序结构差别非常的大。当然，仁者和智者都有各自的见的，也不是说做游戏就非得要那样的结构，不过它确实存在着很多弊端。不过，对于我这样的一个游戏业新手，也还有很长的路要走。
然后就是xdk了。说来说去又说到xdk。前前任公司的一个同仁，也是我现在的好朋友，在msn上聊天，谈到dx的学习进度，自然就提到了shader。其实之前我也打算开始研究shader了，并且做了许多准备，比如从n卡和a卡的网站上把它们各自提供的shader创作工具下载了下来准备进行研究（苹果用不了，只能在公司的机器上用，郁闷）。我就一直在想，单从开发的角度上来讲，实际上已经有很多的shader资源可以供我们利用了，制作出各种复杂炫丽的效果不成问题，但我看到的一些人仍在不辞辛劳地敲着键盘写shader。我就有一个想法（已经很长时间了），为何没有比较方便的shader合成工具来辅助程序员们进行创作呢？rendermonkey和fx composer已经做得不错了，但距理想仍然还有差距。实际上利用拖放的直观操作方式实际上也应该能够制作出想要的效果的shader，并且如果能让策划或美工人员掌握使用这样的工具，那么游戏的开发过程将达到非常和谐的地步，程序员与其他人员之间的交流也应该能变得更容易，不用说效率也大大提高了。
所以，我决定，开始深入研究shader创作（我用创作不用开发一词，就是为了体现我前面所说的目的），希望能达成这目标。研究进程随后不定时向大家汇报，也有可能我自己了解的面不广，已经有了类似的工具也说不准，呵呵。