结束繁忙的一年项目长跑，回归博客

好久没来写博客了，不是因为懒了，而是最近一年都在忙于我的毕业设计+大学生创新创业项目，这是我在制作中的Steam的独立网游《月之暗面》，这个月就差不多发布了。虽然游戏中因为经费不是很够等原因，或许有些不满意，但是我觉得我们作为大学生可以独立去完成一个发布游戏，而且是联网的，已经很了不起了。我想，比起赚钱更重要的是，这个项目，我们从中学到了什么。

很多人大学里做过的项目很少。但我本人比较倾向于项目实践来巩固、加深自己对于知识的理解，我几乎每学新的东西都要做一个小玩意，又能满足自己的成就感，所以大学里做过很多次项目也就不奇怪了。

不过这一年虽然忙归忙，但是疏于写博客也是不应该的，做项目的时候领悟到有许多心得应该立即记下来的。程序员不光是要能做，还应该学会能把自己学的东西表达出来。以后这一点应该铭记于心。

说一下总的心得吧，做了一年的项目，带了其它4个成员完成，也算是一件很难得的事。

1. 确保每个成员清楚理解需求再开始进行项目
   以往我几乎都是大部分一个人完成的项目，而这次是团队合作，而且我作为主程带头人。我觉得我在这个过程中没有做好的很重要一步（或是其他成员没有齐心协力做好的一步）就是理解项目的需求，虽然是游戏（策划就是需求），但不代表跟其它软件开发过程有什么不同。如果某个成员对于需求理解得不够清晰，就会造成项目开发过程中可能会做错某个功能（没有按照策划的意图）。理解策划案，即使花上好几天时间来商讨清晰的需求，也比开发过程中做错某个功能再重做省力气与时间。敏捷开发也不等于可以需求模糊，它是建立在清晰的需求上再发生敏捷变化。

2. 确定好技术方案再写代码
   尽管程序员做项目时都是边学边做，但是负责人应该尽早决定好项目选用什么技术方案（为什么选用这种技术方案，有什么优势，应当做一下调查研究），以免后期项目庞大改动起来颇费时间。比如一开始服务端应该选用什么网络框架和数据库，应该尽早确定，尽量避免后期改动技术方案。

3. 对于C++程序员，内存管理不可忽视
   游戏是我自己写的2D引擎做的，之所以不用商业引擎，纯粹是想专研技术，积累经验。而这个项目得到一个很宝贵的经验就是前期也不可以忽略内存管理，一定要明确对象的生命周期管理和对内存使用量有所把握。一开始我决定做2D游戏，我心想2D游戏已经发展了这么多年，内存应该可以足够应付有余吧。但是实际上到了后期我发现内存问题频出，如果光是用C++的话，内存管理可能也没那么棘手。但是我的引擎融入了Lua，因为Lua的内存是靠垃圾回收器自动管理的，只要一个对象没有引用，到了垃圾自动回收的时候就会去把该对象释放。而C++的对象生命周期是靠程序员去new和delete的。难点在于，任何一方的对象是否被释放掉，另一方可能完全不知道。

   • 比如我在Lua创建了一个对象，然后保存在C++层中（原生C++指针，不增加引用计数），接着在Lua中这个对象被释放掉了，但C++层中完全不知道，结果在C++逻辑中使用该对象就会引发程序崩溃（非法访问内存）。
   • 还有一个问题就是，Lua创建了对象，在C++层中可能对其保持引用计数，因此即使在Lua将对象置空，也不能释放该对象，造成了内存泄露。一点点的内存泄露也不可以忽视，游戏程序是一个循环，反复的小内存泄露最终会造成巨大的内存泄露。（最后内存不足，程序也会崩溃）

   后来我是怎么解决这个问题的呢？1. Lua创建对象后，C++只要保存了该Lua对象就一定要对其增加引用计数。（可以看你用的C++转Lua库文档说明）2. 释放Lua对象的时候，注意这个Lua对象在C++层有无不小心保持了引用（也是跟C++转Lua库的文档说明有关），然后将C++层对该Lua对象的引用也要解除掉。（像我的话，因为有函数引用了该对象，然后在C++层保存了该函数，结果即使Lua中让对象置空也无法释放该对象）。也可能是我一开始对内存的关注度不够高，借鉴的资料也比较少，所以后来在原有框架上再改改补补的对于内存这一块的代码自己也不太满意，希望以后的项目中首先多点关注这方面的知识，再去写框架或逻辑。

4. 尽量借鉴轮子而不完全造轮子
   在项目中写的最为痛苦的一个模块就是UI模块，UI模块是完全用Lua写的。一方面因为Lua中对于类的功能不是很完全（虽然Lua什么类都可以造，但是略麻烦，不够C++的类完善好用），另一方面UI模块比我想象中要难写一点，光是自己完全从零写起，虽然最后磕磕绊绊写完了，但是功能也不够出色完善。对于某些轮子，借鉴比从零造省心一点而且更出色的时候，就不应该完全造轮子（除非是想专研技术或锻炼能力，就应该往自己想深入了解的东西造轮子）。不过最后怎么样也是完成了一个比较艰难的模块，也算是自己一种极大的磨练。

5. 成员之间沟通问题
   我想大多数程序员都是对着电脑多于对人（比如我自己就是），所以与人打交道这种事对我来说还是挺麻烦的，不过还是要从中学习到教训的。每个人有不同的性格，最好清楚了解各人的性格，有的人需要鞭策才能前行，有的人需要激励才能前行，对于不同的人要采用不同的沟通管理方式。另外，一个人的本质可能不太容易改变，如果自己以后在招聘的时候，应该注意考察一个人的本质性格，毕竟如果经常容易给项目造成麻烦的话或者不能适应该项目工作的话，最好考虑慎重。

6. 解决问题的能力有时候比掌握的知识更重要
   做一个以前没做过的项目，肯定会遇到很多困难，编译错误、链接错误、莫名奔溃、莫名卡顿、莫名抛异常、莫名渲染异常、逻辑异常等等千奇百怪的问题是一定会出现的，如果你写代码有多严谨，都不可能完全避开所有的阻碍。我在教其他成员的时候，最重要的是传授给他们解决问题的能力或思维。遇到一个问题，首先自己能不能稍加思考，想想这种问题的本质出现原因是什么？如果有明显的错误提示、异常提示或可能的关键词，可以借鉴谷歌或百度（谷歌优先，集合了全球的程序员智慧），你遇到的坑很大可能前人也遇到过。如果该错误很难表达出来，但是可能有一些示例，就应当查找示例（通常一些奇怪的问题对比Demo很容易发现自己哪里写错了）。如果所面对的问题有相关文档，也应该查阅文档，看看自己是否误解或不了解某些方面的知识，顺便补充一下自己的知识。当然不可避免有些时候，我自己遇到的问题上述途径都解决不了，就需要自己发挥独立甚至创造性的思维能力，去猜测是否某些原因造成的，再去验证。还有一个方法，但是我用的比较少，就是去群里或者论坛（国外的stackoverflow、gamedev等国外论坛，国内论坛不建议，人气较少）求助，如果遇到一些好心人，可能也能帮助你开云拨雾。

7. 巧用20/80法则，但是学无止境
   之前我的一篇博文说过，要学一样新知识，只要用20%的时间可以掌握80%的知识，没错，的确这样很容易可以上手一样新知识。但是作为一名对自己严格要求的优秀程序员，也会不断以更高的标准去要求自己，即使C++语法多，但不等于我们学了那80%常用的语法就停止不用学习了，我经常看一些第三方库，他们用的语法都比我写的简洁和优秀许多，这也许就是那20%的知识差距，也是平庸和优秀之间的差距。所以优秀的程序员对自己要求再严格一点，要求自己写的程序再简洁一点再快一点，就不应该停止学习知识。学无止境，是程序员的坎，也是程序员的乐趣。

还有一些与技术无关，但与游戏相关的感悟：

这一年做的这个游戏项目，首先自己是喜欢这个类型和玩法，所以就按照自己喜欢的方向去做了。当时没有怎么考虑市场的需求、玩家的需求，作品公开之后才发现很多玩家的口味和自己不太一样，首先是精美的画面（我承认画面由于很多经费不足等很多原因造成不够优秀，希望以后我再做的游戏可以改善），只有画面够好看才能吸引玩家。我对画面要求没那么严格，可能是很多玩家玩多了大作之后，对画面要求也渐渐要求高了起来。所以我把关注都放在游戏的玩法与内涵上，也可能是玩法比较类似一般网游（但其实是有很多创新之处的，只是大部分玩家没有仔细了解），反响不太大。但是我自己是很用心地去做这款游戏，觉得这款游戏挺有趣的，也试图去往有内涵有深度的方面走，我想尝试做不一样的游戏，今后也会继续努力，希望有朝一日可以做出让自己和玩家都满意的游戏。

然后说一下接下来的打算，首先是找工作啦，希望能找到一间可以做端游的大公司（比较热爱端游和主机游戏），最好是用UE4的，那我就同时可以继续专研底层图形学了。这个大四的毕业设计也做的七七八八了，剩下大四一个学期，应该有时间了，继续希望打好自己的基础同时（做项目感觉基础越扎实解决问题越高效），还有深入学习3D的东西，还有很多想看的图形学的书没看。如果工作需要的话，可能也需要学习引擎。大学时间很快了，一眨眼就大四了。从小学开始坚持游戏梦，可能人生也是这么短暂，眨几下眼也过去了。希望自己不忘初心，努力学习技术，做自己想做的事情，做更好的游戏。一天一小步，慢慢靠近自己的理想。

（图为我最喜欢的游戏，《赛达尔传说：荒野之息》）