游戏的类型
MMO：魔兽世界【多人群战，服务器计算，精度要求不高】 FPS/TPS：吃鸡【网络要求高，精度要求高】 MOBA：王者荣耀【小规模，网络要求高】
网络选型
TCP：弱网下表现很差 KCP：可靠dup，带宽和开销大，额外带宽换取低延迟【王者，原神等用】
联机的方案
client-server p2p
联机一致性
玩家角度：不同设备上，游戏世界发生相同的事情 技术角度：相同的输入，相同的模拟过程，相同的结果
Lock Step流程
1.客户端采集玩家输入操作发送给服务器 2.服务器收集所有玩家操作，发送所有收集的输入数据给每个客户端 3.每个客户端没有新的操作数据时Lock 4.客户端收到同步过来的所有操作时，进行一次Step模拟 5.所有客户端处在同一时间线
状态同步和帧同步
状态同步
1.玩家输入操作，请求发送给服务器 2.服务器解析请求，进行游戏逻辑模拟，将更新后的Entity状态发送给客户端 3.客户端根据服务器的新状态更新本地Entity表现 【逻辑状态都由服务器决定】 【case：1s时Entity位置为2，2s时为5，3s时为8。断线重连以后，直接同步到8，就会造成视觉效果不一致】
帧同步
1.玩家输入操作，请求发送给服务器 2.服务器收集一帧内的玩家操作，然后发送给每个客户端 3.客户端根据服务器发回来的玩家操作，自己进行本地动画渲染 【逻辑状态由客户端决定】 【透视外挂影响比较严重】
实际使用
1.客户端为了体验会做移动预测，和服务器位置坐标差值累计超过阈值，就会重置客户端 2.战斗相关预测，比如声音，特效，动作切换等等 3.为了预测的正确性，需要保证服务端和客户端行为一致。客户端和服务端都需要有游戏逻辑，实际场景中，往往是状态同步和帧同步结合。
经验：实际使用中，应该根据数据的大小，动作预测的需求等选择合理的同步方案。一个游戏中，往往都是二者结合，不同的东西用不同的同步方案。
王者荣耀帧同步，吃鸡和原神状态同步。 吃鸡有100人，每秒的操作都很大，而且视野范围有限，所以选择状态同步开销更小。
人物移动和跳跃以及视野
通过三维坐标，进行任务和场景的布置，移动跳跃的展示
