PUN使用：https://gameinstitute.qq.com/community/detail/112372

下面的内容，是翻译的部分官方说明。

本地服务器

https://doc.photonengine.com/en-us/server/current/getting-started/onpremises-or-saas
官方论坛

层级结构

基本概念

Game Logic

游戏逻辑定义了客户机如何与服务器交互。它实现操作、事件和服务器自己做的任何事情。
任何游戏逻辑都可以直接在c#框架上开发。它的入口点是application类，在“Photon.Socketserver.dll”中定义。

• LoadBalancing Application
  目录：("{Server_SDK_path}/src-server/Loadbalancing")
  适用于处理基于房间类型的游戏。
• MMO Demo Application
  适用于单个的大型世界。该应用程序为客户端处理客户端感兴趣的东西，并为items、properties、actor等提供类。
• Lite Application
  轻量，一个简单的例子，帮助掌握。

Operations

一个Operation相当于一次远程调用，客户端使用远程调用来完成他们要做的任何事。
Operation和它们的所有参数，都在服务端根据需求进行定义。
客户端可以通过设置哈希表匹配的方式调用任意Operation。
客户端和服务端框架来负责数据的序列化、反序列化、传输。
每个Operation会有一个结果（回执），这是像客户但提供请求数据的一种方法。也可以跳过这个步骤来节约流量。
Operation调用和回执，操作结果是在客户端和服务器之间，其他客户端不会知道这些。

Events

Events是服务端发给客户端的消息。每个事件都以字节码输入，并附带着游戏更新。
“LoadBalancing Application”在服务端定义了几个Events，但是也完全可以在客户端定制Events。
与Operation不同，接收到的Events很可能导致其他客户端的Operation调用。
这意味着，Events可能随时到来。
“LoadBalancing Application”服务端在某人加入或离开房间时发送事件。
RaiseEvent这个Operation使Events变得真正通用：任意客户端可以创建新的Events，通过把数据和应用的代码放在一个hashtable中，并把它发送。游戏数据可以在不需要更改服务器的情况下发送。
当然，对于更复杂的服务器端Events响应，可以定义自定义的Operations来检查Events数据，编译，或创建其他的Events。（就是支持自定义）。

Connections and Timeouts

与普通UDP不同，Photon的可靠UDP协议在服务器和客户端之间建立了连接:UDP包中的命令有序列号，如果它们是可靠的，则有一个标志。如果是，接收端必须确认该命令。可靠的命令在短时间间隔内重复执行，直到收到确认。如果它没有到达，连接将超时。
双方都从各自的角度独立地监视这种连接。双方都有自己的规则来决定对方是否还在。
如果检测到超时，连接的那一侧将发生断开。只要一方认为另一方不再响应，就不会向它发送任何消息。这就是超时断开是单向的而不是同步的原因。

启动服务器

• 启动方式有两种，一种是通过启动参数启动.exe文件，另一种是使用PhotonControl.exe。
• IP设置：Autodetect public 使服务器在启动时检测公共internet IP。
  使用Local IP意味着只有在相同的本地网络中的客户机才能连接。你需要使用一个Public IP，如果想玩家从互联网连接加入游戏。
• 按照教程启动。启动成功。启动测试exe连接成功。

Photon Plugins

• PPlg仅适用于企业云或自承载的Photon Server v4。
• 在Photon4中，Plugin作为扩展游戏/房间行为的新方法被引入，取代了Photon3中通过继承实现的功能。
• Plugin API的设计接近核心流程(创建空间、加入、离开等)。

1. 保持高度的灵活性:允许在处理之前和之后挂钩到核心流。
2. 减少中断流的机会:在客户端和服务器上快速提供错误。
3. 允许使用无锁代码:插件实例每次不会得到一个以上的调用，框架提供了一个HTTP客户机和集成在底层光子消息传递体系结构(fiber)中的定时器。
4. 降低复杂性和增加易用性:参见“最小化插件”。

• 概念：要添加自定义服务器逻辑，需要将代码注入预定义的Photon server hooks。目前Photon Server只支持由Room Events触发的GameServer Events。
• 根据定义，PPlg具有唯一的名称，并实现这些事件回调。自定义插件被编译成一个DLL文件称为插件程序集。然后，所需的文件被“deploy”到您的Photon Server或上传到您的企业云。
• 配置的插件程序集在运行时随着每个房间的创建而动态加载。然后根据工厂模式创建插件实例。
• 触发插件创建的房间称为“host”游戏。后者可以直接从插件中访问，并且它们都具有相同的生命周期。
• Webhooks是Photon plugins的一个很好的例子。Webhooks 1.2的源代码可以在plugins SDK中找到。我们鼓励你深入研究。

Basic Flow

Photon hooking原理依赖于六部流程：

1. 拦截hook调用
   当回调被触发时，主机将控制权转移到插件。
2. [可选]更改调用信息
   在处理客户端/服务器发送的请求之前，访问和修改它。
3. [可选]注入自定义代码
   在处理调用前与主机交互(例如发出HTTP请求、查询室/参与者、设置计时器等)。
4. hook过程调用
   决定如何处理请求（查看"ICallInfo Processing Methods"）。
5. [可选]注入自定义代码
   一旦处理完毕，客户端/服务器发送的请求就可以“作为只读”。然而，插件仍然可以与主机交互，即使在处理之后。
6. 返回
   插件将控制权转移给主机。

Getting Started

Minimal Plugin

• 推荐的制作插件的简单方法是扩展PluginBase类，而不是直接实现所有IGamePlugin方法。然后您可以重写您需要的那些。
• 要获得最小的插件实现，您只需要重写PluginBase.name。它标识这是个插件。

"Default" should not be used as a plugin name.

namespace MyCompany.MyProject.HivePlugin
{
  public class CustomPlugin : PluginBase
  {
    public override string Name
    {
        get
        {
            return "CustomPlugin"; // anything other than "Default"
        }
    }
  }
}

The Factory

• 插件工厂类被期望作为插件程序集的一部分实现。它负责为每个房间创建一个插件实例。为了简单起见，在下面的代码片段中，工厂默认返回CustomPlugin实例，而不检查客户机请求的插件到底是哪个。
• 触发插件实例化的room作为IPluginHost参数传递给IPluginFactory。创建方法。相同的参数也应传递给IGamePlugin.SetupInstance，以便在插件内部保存对游戏的引用。IPluginHost提供了对room数据和操作的访问。

namespace MyCompany.MyProject.HivePlugin
{
  public class PluginFactory : IPluginFactory
  {
    public IGamePlugin Create(
          IPluginHost gameHost,
          string pluginName, // name of plugin requested by client
          Dictionary<string, string> config, // plugin settings
          out string errorMsg)
    {
        var plugin = new CustomPlugin();
        if (plugin.SetupInstance(gameHost, config, out errorMsg))
        {
            return plugin;
        }
        return null;
    }
  }
}

Configuration

企业云

• 根据教程可以修改和保存属性键值；但是没找到添加属性键值的地方。

内部部署
修改文件"Photon.LoadBalancing.dll.config"。

<PluginSettings Enabled="true">
    <Plugins>
      <Plugin
          Name="{pluginName}"
          AssemblyName="{filename}.dll"
          Type="{namespace}.{pluginfactory class name}"
      />
    </Plugins>
 </PluginSettings>

• 构建所需的插件DLL及其依赖项和其他文件必须根据配置的插件名称值放置在“deploy\plugins{pluginName}\bin\”文件夹中。

Plugin Factory

• 我们的插件模型使用工厂设计模式。插件按需按名称实例化。
• 一个Photon Plugins插件程序集可能包含多个插件类和一个活动的"插件工厂"。工厂一个一般就够了，插件可以多搞几个。例：每个游戏类型（或模式或难度等）都可以有一个插件。该工厂还可以用于服务多个插件版本。用例。
• 客户端通过请求初始化插件roomOptions.Plugins创建房间。roomOptions.Plugins是string[]类型的，它的第一个元素应该是插件的名字，并且将会传递给工厂。

• 如果客户端没有发送任何东西，服务器要么使用默认值(当没有配置任何东西时)，要么使用插件工厂在创建时返回的值，不管创建的是啥。

如果在PluginFactory.Create中返回的插件的名称与客户端请求的不匹配，那么插件将被卸载，客户端create或join operation将失败，出现PluginMismatch(32757)错误。
另外,目前,roomOptions.Plugins最多应该包含一个元素(插件名称字符串)。如果发送了多个元素(roomOptions.Plugins.Length > 1)则将接收到一个PluginMismatch(32757)错误，房间连接或创建将失败。

• 在工厂中只需要使用这个名字来加载相应的插件如下:

public class PluginFactory : IPluginFactory
{
    public IGamePlugin Create(IPluginHost gameHost, string pluginName, Dictionary<string, string> config, out string errorMsg)
    {
        PluginBase plugin = new DefaultPlugin(); // default
        switch(pluginName)
        {
            case "Default":
                // name not allowed, throw error
            break;
            case "NameOfYourPlugin":
                plugin = new NameOfYourPlugin();
            break;
            case "NameOfOtherPlugin":
                plugin = new NameOfOtherPlugin();
            break;
            default:
                //plugin = new DefaultPlugin();
            break;
        }
        if (plugin.SetupInstance(gameHost, config, out errorMsg))
        {
            return plugin;
        }
        return null;
    }
}

Plugin Callbacks

• Photon Server有9个预定义的hooks。
  您不需要在代码中显式地注册这些hooks。默认情况下，任何插件类都可以拦截所有9个事件。然而，您应该实现您需要的。我们建议扩展PluginBase并覆盖所需的回调。

• 所有的核心事件回调都有一个特殊的ICallInfo规则。大部分的回调都是通过客户端的操作直接触发。客户端的请求操作，是由ICallInfo.Request方法提供的。

• OnCreateGame(ICreateGameCallInfo info)

  • 先决条件：客户端调用了OpCreateRoom或OpJoinOrCreateRoom或OpJoinRoom，并且room在服务器中无法找到。
  • 处理：

image.png

九个内置事件