从我知道有编程这回事以来，就把编程作为理想职业了，可惜我直到大二才知道有这回事。而且由于悟性不高见识不够，在成为一名真正意义上的程序员的路上走了不少弯路。直到我进入游戏行业之后，才找到了作为一个程序员的感觉。其实真正的程序员都是希望开发系统软件的，操作系统、编译器、数据库之类，不过游戏作为一种软件算是离系统开发最近的一种商业软件了，而游戏引擎也算是一种系统软件。入行晚就要多接触多理解才能赶得上大家的节奏啊，我一年内换了三个工作，来到现在这家公司的原因是想参与一个从头开发的项目。不得不说工作和生活还是息息相关的，工资低、离家远、项目对自己没帮助，都有可能让人无法忍受。

　　下面进入正题，我做的是手游服务器开发，目前手游服务器的特点是：短连接、高并发、轻逻辑。和网站服务器的要求非常一致，以至于大家都用网站服务器稍微改装一下就搞起了。我们的server底层用的是端游改装的，简单的ping-pong测试也能达到1w的并发(系统功能开发前的测试)，不过一旦加上系统功能逻辑，连2k的并发都达不到。所以这样的底层只能作为开发版本，过完年必须换血。现在有很多基于Nginx的网络服务器框架，应该是非常适合手游项目的。这个我也决定不了，暂且不提。

　　我是做逻辑开发的，慢慢来吧。幸好手游项目小，逻辑简单周期短，我大概做了15个系统功能，而且具体实现比较符合我对程序的理解。为了纪念这个愉快的过程，我把整个项目开发的过程概括一下吧。

　　项目开工之前的准备工作：

　　1.招人。整个项目周期内普通的团队都要经历人员流动的问题，项目负责人的性格和领导能力决定了团队的氛围。所以公司老大要先搞定项目制作人和程序主管这俩职位，然后是主策划，前后端主程，我们团队的配置就是以这5人为核心的。所以公司给他们分配的资源也最多，毕竟这个项目缺了其他人就如同少了个工具，缺了这几个人就像缺了胳膊腿一样。所以没办法大家还是努力成为骨干吧，7分技术3分运气，毕竟游戏行业还算是科技领域，技术水平业务水平还是硬道理。

　　2.游戏定位。一个项目总得有个吸引人的地方才有吸金能力，我们这个项目有个天然优势就是ip很火。但是光有一个好ip没用，这个ip以前也做过页游和手游，都石沉大海了，不知道是运营问题还是作品差。最终项目制作人确定的玩法是“第一人称射击类手游”，融合卡牌游戏和rpg的元素，说白了就是主角带着小伙伴打僵尸的游戏。

　　3.策划总纲。这个就是考验制作人的经验和创新能力了，手游不能做得太大，也不能太普通，要结合ip的特点进行取舍和创新。策划总纲里面指定了游戏要完成的基本功能和基本效果，还有收费原则（坑要多要深，兼顾平衡）、吸引留存的方式（简化注册登录，所有功能设计没有理解成本但要有创新）、付费方式（简化付费流程，多种vip等级）等。

　　4.项目工期。这个是程序主管的工作，根据工作量确定需要多少人，工期进度计划，对有经验的程序来说问题不大。这个阶段要把前后端选用的技术方案大致定下来，比如前端unity3d，后端C++ lua这种典型方案。然后是人员配置前端6~8人，后端3~4人，对于手游项目已经比较豪华了（看水平。。）

　　基本人员到齐，项目工期已定，进入项目的前期Demo阶段：

　　1.招人。还是得扩充军备，人齐了才能尽快进入稳定期。

　　2.运营宣传。这年头都是兵马未动，声势先传出去，给人宣传个一年半载的才看到庐山真面目。抢眼球的时代。

　　3.策划分解。根据总纲分解出系统策划、数值策划、关卡策划的工作范围，然后出一个策划案demo版本。

　　4.程序框架。前后端都要制定技术框架，前端unity3d比较薄弱，需要先解决技术问题才能出方案。后端比较成熟，只不过需要敲定用哪些技术，结合运营部署的要求给出部署服务器方案、开服合服方案、统一管理接口。这里必须吐槽的有两点：一是前后端开发分离，这会导致前后端开发不同步问题、前后端对接问题、不同人的对接方式不一致问题，可谓是万恶之源，极大的拖慢开发进度。但也没办法，前端的程序不会C++，后端的lua接口又没接上；后端的程序不懂unity，本身前端就有没解决的技术问题；导致开始的时候没法按功能把前后端工作都分给一个人，只能两边配合，说白了还是码农水平的问题。二是server跨平台，在我看来，除了通信协议和语言标准是平台无关的，其他的东西都是平台相关的，POSIX不过是一厢情愿。跨平台不是一件简单的事情，但是人们都有这样的愿望，所以除非我们已经有了跨平台的支撑框架（比如QT对于GUI）否则千万别自讨苦吃。windows和linux版本的程序写的越好就越没有相似性，其实他妈本来就是两套代码。至于为啥我们选择跨平台捏，说出来让人很无语，linux适合做server（免费+稳定），但是程序员不会在linux下开发，尼玛还是码农水平的问题。我能说在linux下开发其实比在vs下更有效率吗，vs除了complate和reflact是优势，其他方面和linux比(工具链方面)甚至稍逊一点。关键的问题在于程序运行机制的问题，linux下是统一的思路：server程序做成Deamon进程（windows下一般不做成服务进程，可能是不好管理），输出日志可以用tail实时查看（windows下要打印到屏幕上一份），shell启动和停止脚本完美配合（windows下可以用脚本启动停止，但是没法传递消息给程序，只能在cmd上Ctrl+C让程序捕获），程序宕机自动dump（windows下需要借助SEH的特殊处理方式产生dump文件），等等问题吧。

　　5.流程和规范。

工作流程有：

　　　　每周总结会、每周周报、每天站立会

　　　　svn权限分配

　　　　从策划草案-定案-程序执行-策划验收-测试版本-测试验收的整个流程

　　　　每个人的任务分配方式，任务时间评估

　　　　测试bug管理流程

制定规范：

　　　　策划文档、程序文档、美术文档、测试文档等的命名规范和格式模版

　　　　前端代码规范

　　　　后端代码规范，这个是我出的，基本和google的C++规范差不多，做了点扩展，然后定了一套我觉得好的命名方案。我觉得比较成功的一点就是规定了代码注释必须用中文，说实话能用中文写明白注释的人都不多。

　　7.服务器压力测试。首先要有一个可用的服务器底层，这个底层上面也说了，是从一个端游抽出来的，仅保留网络连接和数据库连接两个功能。然后要做一个压力测试机器人，这个是我做的，第一版的机器人是单机模拟一组机器人并发。因为要有界面反馈，我选用C#的wpf做的UI，确实很强大。第二版的机器人就牛逼了，我做了一个控制中心连接所有的机器人客户端，然后统一下发配置和启动测试。目前已经是第三版，可以用真实的客户端服务器交互信息，在server端录制交互报文（这应该在client端录制，可惜前后端是分离的，我改不了前端的代码），然后作为机器人的测试脚本做压测。有了机器人，我把服务器的登录部分第一版完成（基础逻辑就是玩家登录的时候发送一个设备id到gateserver，如果已经缓存此设备id就返回对应的guid给客户端，表示已经登录。否则去db查找设备id对应的guid，如果找不到就创建一个guid绑定设备id，存入db；找到则通知gameserver从db查找玩家数据初始化，初始化完成后通知gate，再通知client）。

　　8.前后端对接。前后端都会完成几个基本系统功能，比如主角系统、武器系统、副本系统，通过这几个系统，实现系统功能和关卡玩法对接，前端表现和后端逻辑对接。对接成功之后算是基本的技术开发流程走通。然后是打包发布apk和ios版本测试，于是乎Demo完成。

　　OK，经过第一个Demo版本，团队配合也差不多磨合出来了，进入铺量开发期：

　　上个阶段因为处于磨合期，很多流程规范是逐步建立的，会留下很多问题。这个阶段会把所有的系统从新设计一遍，按照流程逐个开发，直到完成一个各方面符合预期的版本。这个时候前后端开发是并行的，前端系统开发和关卡开发是并行的。这个周期比较关键，前后端都要出来一个逻辑上的框架统一管理所有模块。前端需要管理场景、预设、美术资源、声音、逻辑模块划分、怪物ai状态机等等。后端需要管理client-gate-game通信模型、日志输出、数据库操作封装、玩家管理（登录、踢出、封号、解封）、配置文件管理、逻辑模块划分、公共数据管理、时间管理（定时器和计时器）等等吧。解决完这些问题之后，整个开发过程就顺畅了许多。不过这个时候前后端配合开发的问题就暴露出来了，不同的人对前后端的分工见解不一致，最终导致了最后开发高级功能的时候各种接口不一致。以此为鉴吧大家，要想前后端配和开发，必须有很强的预见性，对通信协议和逻辑划分都全面考量。对推脱责任消极怠工的员工陷害踢出（招人的时候干嘛了）。

　　说说这个阶段的完成的功能模块，登录-武器-副本-伙伴-主角-任务-背包-签到-竞技场-排行榜-图鉴-成就-vip-队伍-商店-装备-解密-佣兵团-GM-招募-修炼-信息提示-新手引导。。大概这些，可能有忘了的，不过没关系，做系统功能的特点是，做10个和做20个差不多。有时候好几个功能一块做，都分不清谁是谁了。我觉得只要把系统功能背后的支撑框架做出来，或者找到一个适合表达的模型出来，剩下的就是往上面一套。说白了就是机制和策略分离的原则，系统功能会不断添加，所以必须把新功能向目前的功能系统框架下正交分解，如果没法分解，就增强系统框架。

　　铺量开发的后期是出问题的阶段，因为开发模式的问题，前后端很多逻辑层次的划分不同导致了开发综合功能的时候不能统一处理。前端尤其严重，比如前端的数据同步，A系统使用了B系统的数据，而B系统可能没有从服务器同步数据，这时候A怎么办？向server请求B的数据显然不对；在A系统加载之前加载B系统会导致登录的时候要加载大部分的系统；登录的时候分步请求所有系统的数据会导致登录延迟或者server承载过大。目前的解决方案就是第二种，不过我觉得还是第三种好点，只需要前端把登录分两步，一步是loading核心数据，第二步是弹出公告信息和玩家登录后的收益什么的，先进界面再说。整个过程实际上还是在后台加载数据（好像是windowsxp的作风）。再吐槽一个例子，A系统调用了B系统的功能，B系统界面关闭之后，A系统不知道B系统干了什么。这是因为每个系统单独开发的时候，都是依赖后台通知的，前端系统互相之间没有建立数据接口，导致这种简单的增加一个数据接口或者回调接口就完成通知的事情，变成了问题。这就是前后端开发没有逻辑上划分清楚，导致前端只管表现，后端只管奶妈的情况。

　　暂时写到这里吧。项目还没开发完，和平台对接的大战还没开启，估计又是各种扯皮的问题了。

进入游戏行业1年的总结