游戏框架笔记

游戏的数据有哪些类型

无非是只读数据（各种道具配表里的数据）和可读可写数据（玩家属性、拥有的物品）。

游戏框架需要哪些管理器

用户数据管理器

负责找到数据持久化文件，从中读取指定用户的数据，包括玩家的设置数据（音量等）、拥有的物品（金币、人物、道具）。

不需要依附游戏对象，一般是不继承MonoBehavior的单例。

资源配置管理器

负责找到配表文件，根据外界要求的资源种类、ID返回资源的详细信息（游戏内名字、图标、预制体，其他信息如价格）。

资源加载管理器

负责封装加载资源的方法（Resources和AB包），以便快速切换。主要用于资源配置信息管理器加载配表文件，和加载UI面板预制体。

和资源配置信息管理器可以合成一个吗？不合适，因为还要加载UI预制体。

这个管理器就是提供加载资源的方法，并能方便在Resources和AB包加载之间切换。

场景管理器

提供异步加载场景的方法。显示加载界面、更新进度条的代码可以放在里面。

因为要用协程，且全局存在，应该是DontDestroyOnLoad的继承MonoBehavior的类。

UI管理器

提供加载面板的方法，包括从Resources和AB包加载，包括全屏面板和部分面板。为此需要面板预制体的路径和资源名，需要一个方法知道当前哪些面板在显示，可以是查看一个面板类的单例是否存在，也可以用一个字典存储显示的面板。

声音管理器

使玩家可在任意场景的设置面板改变音乐和音效音量。游戏所有播放声音都要使用它封装的函数。它无需储存用户设置的音量，因为那属于用户数据，由用户数据管理器存储。

看想不想用拖赋值，想就用DontDestroyOnLoad的继承MonoBehavior的类。

关卡场景管理模块

以上是游戏全局需要的管理器，在关卡场景有一些所有关卡都相同的管理模块：输入模块、相机模块、UI模块（HUD、对话面板、交互选项面板、任务面板）、关卡管理器、缓存池。

这些模块一般打成一个预制体，新建关卡时直接拖入。（虚幻项目直接就有一套这些）

缓存池

在射击游戏里一般用来存弹壳、弹头、击中效果。只在关卡场景需要，所以用继承MonoBehavior的单例，可以和游戏管理器、输入模块等打进同一个预制体。

cs 复制代码

public enum BufferType{
        impact,bullet, rifleShell,handgunShell,impactBlood
    }
public class BufferPoolBase : MonoSingleton<BufferPoolBase>
{
    public const float impactLifeTime=1;
    Dictionary<BufferType,Transform> bufferDict=new Dictionary<BufferType,Transform>();
    //可能的情况包括没缓冲池、有缓冲池没物体（一般不会有，但理论上可能）、有缓冲池有物体
    public GameObject Depool(GameObject prefab,BufferType bufferType,Vector3 position){
        GameObject instance;
        if(bufferDict.ContainsKey(bufferType)){//缓冲池已建立
            if(bufferDict[bufferType].childCount>0){//缓冲池里有物体
                instance=bufferDict[bufferType].GetChild(0).gameObject;//取出
                instance.transform.SetParent(null);//解绑
                instance.transform.position = position;
                instance.SetActive(true);//激活
            }
            else{//有缓冲池没物体（曾经放入过物体，又拿出了）
                instance=Instantiate(prefab,position,Quaternion.identity);
            }
        }
        else{//没有缓冲池
            Transform bufferTransform=new GameObject(bufferType.ToString()).transform;
            bufferTransform.parent=transform;
            bufferDict.Add(bufferType, bufferTransform);
            instance=Instantiate(prefab,position,Quaternion.identity);
        }
        return instance;
    }
    public void Enpool(GameObject instance,BufferType bufferType){
        if(!bufferDict.ContainsKey(bufferType)){
            Transform bufferTransform=new GameObject(bufferType.ToString()).transform;
            bufferDict.Add(bufferType, bufferTransform);
        }
        instance.transform.SetParent(bufferDict[bufferType]);
        instance.SetActive(false);
    }
    public IEnumerator EnpoolLater(GameObject instance,BufferType bufferType,float delay){
        yield return new WaitForSeconds(delay);
        Enpool(instance,bufferType);
    }

事件中心

我们知道事件中心是用于一个事件引发很多操作的，它比直接调用避免了蜘蛛网一样的耦合，但是又比直接调用麻烦一点。那么问题是，任何一个类操作引起另一个类的操作都要用事件中心吗？那样很明显事件中心会有大量事件。应该设置一个操作引起其他类操作个数的阈值，达到阈值的使用事件中心。

输入模块、玩家人物和人物

玩家人物和NPC人物有一些共性，玩家人物还有一些个性：更新UI、接受输入控制。通常会把玩家人物作为人物的子类，重写一些方法。问题是任何一个类操作引起另一个类操作都要用事件中吗？

是否只有一个操作引起的操作达到一个数量时才值得用事件中心？

输入模块和玩家人物要写在一个脚本吗？

如果用了新的Input System，我们知道给几十个按键配回调很麻烦，会想把PlayerInput和处理回调的脚本放在一个预制体里，如果把PlayerInput和玩家人物打进预制体，那么不同关卡用不同人物时又要换人物的骨架和模型，人物身上绑的物品挂载点、约束也要重新绑。会想到写一个输入回调处理脚本MyInputHandler和PlayerInput放在一起，MyInputHandler指向玩家人物。也就是输入模块和玩家人物分离。

输入脚本和人物脚本的代码分布

人物的各种行为会封装成方法Move()、Turn()、Run()、Jump()。这些方法是在

人物脚本Update()
输入脚本Update()
输入脚本处理输入的方法

执行？

放在输入脚本Update()就等于输入回调先写入输入脚本字段，再传给人物脚本行为方法的输入参数。

放在人物脚本Update就等于先写入人物脚本字段再让行为方法读取。

放在输入脚本的输入回调方法就是把输入变量传给人物方法的输入参数，只在输入变量改变时执行。

为了减少字段，可以尽量用3，但有一些方法必须每帧执行，比如跑步可能被各种情况打断（射击、换弹、坠落）。跑步要执行，除了按下跑步，还要满足几个条件，这些条件有的靠状态机的互斥就可以（跳跃、坠落），有的要另外判断（主要是上半身层的）。执行跑步前把这些条件全部&&。

管理器分类

根据管理器的生命周期，可以分为整个游戏内存在的和场景内存在的。根据是否必须继承MonoBehavior，可以分为继承和不继承。这两个问题组合，其中不继承MonoBehavior的一定整个游戏存在。这样就把管理器分为3类：

不继承MonoBehavior；
继承MonoBehavior；
继承MonoBehavior且DontDestroyOnLoad；

不继承MonoBehavior

用户数据管理器、资源配置管理器；

继承MonoBehavior

各场景内的管理器。对于关卡场景，有输入、相机、秩序管理、缓存池。

继承MonoBehavior且DontDestroyOnLoad

通常是游戏全局存在且需要协程的管理器：场景管理器、AB包管理器。

还有必须和组件关联的管理器，比如声音管理器，必须记录音乐声源和UI音效声源。

这些管理器可以打成一个预制体。

登录注册系统

多用户数据系统

如果一个游戏要做登录注册界面，那么它就是一个多用户游戏，意味着它有一个记录用户名和密码的文件，而其他大部分数据（玩家拥有的人物、武器、物品、音量）都因用户而异，需要在每个用户注册时建一个文件夹，把这些用户数据文件都放在里面。

这样UserDataManager在构建的时候就不能加载所有的数据，因为还没登录，不知道用户名，也就不知道这些数据文件的路径。所以需要一个UserManager，开始运行时构建，负责获取上次登录用户、注册新用户、判断登录是否成功。加载登入用户数据的DataManager在登录成功后构建，它读取数据的路径依赖登入的用户名。

场景管理

需要有一个《场景转换图》列出所有的场景和哪些场景。一般需要登录场景、主界面场景、若干游戏场景。登录场景和主界面场景应该分开，因为主界面场景可能从登录场景或游戏场景进入。