标签：team http 第三方 lock ubi == java 项目配置 nim
这里主要是想记录一下自己的想法，以及一些设计思想，然后在实际开发过程中，是否会遇到一些自己所想不到的事情，以及怎么的解决过程。事实上，写这种文章，远比写技术性的文章难多了，个人感觉还很难写好。这里写也仅是自己的观点，一种想法和思考，不代表完全正确，共勉而已。
两款ARPG游戏，一款相对简单一些，偏挂机的ARPG游戏，另外一款是比较类似传统的ARPG页游。跟传统的项目换皮再上线还是有比较的的区别的。
1. 确定战斗系统的机制是一致的，其他细节的功能会有所区别
2. 已有AS3的回合制以及ARPG项目和相关开发经验
3. 多页游积累的相关工具以及流程
4. H5的arpg demo已经实现了基本的角色、地图和基础简单的战斗系统（前期做的技术预研）
5. 几乎要重新开发全部客户端Html5的代码（基于TypeScript，但可移植部分之前AS3代码）
6. 服务端相对好点，上个页游也是用Java写的，所以服务端可以进行比较好的迁移。
由于几乎是同时开发两个类似项目，又没有一个比较接近项目进行换皮。再者项目开发进度也紧，人力也有限。为了最大限度提高开发项目效率，节省资源。对两个项目进行整合，尽量复用代码，最好也最快的解决方案。下面是一些考虑执行的方案。
最基础的，和具体的业务逻辑没有关系的代码和设计放到这里，不用考虑和纠结的。基础也大量移植原有AS3的代码，在稳定性和实用性都有一定的保障。
非代码类
1. 保持代码结构一致（代码包名等等）
2. 保持游戏资源目录结构一致（ui、场景、角色、物品等等）
3. 保持动画格式、ui编辑、动作编辑器等工具保持一致
4. 保持各种目录结构、ftp、持续集成服务器一致
5. 其他开发流程，相关规则保持一致
6. 项目配置、编译参数、编译工具(Egret Wing IntelliJ IDEA)
7. 通讯协议、策划数据尽量采取类似或者通用的方案
具体的版本管理图:
代码库
1. 自研基础代码库（通用类、工具类、mvc框架类……）主要移植和编写基础代码，跟具体的游戏类型没有关系的通用逻辑代码。
2. 第三方代码库（Json，MsgPack等等……）
3. 游戏引擎包（场景、地图、角色体系……）这里算是指定是开发游戏用的，但是这里还是根据可以做到不跟具体游戏类型。保留通用的游戏机制的代码库。
4. 战斗系统。战斗系统是引用前面3条的代码库，这里做得只能是arpg的战斗系统。这里会处理两个项目通用的战斗逻辑。以及面向接口开发，部分具体的实现是在不同的项目里开发的。
项目代码设计
1. 通过基础库和core库的分离设计，项目集中在写自己的项目，core库不能引用具体的项目代码
2. UI布局和逻辑分开。每个项目UI布局肯定不一样，但是部分逻辑是通用的，所以重点是这方面的设计。提取出公共的UI接口，然后项目分别实现。根据项目类型来不处理某些接口（单个项目独有），如图：
会有专门存放接口的包名(其实应该放在core里，然后实现类放在具体的项目)，UI结构示意图
UI的接口和实现
另外一种情况，就是UI功能变化比较大的时候如何处理呢？假如有一半一样一半不一样
这里可以采用共享LoginView基类了，在这里处理公共逻辑，具体的子类处理不同的UI逻辑。如果要更多的
重用，就得把基类的粒度做得更加细一些，当然做太多其实反而是浪费精力，应该根据项目具体的情况来决定使用什么的设计技术。
3. 功能模块之间采用事件派发，这样只需要处理事件，不具体处理项目，可以做到逻辑共享了。 这里分几种事件机制：core事件、cmd事件、mvc事件，项目独有事件。做了细致的分离，根据不同的功能使用不同的事件，提高开发和运行效率。
非技术方面
1. 两个项目都会指定负责人，希望项目进度和管理能够及时跟进
2. 两个项目的开发人员会交叉开发，类似和相同的功能模块，尽量同一个人开发，节省人力资源
比如背包、登录、创角、聊天等一些功能。
3. core库只能有1，2个人才能维护，其他人只有使用权，没有修改和提交权。不同项目还会开分支，同步到主干之后，还需要两边项目都调通。
4. 策划层会也会尽量沟通，除去玩法之外的一些功能模块，也会互相探讨，尽量做到至少是在数据结构上可以保持一致。比如技能、地图、角色设置等一些通用的设置
刚开始基本上是按照前面的设计来进行的。挂机类aprg（见现在到处跑的传奇世界H5类型）先进行开发了半个月，所以这半个月首先是开发一些最基础和最通用的功能，同时也是完善角色场景以及战斗体系。
先做基础功能主要也是为了第二个项目也能够使用这些开发好的模块。
半月后同时进行第二个项目，刚开始其实还是蛮顺利，大部分也按照开始的设计来进行。只是后来因为项目原因，工作量也大，开始出现了一些问题了。比如因为项目赶，有部分功能没考虑设计，使用了简单粗暴的移植法。虽然快速做好了，但是有bug的时候，就必须在两个之间进行修复了。
另外就是core库的战斗系统设计得不够严谨，会修改得比较多，一不小心就会造成另外的项目跑不起来了。
所以在一些系统稳定前，总会踩下这些坑，得小心翼翼了。
人员的不足，不是每个模块都能按照之前设计那样，两个类似的模块同一个人维护，所以有时难免要维护或者移植别人开发的模块。
后面也是有陆续根据项目的具体情况调整一些方案，以及陆续补充core库的代码。
其实这blog的内容一个多月前就开始了，结果直到现在才算是勉强写好。双开的结果就是连写blog的时间都没有，一天至少是当1天半来使用，写这个文章的热情也淡下来了。好在之前也写得差不多了，现在也没做太大的修改，有些设计和想法还是挺好的，在实践中也得到验证。总体有这种想法和设计，对于团队后面的工作展开还是有很大帮助的。
最后团队这种高压下，进步也是挺大的。同时也看到了团队强大的应变能力以及开发能力。
双开的很多的，发现真的很难用一些言语来描述，跟换皮做项目是两回事。不过总体还算顺利，虽然有些坑，不过也后续中慢慢填补上来，尤其是招到了足够的人手后，很多问题都得以解决了。
标签：team http 第三方 lock ubi == java 项目配置 nim
原文地址：http://blog.csdn.net/sujun10/article/details/71104020
