Unity框架

尝试实现自己的游戏服务器框架(客户端基础构架)

Spread the love

最早写游戏服务器与客户端的时候并不是很理解服务器整体的结构,并且对游戏功能的实现也操之过急了,导致代码完全无法复用,于是打算实现一套自己的游戏服务器框架。
不过我对服务端编写还是处于学习尝试的阶段。
写下此文仅仅是为了记录一下编写的过程。
服务端的Netty部分我已经重复写了不下三次,可惜一直保留着第一次写的痕迹,也有很重的公司的代码的痕迹,于是打算推倒重来,从Socket开始重新实现。
今天大概封装了一下客户端的基础构架部分,不涉及到具体的例如登陆、心跳等等环节,基本思路还是想尽量先把基础的通信层搞得更通用一些。
基本思路是通过上下文的形式将接受器、解析器、处理消息的门面类抽出来,方便开发者随时替换。

首先,我把Socket进行封装,成为TCPClient和UDPClient,将连接中的细节进行了隐藏,例如:大小端之类的代码,全部都不向开发者展示。

然后注入接收器IReciver,将拆包逻辑进行抽出,帮助开发者进行替换。

然后将Client封装为GameClient,不同的游戏中或许数据结构都会变得不一样,所以我定义了IGameClient,定义了发送和接受消息时接受的数据结构。

在GameClient之下又有几种不同传输格式的封装:Json或者Protobuf。例如在一些数据量较小的服务器上我们可以使用Json进行处理,处理较为方便,而数据量较大的服务器上用Protobuf进行处理,效率较高。

最后,我们会针对不同的服务器注入不同的消息处理器,也就是接受消息的门面。
我提供了一个IMessageHander的接口,类中的每一个带有HandleById特性的函数都会处理特定Id的消息。

总体的样子就是这样,我们可以看到,我们将接收消息的拆包方式、解析格式的方式、处理消息的方式单独抽出,开发者就不需要关心别的细节而只需要实现对应的接口并且注册到上下文就可以完成服务器的编写。
这种做法其实蛮像Netty的Pipeline的,不过我写的时候也没有想这么多,单纯只是想把关键逻辑抽出而已,明天再优化优化代码吧。

 

 

我其实蛮想做成链式结构的,不过不同数据类型的input和output还不是很清楚怎么连起来。明天再试试吧

发表评论

电子邮件地址不会被公开。 必填项已用*标注