第一篇博客

潜水多年终于决定要开始写技术博客了，不过相较于这一时的冲动，我内心中对于自己到底能够坚持多久表示深深的怀疑。

虽然还没毕业，不过算上来大大小小的也做了不少项目了，其实每次做一个项目的过程中都能学到非常多的新东西，有很多新感悟，但是项目中总是没有时间去总结，而项目结束后又急于放松不愿意去废时间将学到的东西记录下来，周而复始，到现在觉得浪费了不少时光。当然通过各个项目的经验积累我还是能明显的感觉到自己的成长，但我相信，认真的总结与回顾将会是我更进一步。

另一个想写博客的原因自然是希望分享与获得关注，也算是督促我进行总结的一种方式吧。当然，说到底，我想我真正开始想写博客的原因还是因为。。。。。太寂寞T_T

就写到这把，该去做总结工作去了，先把许久之前写的一篇贴上来吧，这篇文章还是我没事儿在百度搜自己名字时搜出来的。。。。当时那叫一个激动啊，也算是从那次起我开始有了写博客这个想法。

实训总结

这 次实训终于结束了。我第一次作为组长带领团队交付一个完整的项目，这个过程中的点点滴滴实在是有必要总结一下，其实总的来说这次实训中我并没有时间去研究什么新技术，由于大作业时做的是地形，本来想借小学期的时间好好研究下粒子系统，不过面对每天很大的工作压力也没有实现，看着其他组都用上了PhysX物理引擎、CEGUI等 心里实在是羡慕嫉妒恨啊。回顾这次实训，其实相对于编程来说，我最为重要的收获是亲身实践了一个软件项目的管理过程，并且在这个过程中获得了很多经验与教训，尤其是教训。作为一个程序员最终还是要走上管理职位的，因此我觉得这些经验与教训并不亚于编程方面的技术积累，所以我也更有必要好好地总结一下这次实 训的管理过程。

 

一、        实训回顾

由 于我并不是软件学院的学生，所以如何了解组员的能力、状态是每次我分组时遇到的最大难题，不过这次由于之前已经和他们一起做过学期的大作业，所以基本掌握了全组的情况。由于我之前做的是地形，对静模导入、摄像机、操作控制这几个游戏的基础模块也已经掌握，因此刚拿到项目时的想法便是“没有问题，项目还能够 在我的掌控之中”。但是从之前做大作业的情况来看，我们在粒子特效方面基本没有任何技术储备，因此我为我们项目组定下的目标也仅仅是“能够成功实训项目交付的基本要求，尽量多的加入特效及其他技术”。本身的目标算的上很低了，因为有第一次实训的教训，所以我在项目开始前便已经做好了最坏的打算。

实训第二天为了D3D的大作业刷了一晚上，不过在第三天居然又精神抖擞地工作了一整天让我自己都感到很神奇，这也算是实训过程中的一朵小浪花吧。

项目开始之初我的计划是还按照之前的分工研究粒子系统的继续研究，做骨骼模型的由于已经有提供好的SkinMesh类，因此主要帮我打打下手，同时作为副组长帮我在他们回到后宿舍进行督促，而做界面的我在对他的编码能力有了充分的了解后决定先让他负责策划、立项等文档，等我研究好CEGUI后再讲给他做。

想法总是美好的，而现实又是残酷的，实训开始的前几天组员们的工作效率实在很低，每天下班前布置的任务第二天来也还没完成，而我的计划则是一改再改，本来甚至是计划在第一周完成基本的游戏流程，在第二周集中做特效、AI、阴影、水波等一些优化技术（哎，本来还要研究下阴影的shader呢），不过实际情况却是到周末才完成。这种状态到第四天时着实让我感到了很强的交付压力，最终我摒弃了对全部之前没有掌握技术的研究计划，连GUI也是在经历了两次对CEGUI的调试失败后也干脆自己用dDraw写了一个小类库。

到 第二个星期的开始，游戏引擎的核心部分已经做好，四个地形也利用周日的休息日做好，而组员们的工作效率终于开始高起来，赵煜在第二天早上就完成了全部场景内模型的搭建；张玉堂在我给他用粒子编译器演示过对特效的需求后，在下午便实现了基本的特效效果；而朝克完成的策划需求文档以及图片资源的搜集让我感到很 满意，这一切真是让我十分的欣慰，顿时感到项目的前景又光明了起来。剩下的一切都进行的紧张而有序，怪物模型的引入，对话系统的实现，碰撞、AI的设计与实现，特效的合成，逻辑的优化以及音效的加入，在小组成员的齐心合力下，我们最终成功的交付了这次实训的项目。

 

二、        经验总结

对 于这次项目管理的反思是从倒数第三天的内部评审开始的，看到别的组做出的丰富的游戏特效，我们组在这方面并没有做好。虽然说我们组成员的编码水平可能并没有几个很优秀小组的成员那么高，但有他们认真的工作态度，以及其他一些小组展示的效果来看我们理应能做的更好，这首先让我对我的管理方式产生了反思，这一 反思却发现好似复习了一遍软件工程管理课一般，这才深深体会到了管理学在软件工程这一专业中的重要作用。尤其是当组员中没有所谓的牛人时，如何最大化的调动发挥组员的作用实在是很有学问的。

1.       人员管理

我 对于人的管理有自己的管理哲学，我喜欢自我约束，而不是被人约束，因此我在人员管理时也是喜欢放养式的管理方式，希望能够通过自己树立的榜样增加组员的自我约束。这个怎么说呢，性格使然，虽然了解并常常深切地感受到这种管理方式存在的问题，尤其是在面临项目交付压力的这样一种场合中，不过我想这个在短时间 内真的很难改变，也只能是通过对自我更加严格的要求来进行弥补。

2.       项目管理

首 先是项目进度的安排，在听了所有小组的项目汇报，尤其是关于工作量分布的柱状图后我了解其实大多数人在实训过程中都是经历一个工作效率由低到高的过程，而我一开始的进度安排却没有考虑到这一点，再加上对于文档工作量的低估，导致对于项目进度产生了错误的判断，自己第一个星期其实做了很多本可以拖后安排给组 员的工作。这也是由于平时大作业都是一个人做，而我的做法一般是早早开工，提前完成基本要求，再花很长时间对细节进行优化，因此以后还是要多多合作项目，才能够准确把握小组工作进度的安排。

另一个很重要的便是需求优先级划分。在这次实训中我花了很大一部分经历去对细节进行完善，包括场景渲染、地形图制作、怪物AI以及整体的游戏逻辑，而其实从优先级的角度来看我实在是应该利用这些时间和经历去帮助组员多研究一下粒子系统，我相信有这些时间是足够我们做出更加炫丽的特 效来的。不过这实在也是有些身不由己，每做出一个阶段成品，或是完成一个功能模块，我总是会有强烈的冲动去完善每一个细节，为此花去大量的时间和精力，这在交付压力不大时（比如上次实训）其实算是个很好的习惯，但是面临像这次实训的环境下，我觉得我有必要能够改变这种习惯。验收前一晚上我列出了所有目前我 们还需完善的功能项以及优化项，并标记了优先级再将其分派给各个组员们，这才想到其实如果能早点用这种方法来确定每天的任务分配也就不会感觉到大脑如此混乱了，因为确实这一个游戏项目所涉及到的事情实在太多了，光用脑子记便往往会乱了套，这也是我这次实训过程中总是变更分配任务的原因所在。

3.       游戏架构

这 是我认为这次实训给我最为重要的经验也是教训。在了解到了一个游戏的基本架构时，也深深地让我明白了“烟囱系统是如何构成的”。。。。可以说这次我们的这个烟囱架构是我一手造出来并亲眼看他是如何“成长”的。这学期老师在讲烟囱系统的时候我还想这么烂的系统既然都明白又怎么会存在呢？现在我明白了，烟囱系 统的形成就是两句话：“系统设计之初欠考虑，发现问题后没时间改”。

项目开始前，我并没有做过一个完整的游戏，只是使用过Unity3D的游戏引擎，觉得他使用场景Scene以及GameObject的概念十分不错，因此设计之初便是想模仿这种方法。使用场景管理器统一负责场景的创建、渲染及销毁是我一直坚持的理念，因此虽然没有时间抽象出GameObject类，但是整体框架的设计核心还是基于以BasicScene作为基类，派生各个场景子类。但我却忽略了一个很重要的组成部分，游戏逻辑，这既包括场景内逻辑，又包括场景间逻辑，而这部分却很难在现有框架下抽离出来。 等到发现时以及进入了项目后期，根本不可能有时间去重新整理架构，结果只能是开放大量的公共变量，我就眼睁睁地看着自己设计的架构变成了一个烟囱系统。。。。心痛啊。痛定思痛，其实也不应太沮丧，毕竟也是第一次进行结构上的设计，至少通过这次失败发现了问题及问题产生的原因，而赵心砚提到的MVC架构实在让我有一拍大腿的感觉，接下来我还是应该继续自己的思路尝试下去，同时也应该多多学习并吸取目前成熟流行的框架设计思想。

4.       关于C++

C++的学习一直没有终止，但是效率很低，同时像C++中的STL也很少敢于使用，借这次实训的机会我尝试了很多C++的特色语言，包括虚函数，vector，引用，命名空间，以及外部声明，虽然是使用了，但同时也了解到这里还有很多不明白的地方，尤其是类的继承上，也不知道是不是时间消息函数的原因，我一旦在场景的子类中加入成员变量便会引起运行错误，最终一个本来简单的场景基础关系被我误打误撞的弄成了Template Method模式。。。让我实在感觉 “还差点远呢”，而且项目开始前的C++测试也才65分，实在是汗颜。这个假期中一定要把C++的学习作为重中之重。