简单工作总结

来源:互联网 发布:网络经典歌曲500首 编辑:程序博客网 时间:2024/05/02 02:28
 

进入网游行业已半年, 最近按公司要求做一个涉及多个服务器同步的帮派副本, 发现一些新东西,所以作个简单总结下:


本人建立帮派副本的流程:
1, 单机版副本的功能编码。
2, 将单机版副本功能封装成指令类。
3, 将副本的指令类封装成“逻代布局”的网络结构。
4, 精减网络同步数据,修改指令类里的数据结构,将必要的同步数据提炼出来做为独立模块(常量数据,非常量但可以不网络同步数据为另一模块)。

总结:
1,先做单机版功能编码,再转成指令。阶段性开发比较清晰。

2,在把功能封装指令类时, 本人采用了状态模式,将每个指令的发送和接收绑定在一个状态里,降低了逻辑复杂度和提高了可读性。 其中指令ID的编码采用宏进行自动累加。

3,设计“逻代布局”的“逻代类”,让逻辑服和代理服的对外接口统一(只提供唯一的send(_CMD_ID,_PAR)接口),由于内在逻辑去解决区别。通过组合机制让“逻代类+副本类”可以组合出逻代布局的副本类。


4,从应用逻辑角度看,属于一致的数据类型;从优化逻辑角度看, 可能属于不一致的数据类型,这个发现从"以前的知道这么回事"到现在的"重视",应该是本人网游设计意识来说是一个历程碑。事实上这已有不少应用,例如将数据划分出数据库数据,网络数据。 但一直没有怎么去重视。有时间应该好好思考一下怎么解决这两种角度分法的过渡。

 

关键的发现点:

1, 逻辑服和代理服的网络布局。

2, 从应用逻辑角度看,属于一致的数据类型;从优化逻辑角度看, 可能属于不一致的数据类型。

 

回头一看, 本次副本代码实际写得很不理想。 有些接口做到后面之后才发现在分服的情况下是用不了的(例如向玩家发送处理结果的消息,例如取得玩家的帮会ID,异地服务器是无法依据玩家的ID获得这些信息的, 因为进程都不是同一个了), 导致需要修改的接口和实现,把一些只能在当地服务器做出结果的东西先做出来后再传到逻辑服去处理。 这种修改打碎了整个设计的连贯性。 无知是一种错。

 

原创粉丝点击