网络通信
在项目最开始阶段主要需要考虑的还有网络通信模块，当然如果你做的是单机游戏就可以跳过这部分了。
这里主要讲长短连接的选择，这个也是根据游戏项目来选择的。长连接和短链接分别也有不同的处理。这里说一下其实如果没有玩法上的限制，能用短链接来实现就尽量用短链接来实现，因为短链接无论是对服务器还是对客户端，短连接对消息的处理会简单很多，而且最重要的是占用的系统资源相对于长连接来说非常少。这里所说的系统资源占用少就是，无论是客户端还是服务器都不用长时间维护连接状态。而且假如一个逻辑服务器长连接时可以同时保持4000个连接，也就是支持4000人同时在线，但是如果改成短链接的话，这个逻辑服务器可能会支持10000+人同时在线，当然，前提是不影响游戏功能的情况下。
下面先来说说短链接。一般我们说短链接大都是指http请求，当然有时我们也用socket来模拟短连接，这个我后面再详细说明。很多游戏与服务器数据交互比较简单，像一些偏单机玩法的弱联网游戏，一般指向服务器上传和请求很少的数据，比如积分、排名等信息。这时一般我们就直接用http请求来做就可以了，也不用做任何的数据封装和处理，简单粗暴也高效。但有时游戏会复杂一些，比如一些社交游戏(Social Game)，它就没必要使用长连接，短链接完全可以满足游戏需求，还可以最大化利用服务器资源，但是如果还采用刚刚那种简单粗暴的方式，直接用http请求，不做任何封装的话，开发时就会力不从心了，因为这类游戏中数据交互较多，人力维护成本较高，也容易出错。这时我们一般都会对http进行一个简单的封装，例如为每个消息增加一个唯一ID，同时会有一个对应的配置，告诉程序怎么解析这个请求，也就是这个请求里有哪些数据可以Get到，按照这个逻辑可以封装一套不需要逻辑层来维护的网络协议层，再把这些工具话，就不会再数据传输和解析上出错，并且也能提高开发效率。
接着我们再说长连接。通俗的说长连接就是与服务器长时间的保持连接。保持连接的一个好处就是，不需要客户端主动的发起请求，服务器就可以随时的推送数据给客户端。短连接中我们采用轮询这种机制来，让服务器可以在一定的心跳时间内向客户端推送数据。但是在交换性较强，并且需要实时性的游戏中这种方式就不太好用，并且浪费了，这时我们就会采用长连接，保持连接不断开，服务器可以随时快速的推送数据给客户端。一些游戏类型必需采用长连接才能实现所要的玩法，比如FPS、MOBA这类游戏，还有大部分需要联网对战的游戏，都需要长连接来支撑玩法。在长连接中，还分为基于TCP和UDP的两种协议，更复杂的还有TCP和UDP混合使用的设计，这里我们不详细讨论，后面有时间我会单独讨论这个知识点。这里有一片文章介绍TCP和UDP怎么选择和设计的比较不错，大家可以参考一下：UDP vs. TCP
我们再说一下上文提到的用socket来模拟短连接这点。第二点在介绍短连接时我们了解到短连接可以实现大部分游戏需求，而且能用短连接尽量采用短连接，这样可以节省服务器资源。但是有很多游戏虽然可以采用短连接，可是他的数据请求比较频繁，这时使用http请求的弊端就显露出来了，由于http的特性（HTTP数据包头解析）导致相同的数据http的数据包总要比socket大很多，所以频繁发送http请求就会很消耗流量资源，以及响应速度也稍慢(当然这点可以忽略不计)。这里就会用socket来模拟短连接来解决这个问题。由于http包头信息较多，导致数据量大，所以我们可以用soket来自定义自己的数据格式，来减少包头信息，自定义可以让包头足够的小，然后用socket来创建连接-发送数据-接收数据-关闭连接，就完成了一次请求。
最后还有一种设计方式是短连接和长连接组合使用。有些游戏类型游戏会分为两种状态，比如一些棋牌游戏，在大厅时交互很弱，强交互都在房间内产生，这时候就适合短连接和长连接组合使用这种设计了。因为这种游戏一般服务器结构都分为大厅服务器和房间服务器，在大厅服务器时交互较弱，就适合使用短连接来实现，这样可以充分的利用服务器资源，让大厅服务器可以承载更多玩家在线。而连接到房间服务器时就可以保持连接不断开，采用长连接，以更好的服务玩法和带来更好的游戏体验。
总之无论怎样设计，都是用来服务游戏本身的，所以考量设计时一定要从游戏本身来考虑和设计。这里还有一篇文章也不错，分享给大家看看：手游开发中网络通信使用长连接还是短连接比较好?
