这是最后一part，也是个人觉得相对较复杂的地方——联机
我这边最后的目的是实现互联网上联机玩游戏，具体原理如下：
服务端：
1.使用带有公网ip的云服务器（这里白嫖了阿里云）作为服务端，云服务器不断运行我提前写好的服务端程序，监听本地指定端口的TCP请求。
2.如果听到了来自客户端的TCP请求，则保留此socket套接字，并为其创建一个线程，线程内运行的是游戏的主程序。而服务端则继续监听来自其他主机的TCP连接请求，继续创建新的线程。
3.当有两个客户端请求主机连接时，服务器会正式启动游戏运行的工作，根据客户端不断通过已建立好的TCP连接发来的按键反馈，更新游戏状态，对游戏中的每一个动画的位置、名称、图像等创建其独有的序号，形成一帧数据包，发送给两个客户端。
客户端拿到这帧数据包可以完整绘制服务端那里的游戏状态，以保证两个客户端看到的画面是与服务端一模一样的，数据帧内容附在文末。客户端可以通过数据包每四位中的第一位确定后面三个是关于哪个游戏内容的数据，他的坐标、图像等的具体值为多少…
4.退出机制（心跳包机制）。当没有收到客户端发来的心跳包后30s，关闭客户端连接。
客户端：
1.每个用户运行提前写好的客户端程序。客户端程序的第一步就是通过公网ip与云服务建立连接。
2.成功建立连接后，开启两个线程，一个不断接收来自服务端数据的线程，一个进行游戏的正常运行。二者通过全局变量交互来自服务端的数据。
3.当客户端用户按下按键时，会形成特定的数据包，发送给服务端，服务端根据不同的用户反馈，提供不同的游戏画面（也是主要的人机交互部分）
4.客户端根据收到的服务端的内容，查找提前约定好的数据帧表，在屏幕上不停绘制收到的游戏画面。
联机功能及游戏展示：
尾声
总的来说，从周四到周日的这四天，在原来写的部分脚本的基础上，完全仿照了造梦西游的模式，截取了游戏的贴图，并复刻了游戏的玩法，同时还实现了联机功能！
四天的收获很大，我想也是我真正意义上的把游戏从建文件夹到上线的整个流程自己过了一遍，是从玩游戏的到做游戏的一个“小小”的身份转变。此外，感谢我的小伙伴们提出的对于游戏建议，没有他们想要联机的建议我可能中途就不想做了！
未来有机会会继续做相关内容，但这四天写的有点high了，还得宠幸宠幸科研！欢迎大家提出意见！
数据帧内容
位置1 分隔符 位置2 分隔符 位置3 分隔符 位置4
1（猴子） | 坐标x | 坐标y | 图像
2（云梯） | 坐标x | 坐标y | ——
3（路1 ） | 坐标x | 坐标y | ——
4（路2 ） | 坐标x | 坐标y | ——
5（怪物1） | 坐标x | 坐标y | 图像
6（怪物2） | 坐标x | 坐标y | 图像
7（怪物3） | 坐标x | 坐标y | 图像
8（怪物4） | 坐标x | 坐标y | 图像
9（石头1） | 坐标x | 坐标y | 图像
10（石头2） | 坐标x | 坐标y | 图像
11（石头3） | 坐标x | 坐标y | 图像
12（石头4） | 坐标x | 坐标y | 图像
13（boss） | 坐标x | 坐标y | 图像
14（箭1） | 坐标x | 坐标y | 图像
15（箭2） | 坐标x | 坐标y | 图像
16（箭3） | 坐标x | 坐标y | 图像
17（箭4） | 坐标x | 坐标y | 图像
18（光波1） | 坐标x | 坐标y | ——
19（光波2） | 坐标x | 坐标y | ——
20（光波3） | 坐标x | 坐标y | ——
21（光波4） | 坐标x | 坐标y | ——
22（光波5） | 坐标x | 坐标y | ——
23（伤害提示） | 坐标x | 坐标y | ——
24（游戏结束） | 坐标x | 坐标y | 图像
25（开始） | —— | —— | ——
26（主角1血条） | 血量 | —— | ——
27（怪物1血条） | 血量 | —— | ——
28（怪物2血条） | 血量 | —— | ——
29（怪物3血条） | 血量 | —— | ——
30（怪物4血条） | 血量 | —— | ——
31（boss血条） | 血量 | —— | ——
32（主角2血条） | 血量 | —— | ——
