您老就不能使用固定分辨率吗,在设计模式搞这个有什么意义

第一个是表达了在平面zuobiaoxi

public enum EWeaponType
{
    WeaponGun,
    WeaponRifle,
    WeaponRocket,
}

这里把枚举重写下,和预制体名字一样

string assetName = weaponType.ToString();

然后枚举变量转文本

使用到ECS设计框架  运用到Entitas插件进行管理。

Entitas是一个运行效率高的轻量级C# Entity-Component-System(ECS)框架，专门为unity订制。提供内部缓存和快速的组件访问。它经过精心设计，可以在垃圾收集环境中发挥最佳作用。

面向对象思想强调对象，通过对象自身属性等完成具体实现。ECS则强调过程，通过并无实际意义的实体来收集作为数据的容器来完成具体实现。
 

关于命名规范

关于技术栈

1、对象池

2、通过命名规范，实现挂载脚本自动化，预制体上不挂脚本

3.简易UI

4.AI寻路

5.FSM，有限状态机

6、用Animator重构动画结构

7，配置文件。数据本地持久化，

8、功能模块化。使用数据驱动。最大程度上的复用代码，提升拓展性，在项目中才能更好的理解设计模式。

四、组件设计

1.资源加载，通过命名规范，实现资源加载的自动化。

2.游戏场景分布加载控制

3、动画控制组件

4、人物行为组件

5、声音控制组件。

6、特效控制组件

7、关卡管理器

8.怪物生成器

9.关卡管理器

10.怪物AI

有需要的同学也可以这样写; 我不太喜欢让子持有父, 所以让子返回信息给父

//控制
public class Context
{
    //由于state是私有的,外部不能访问,所以需要提供以下方法
    private IState state;

    //封装一次方法
    public void Handle(int num)
    {
        IState tempState = this.state.Handle(num);
        if (tempState != null)
            this.ChangeState(tempState);
    }

    //切换状态
    public void ChangeState(IState state)
    {
        this.state = state;
    }
}

//接口
public interface IState
{
    public IState Handle(int num);
}

//实现接口
public class StateA : IState
{
    public IState Handle(int num)
    {
        Debug.Log(this + "  " + num);

        if (num > 10)
            return new StateB();
        else
            return null;
    }
}

//实现接口
public class StateB : IState
{
    public IState Handle(int num)
    {
        Debug.Log(this + "  " + num);

        if (num <= 10)
            return new StateA();
        else
            return null;
    }
}

你哪怕弄成固定分斌率也不会有这种问题, 主要是设了16:9的原因

这个采用dotween会更可控吧, 时间也可以在叫脚本中一一控制

需要取消鸟的射线检测, 否则会影响按钮点击

为什么这里不创建两个空物体作为坐标点呢, 这样就不用一次调试看数据了

点击礼物直接作用于暂停按钮也可以

 项目名称：BowlingGame

1.搭建Pico开发环境

• 打开Pico开放平台网站，开发资源

但这个例子举得实在有点一般

这一步少了个演化步骤,本来整体可以缩减为IOC变量,Init()方法,Get()方法; 然后在写成模板的需求下,增加了一个mArchitecture变量和MakeSureContainer()方法,主要是为了用来调用非静态的抽象方法Init()

在讲框架的时候,还用这种跨模块的调用不合适吧

所以为什么这么多次了还放在这里呢, 自身的事情自身去完成, 例如检测放回对象池, 这种事情就应该由带有AudioSource组件的物体自己去完成, 而不是大包大揽全放在AudioManager里面;

至少可以创建个预制体吧,然后加载出来使用;

每次都在脚本里面写,用一种更麻烦的方式去实现

这集真够水的!!

为什么不把需要调用的面板都放到字典里呢,然后通过字典调用对应面板;

而不是只用来判断面板是否已经生成;

我的理解是谁有需要写在谁那里呗,如果后续其他预制体有其他的需求,总不能都写在这里吧,造成本来简练的代码变得臃肿;

既然bullet有需要就写个bullet脚本呗,销毁时间也不要单独写,写个脚本统一管理和调用;

其实这个顺序有点错误,小池ObjectPool只需要作为类使用就行,把具体实现方法放在池管理ObjectPoolsManager中,这样也能避免多次封装;

另外,为什么这里不直接使用字典查找呢,声明字典Dictionary<string, ObjectPool> poolDict,查找的时候直接使用名称poolDict["Bullet"]查找就可以了;

把初始化放物体自己身上就好,Awake记录,OnEnable调用初始化就好