Studio网络通信介绍

迷你世界 Studio联机模式

迷你世界联机主要是分为两种:

一种为 主客机模式，由主机不仅作为客户端还需要作为服务器，其他玩家为客户端
另外一种为 云服模式，云服作为服务器，每一位玩家都为客户端。

服务器负责运行整个游戏世界并与客户端进行同步，接收客户端发来的信息，处理运算后对游戏世界进行改变。

服务器与客户端如何通信

在游戏运行的时候，服务器会不停的更新所有的客户端

例如当服务器脚本将天气进行了改变，此时服务器运行的游戏世界天气发生改变，此时也会通知所有客户端天气需要改变。

客户端也可以向服务器发送消息

例如玩家的按下W按键后向前移动会先在客户端进行处理玩家移动，然后通知服务器对应的结果，服务器根据结果对游戏世界进行改变，让玩家角色向前移动，同时这个变化会通过服务器同步至其他客户端，这样其他玩家也能看到这个角色的移动了

所以分清楚代码应用在何处显得十分重要。

客户端代码

客户端代码一般来说是用于处理玩家信息、玩家输入以及玩家界面的。响应玩家的输入并可能使服务器内容进行更改，但是首先会在客户端进行处理，这个可以给玩家快速的反馈。同样的，玩家UI界面也是有客户端代码进行处理

LocalScript 只有在客机上且是 以下节点 的后代子节点（儿子节点，孙子节点等等）代码逻辑才会执行

localscript_used

Player 的，如的子项
Player 的模型
Player 的，联机情况下只有 LocalPlayer 对应的 Actor 对象的 LocalScript 才会运行，非 LocalPlayer 的 Actor 即使有 LocalScript 也不会执行
Player 的
Player 的
服务

服务器代码

服务器代码主要负责游戏逻辑，玩家数据更新，场景改变等，是否需要服务器代码可从以下几个条件考虑

脚本代码是否会对游戏世界进行改变，例如添加模型，移除模型等，需要所有的客户端都会做出同样的改变
玩家较为重要的数据信息。此类信息可以放在服务器进行更改处理，用来保证外挂的干扰

服务器代码在Script中运行。只有当Script属于以下实例的子类时，此类代码才会开始运行：

玩家的

同步代码

迷你世界 Studio与传统游戏相比，迷你世界 Studio的开发者可以控制客户端（玩家）与主机或云服之间的通信。开发者可以通过节点的同步属性控制该节点是否与服务器内的属性进行同步。基础的通信原理是客户端对节点属性进行修改，然后属性变化会同步至主机，主机会再次同步给其他客户端。

目前支持的同步模式如下

SyncMode : | 同步模式 | 描述 | | ---- | ---- | | NORMAL | 正常模式（任意端修改了节点、属性均会同步到其他端） | | DISABLE | 禁用（不同步，修改只会本地生效） | | ONLYHOST | 仅主机模式（只能主机发只能客机收） | | ONLYREMOTE | 仅客机模式（只能客机发） |
LocalSyncFlag : | 同步模式 | 描述 | | ---- | ---- | | ENABLE | 开启模式（设置开启才能同步） | | DISABLE | 禁用 | | NO_SEND | 禁止发送 | | NO_RECEIVE | 禁止接受 |

一、SyncMode

SyncMode该属性只能通过 Script（服务器脚本）进行同步，Localscript无法对其进行修改。所以不同客户端的同一个节点的SyncMode是相同的

实例：有一个模型节点cube，现在有两个客户端，以及一个服务器

NORMAL: 该节点在任何一个客户端被修改后（通过LocalScript修改），都会同步给主机（云服）然后再次同步给其他客户端；使用Script会修改主机内该节点属性，并会同步给所有客户端。
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性会被同步为(10,10,10)，云服会像B客户端进行同步，B客户端内该cube也会修改至(10,10,10)。
情况2：当cube使用Script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，服务器内该属性会同步至AB两个客户端，都会变为(10,10,10)
DISABLE: 则客户端属性的修改不会同步给其他客户端；使用Script对属性进行修改是不会同步给所有客户端的
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性仍为(0,0,0)，B客户端也为(0,0,0)
情况2：当cube使用script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，AB两个客户端内cube仍在(0,0,0)位置
ONLYHOST: 只能通过Script进行属性修改才会同步给其他客户端，使用Localscript进行修改仅会修改当前客户端的属性
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性仍为(0,0,0)，B客户端也为(0,0,0)
情况2：当cube使用script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，AB两个客户端内cube会同步至(10,10,10)位置
ONLYREMOTE: 使用Script可以修改主机（云服）的节点属性，但是客户端不会接收同步；使用Localscript会修改当前客户端的属性，同时同步改变主机的节点属性，但是主机不会同步给客户端。
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性同步为(10,10,10)，但是B客户端仍为(0,0,0)
情况2：当cube使用Script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，AB两个客户端内cube依然在(0,0,0)

二、LocalSyncFlag

LocalSyncFlag该属性只能通过Localscript（客户端脚本）进行修改，Script无法对其进行修改。所以不同客户端的同一个节点的LocalSyncFlag可以设置为不同

实例：有一个模型节点cube，现在有两个客户端，以及一个服务器

NORMAL(与SyncMode相同): 该节点在任何一个客户端被修改后（通过LocalScript修改），都会同步给主机（云服）然后再次同步给其他客户端；使用Script会修改主机内该节点属性，并会同步给所有客户端。
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性会被同步为(10,10,10)，云服会像B客户端进行同步，B客户端内该cube也会修改至(10,10,10)。
情况2：当cube使用Script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，服务器内该属性会同步至AB两个客户端，都会变为(10,10,10)
DISABLE(与SyncMode相同): 则客户端属性的修改不会同步给其他客户端；使用Script对属性进行修改是不会同步给所有客户端的
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性仍为(0,0,0)，B客户端也为(0,0,0)
情况2：当cube使用Script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，AB两个客户端内cube仍在(0,0,0)位置
NO_SEND: 只能通过Script进行属性修改才会同步给所有客户端，使用Localscript进行修改仅会修改当前客户端的属性
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性仍为(0,0,0)，B客户端也为(0,0,0)
情况2：当cube使用Script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，AB两个客户端内cube会同步至(10,10,10)位置
ONLYREMOTE: 使用Script可以修改主机（云服）的节点属性，但是客户端不会接收同步；使用Localscript会修改当前客户端的属性，同时同步改变主机的节点属性，但是主机不会同步给客户端。
情况1：当cube位置属性通过A客户端的Localscript从原有的(0,0,0)修改为(10,10,10)后，服务器内该属性同步为(10,10,10)，但是B客户端仍为(0,0,0)
情况2：当cube使用Script脚本将cube从原有的位置(0,0,0)修改为(10,10,10)后，AB两个客户端内cube依然在(0,0,0)

三、组合

开发者开发时可能会面对LocalSyncFlag和SyncMode冲突的情况，遵循的原理为: