目前在做其他项目,之前维护接近一个月的逻辑工程,觉得写点什么才能对的起这段时光。当然来说,我也觉得做的不够好。既有经验的问题,也有在思考需求的不明确。在时间紧迫情况下,会有动作变形。
一.接手前的状况
客户端主要逻辑逻辑是使用C#写,但是逻辑工程是把客户端中抽出了一些逻辑部分的内容,2月份才开始做了第一版本。当时已经到4月低的版本,中间更新能编译成功,但不清楚是否有效。
我接手的时候已经到6月初了。当时7月给腾讯的版本中,有一项内容是战后做逻辑验证。逻辑工程要保持更新到最新,要在服务端可以启用。
客户端在开发功能的同时,也有人整理代码和同步加载改成异步加载的加载优化,涉及代码变更很大,有点不知道从何处下手。 客户端在启动更新等等,加入整个游戏状态机。
其次一些配置文件的读取,因修改两边需要不同的代码来管理了。
二.遇到的问题
无从下手的我,只想到把代码更新到最新。中间2个月一直有新的功能开发,一直有更新代码。情况就是一个人
要去整合处理十多人的提交,有点晕。
配置和代码虽然是通过批处理拷贝过来的,但是并没有被正确调用。脱离unity工程的DLL工程,看对应的报错很不方便。只能有try Catch捕捉。
前期一个能编译的成功的版本都不行,中间涉及改动,一直以最新客户端版本为准。通过看代码和缺少报错,把一些新的内容和缺少内容加入。运行过程中是一直报错的。看下来是配置有问题。
重新梳理,把客户端版本的状态机机制看懂,并加入到逻辑工程中。配置更新到最新。对应读取方式做了区分。但还是不行。
深入去看每一个配置内容,有5个在战斗加载前要读取的配置,在考虑中间的时候,有人在调整相关配置的路径,配置读取方式有同步改成异步读取,可是整个逻辑工程只支持同步。
三.调整
1.老大给的版本思路,定到某个一个提交版本。客户端和逻辑工程同一个版本进行对比Log。
2.在另外一个同事加入后,在客户端代码里加入逻辑工程的宏,通过bat同步后不用在手工修改了。
3.配合的服务器调整打印的log格式。
4.梳理整个战斗流程,和之前版本的相比,一些配置的加载顺序有修改。
5.单例初始化时机的问题,逻辑工程不同,有些单例初始化时机不同。
四.总结
1.从整个需求上并没有定位清楚,这个逻辑工程的目的,我收到需求是能编译成功就行。而从版本计划上来说,要在测试版本中做战斗验证。
2.从经验来说,之前没写过C++工程的,对于dll有点陌生
3.一个人针对很多人提交,没做过版本合并的经验,需要定一个svn提交记录并进行更新。
4.从维护逻辑工程,确实帧同步查找问题,就打log,看调用栈。长时间看有点考验耐心
5.做log对比,最好的方式是让两边的打印方式同步。我有点懵,并没有要求服务器配合,而是自己看着打印日记查了几天,老大介入后,服务器做了相关的配合
6.正因为缺少相关的经验,客户端要在对应的cs,要加对应的逻辑工程宏。我想着不污染客户端代码,自己去修改。
7.逻辑工程确实查出了一些问题,很有意思
* 排序问题,两个变量,对某个属性的数值相同,没有加入第二条件做排序辅助,客户端和逻辑工程排序结果不同。这个问题比较难复现。只有一些特殊条件下才能触发。
* 随机种子的调用数量不一致,这是看打印日记很容易看出来得,在执行上有用到随机种子的地方没屏蔽干净。随机轰炸,客户端表现屏蔽,但是调用随机种子的逻辑没处理
* MainRole概念,在很多游戏中都主端处理和非本端处理。当一些地方为null,会强制把MainRole的数据放进去。逻辑工程不作为一个主端,MainRole是没有数据的。这种执行肯定会出错。逻辑工程dll是把各个端数据拿来验证。一个房间24个人,逻辑工程就第25个。但是实际处理中,他不参与房间里任何数据处理。
* 先理顺整个处理流程,才开始动手才是关键,接手的时候,并没有注意到客户端和逻辑工程在流程上修改了,花了很多冤枉的时间。
8.非常谢谢对应的服务器开发高韩写了逻辑验证的dll,用帧数据流在查找dll的问题。在查找问题的时候更方便多了。
9.对帧同步开发理解更深了,正是有了这样的机会。
10.如果时间可以的话,在逻辑工程还是先做成dll给客户端调用,毕竟那才是正确的执行步骤。