回公司以后我们正好在做小天才的英语项目。所以我们12届大学生这批新员工就接了一个游戏的修改，后来看我们新员工接一个游戏任务不饱和，我们又接了一个游戏的修改。下面就谈谈我在这个项目中的一些个人总结吧。
第一，是自己编程能力与经验的严重不足。刚开始接的第一个游戏是《狼堡大解救》。这个游戏本身难度不大，但这个游戏是使用GEI写的，框架也已经写好了。GEI以前从来没有接触过，对于那些API甚是不熟悉。对于框架，以前都是自己写的。总之，刚开始的时候感觉一切不熟悉。好在很多东西都是想通的，熟悉了几天之后就正式开始修改游戏。然后噩梦从一开始就种下了。由于自己从未参加过项目，拿到策划的PPT就按照PPT的策划内容开始修改。修改的时候，完全没想过可能再要进行修改，结果导致代码写的自己看起来逻辑都很复杂了。就拿我接的第一个游戏来说。《狼堡大解救》由于之前就是直接盖上锅后开始旋转后用户进行选择，修改的文档说要灰太狼抱鱼/鸟然后扔进锅里。我想当然的以为是只有每一关的第一轮灰太狼才有这个动作。结果给策划说每一轮都要这样。那时候我偷懒，就在原有的基础上将错就错加了这个功能。结果后来策划又要我加一个关卡，这个关卡跟之前的几个关卡完全不一样，导致灰太狼那个走进来扔鱼鸟的过程再也无法在之上打“补丁”进行修改，导致我之前写的很多代码都得重新删除开始重写。从这个事例一是可以看出我的编程能力不够，还有一个很重要的就是编程的过程中一定不要将错就错，也许你的将错就错，导致你要花更多的时间来纠正这个错误。出来混，迟早是要还的。这编程能力的不足还体现我接的第二个游戏上，第二个游戏是我主动选的。因为那时候自认为学了一点点C++，就接了那个《彩色泡泡》游戏。那个游戏比我第一个游戏难度大了不少，导致自己修改之前看了四五天才基本看懂，后来这个游戏的修改也花了我很长时间。不过我还是觉得挺好的，虽然难度大了一点，但我间接地复习了一下C++方面的知识。从这方面来说，还是挺不错的。
第二，就是不要盲目的迷信比我们经验丰富的程序员。这主要体现在《彩色泡泡》这个游戏上。由于刚开始对于《彩色泡泡》确实没怎么看懂，所以我改代码的时候改的小心翼翼举步维艰。而且刚开始的时候总是有很多莫名其妙的BUG，比如彩色泡泡发射出去跟已在屏幕的泡泡重叠，发射出去的泡泡悬空，进行一次消除已有有些该掉落的泡泡没有掉落……等等。刚开始的时候，我理所当然的认为给我这个游戏之前这算法就一定是对的。所以从来没想过要去修改算法。其次也是自己的惰性使得自己不愿意去改算法，因为改算法要去了解算法，总之就是怕麻烦。不过，后来随着我逐渐对整个泡泡算法的理解，发现发现如果不改算法很多的必须要解决的BUG都无法解决，于是我就开始仔细研究算法。到后来确实发现几个主要的算法，比如泡泡的定位，泡泡的掉落算法都出了一点小小的问题。我把那些算法进行修正或重写，结果就是那些莫名其妙的BUG果然再没有重现过。由此可见，以后不管是经验丰富的程序员的代码也好，还是像我这样的菜鸟的代码也罢，都要对代码中的算法逻辑等等，要进行大胆怀疑，小心求证！
第三、沟通不到位。主要体现在《狼堡大解救》这个游戏之上。最大沟通失误就是上面提到的，灰太狼走进来扔鱼/鸟的过程。这个导致后期改动很大。还有很多一些细的规则，也许我理解的是这样，而策划理解的却是那样。以后一定要铭记这个教训，一定不要急于去写代码，在写代码之前一定要把每个小细节都跟策划沟通好。想想也是，连需求都没弄清楚，又怎么能写代码呢？
当然，自己出现了很多问题，但整个项目的过程中，我觉得每个人都在存在不完美的地方。（先申明一下，对事不对人），美术方面主要体现在出图有所延误，导致把时间压力转移到了我们程序员身上。还有就是策划，策划方面的功能有时候改来改去，甚至有些功能临时性加的，导致考虑不周到程序测试的时候才发现规则有所不合理。还有就是第一轮修改跟前期做的demo，美术基本要全部重新出一遍图，我们程序要实现的功能有比较大的改动。后期甚至加新的关卡使得程序需要修改很大。这个过程个人感觉做了很多的无用功。这些问题，我想能不能前期策划游戏的时候策划，程序员，美术，还有测试员都一起进行讨论，把游戏定下来的时候就不要反复去修改。还有就是，策划参考游戏的时候有时候参考的游戏过多，想把每个游戏觉得好的都搬进来，结果有些就起了冲突。所以，我觉得还是要以一个游戏为蓝本为好，不要参考过多的游戏。
不管怎样，觉得自己还是有进步的，按照项目的进度完成了游戏。要尤其感谢的是测试员，为我们程序员的游戏的完美付出了巨大的贡献。虽然有很多BUG觉得很搞笑，有些BUG觉得不需要改，甚至有些BUG根本不是BUG……但还是要感谢他们。每个人都不是完美的，我会记住我在这个英语项目中所犯的错误。因为，逻辑项目即将开始！！！！！！