第一次参加Gamejam后的成长——小白开始蜕变？

您更新了 10 天前 • 评论 • 被浏览仅您自己

前言

第一次尝试 Gamejam ，以熟悉 Unity 和游戏制作流程为主。在实际自己独立完成一个 Gamejam 作品的过程中我学习到了很多，同时也发现了很多很多不足。

成长之处

Sprite
- sprite renderer 上设置根据 pivot 排序，实现动态遮挡
- sprite editor 里设置物理大小，可以调整 tilemap collider 的大小，切片时可选择轴心位置
- 先设置好轴心这些，调整好遮挡关系，再去设置 collider ，否则 collider 的位置会很奇怪
- pivot 的位置可以全部设置在底部吗？
单例模式下，不应该在OnEnable和Awake下访问其他的单例，只能从最主要的Manager去访问其他的，否则会导致物体被Destroy。需要有先后访问顺序，或者手写类似线程锁这样的东西
函数命名，函数只干一件事情
多写注释，#region，/// <summary>

不足之处

程序设计架构混乱，逻辑上不清晰，抽象层级不够，场景管理虽然有但仍然困难。可测试性差，如果要从某个场景直接开始不能正常运行。
资源管理混乱，由于对Tilemap的不熟悉，我把各个瓦片都放在了同一个文件夹下，难以管理。Prefab使用时踩坑，搞了十几分钟的东西被覆盖掉，还需熟悉。
对Sprite的各种操作不熟悉，遮罩管理错误，对瓦片地图的使用场景的可能的错误认知。操作2D光影时，由于之前只接触过方形Sprite，不知道要修改Shadow Caster 2D的形状，导致阴影生成错乱。
游戏设计拉垮
玩家交互系统设计也许设计的不好，但本次游戏对交互的需求较少，不好作出评价
游玩过程的反馈很少，音效只有一点点，屏幕反馈没有，鉴于这是一人速通Gamejam情有可原，但仍然需要后续学习
在 Prefab 上踩坑，如果我想制作一个传送门，那么我是否可以把一对传送门放到一个父对象下，然后把父对象作为预制体。如果我在其他场景中更改了这对传送门的位置，同时为传送门添加了某个脚本，而我只想为所有传送门添加脚本而不希望改变位置，这可以做到吗。是否需要在做可能行为不同的东西的时候，要注意分离出使用相同预制体的物品的行为之间的统一和不统一的地方

根据以上缺点，以及制作游戏时遇到的一些问题，我认为目前需要了解一下内容

TOLEARN:

UI框架
场景加载播放动画
代码过于混乱，SceneManager，如何做到开始在哪个场景就直接可以用哪个（分场景测试），快速禁用动画方便测试
EventSystem
协程
Scriptable Object
Collider分层应用场景是什么，这个还没有使用过
2D光影
Sprite深入了解
解决 Prefab 踩坑

学习过程

首先从框架入手

首先根据自己目前的认知和想法思考了一下目前的框架

十分潦草的反省草稿

然后重新初步制定了一套标准

先这样写着，等从其他开源框架那学到一点东西之后再来打脸。

后续补充：实际上已经打脸了，几天后已经学了几个框架和技术栈，其中有一个小型架构 UniFrameWork 我还阅读了源码，学习了 HybridCLR，YooAsset 、TEngine、ET等，详见下方。

接下来学点杂事

光影

做项目的时候，我在2D光线和阴影上踩了很大的坑，所以先去学习阴影的生成。我发现给 Grid 添加 Shadow Caster 2D 是没有用的，它并不会给每一个 tile 都添加一个正方形阴影，后来我在一个视频中找到了一个脚本，用于生成每个 tile 的 Shadow Caster 。链接：https://github.com/Lumos-Github/Auto-add-Shadow-Caster-2D-on-TileMap/blob/main/Assets/ShadowCaster2DTileMap.cs

还有一件事就是，我在把渲染管线换成 URP 之后，场景中的 Sprite 遮罩关系突然错乱，后面发现在 URP 的渲染器列表中的那个资产里要这样设置：

场景管理

之前提到的资源和场景管理，我发现可以通过更改 GameObject 在场景中的标签来让场景中的物体易于观察，分清层次。

Prefab

似乎是这样的，如果把 Prefab 拖到场景中形成一个物体，如果不修改这个物体的任何属性，那么修改 Prefab 时就会导致这个物体的属性被同步修改，如果提前修改过了熟悉，那么就不会受影响

只发生在构建时的 Null Reference （Null References ONLY in Build）

这次游戏实际上并没有提交上去，因为构建出来正如本段标题所示。后续去网上查找，发现很多人也遇到了一样的问题，在这篇帖子中有个回答是这么描述的：

如果真是这样的话，不明白为什么 Unity 要这么设计。我似乎明白了一部分原因：我的代码可能在非Awake和Start的地方去获取了一些在场景里的物体（Awake和Start是一定会在物体生成之后执行的），但我写的代码一进场景就获取物体，物体还没加载出来，所以就 Null Ref 了。所以如果要一开始获取场景内的物体话应该是要写在 Start 或者 Awake 里。之后还是用代码单一入口然后驱动其他实例动态加载场景吧。

又发现了新东西，这个单例的 Init 函数在 Awake 之前被调用了，我的锅。那可能是因为物体还没生成就被调用导致错乱了罢。这就是乱用单例的后果…

然后就到了重头戏——架构

前期我简单看了一下目前网上流传哪些好用的框架，GameFrameWork、ET、QFrameWork 等等，看了一圈，发现 TEngine 和 ET 还在保持更新中，项目中也用到了 HybridCLR 和 YooAsset ，我之前既没有了解过热更新，也没有了解过 AB 包。所以这次来学习一下。

HybridCLR

HybridCLR 比较好上手，难点在于逻辑比较绕，操作并不困难。还有一个难点就是，加载 DLL 的代码，你看官方文档里写的和官方示例项目里 LoadDLL.cs 里面写的就是两码事。官方示例项目里面还有 Editor 扩展，强烈建议把那部分扩展代码复制到自己的项目中，然后读懂 LoadDLL.cs ，本质上是 AssetBundle 和 HybridCLR 的结合。

YooAsset

学习这个的过程简直是一场灾难。我入门的时候文档和实际的包不是一个东西，不仅前人留下的代码失效了一部分，官方文档也年久失修了。Space Shooter（官方示例项目）中使用了第三方库，阅读起来对新手十分不友好，里面包含了 UniFrameWork 的消息队列和状态机。

总之也是强忍着把前人的代码和官方示例项目的代码结合起来了，解决了报错，迈进了一大步。

后来在其他地方遇到了两个问题，折腾半天，最终去 Github 上发 issue 了

解决了这两个技术栈之后，就可以开始研究正经框架了，首先从稍微小型的 TEngine 看起，再去研究 ET。

插曲：看着看着又看到一个 JEngine ，star 数量比这个多，选择困难症又犯了

几天后得到了作者的回复，详见 https://github.com/tuyoogame/YooAsset/issues/262

TEngine

看了一圈，TEngine 整合了众多架构，比如 YooAsset、HybridCLR、还有老牌 GameFrameWork。

主要思想是，游戏由许多个 Module 组成，然后每个 Module 相当于接口，每个 Module 下有一个继承自 ModuleImp 的具体实现类，游戏功能实现逻辑都在这里面。

这个框架对目前的我来说有点大了，有很多功能我还不知道为什么要这么设计，于是边问 GPT 边了解功能，也算是看完了这个架构，接下来是 ET

ET

之前啃过了 TEngine ，深感无力，ET 肯定不能干啃了，于是首先看了 CSDN 上一些大佬的博客以及一些个人博客。内容涵盖 ET 事件、Entity 生命周期、配置表的使用、定时器的原理和使用、协程锁的原理和使用、UGUI 框架的使用、多语言、UI 动态循环列表、数值组件、ObjectWait组件（用于等待，锁住方法继续执行直到收到返回通知）、ComponentView…………

看了很多，全是没有接触过的复杂概念，所以阅读起来比较困难，好在最后汲取到了很多内容，也知道了 ET 的使用与内部的实现逻辑。