游戏开发日志09对应的是项目 v0.1 版本的完整记录。走到这个节点说明项目已经度过了“随便玩玩原型”的阶段开始进入第一个能被反复试玩的内部里程碑。v0.1 版本不一定有好看的美术也不需要把每个系统都做完但它必须回答两个问题核心玩法能不能循环起来技术方案能不能继续支撑后面的开发。这里按 v0.1 版本的目标、技术选型、资源管理、帧率设定、微信小游戏兼容、版本验证和日志记录这几条线复盘我在这个版本里做的事情和踩过的坑。如果你也在用 Unity3D 做独立游戏或者正在纠结资源管理和帧率目标可以参考这种版本记录方式把“开发日志”变成真正能推进项目的工具。1. v0.1 版本要交付什么先定目标和边界1.1 v0.1 不是 Demo是第一个可玩闭环Demo 通常是为了验证某个表现或技术点比如一段动画、一个渲染效果、一次动作手感。v0.1 则更像是“一个可以被完整试玩的内部版本”。它不要求美术精美也不要求系统丰富但必须把核心玩法从开始到结束跑通。我在这个 v0.1 版本里选择了一个非常小的 2D 休闲玩法玩家控制角色躲避障碍物吃到一个目标道具后计分被障碍物碰到则本局结束回到结算界面点击“再来一局”后重新开始。整个循环只有四步开始游戏、操作角色、判定胜负、结算重开。这个循环看起来简单但它是后续所有系统的基础。如果没有这个闭环后面加入背包、技能、商城、任务都不知道应该挂在哪个环节上。很多项目在 v0.1 阶段最容易犯的错误就是想把功能做得足够多。今天加一个商店明天加一个新手引导后天又加一个成就系统结果核心玩法一直没稳定连最基础的“能不能顺利开始一局游戏”都没验证完。v0.1 的价值恰恰是砍掉这些功能把精力集中在最核心的循环上。只有先让玩家愿意反复玩这一段后面的内容才值得继续开发。1.2 验收标准与不做什么版本记录不能只写“完成了什么”更要写“这个版本做到了什么程度”和“这个版本明确不做什么”。有了边界后续版本的对比才有意义。类别v0.1 验收标准v0.1 不做什么原因核心玩法能完整玩一局并重开失败判定准确不做多关卡、不设计复杂技能先验证核心循环是否成立技术基础资源加载正常、能定位日志、失败不崩溃不做热更新、不做增量下载v0.1 先跑通离线条目复杂更新后续再加性能基线记录不同平台的帧率、内存、加载耗时不追求低端机全量适配先拿到数据再决定优化优先级工程记录能通过 Git 标签找到 v0.1 对应代码不写完整项目文档用日志记录关键决策文档后续再整理这份验收标准不是拍脑袋定的。它来自上一次迭代的教训当项目没有明确边界时任何新想法都会被加进当前版本结果版本无限延期开发日志也越写越散。v0.1 版本最重要的不是功能数量而是为整个项目确定一个“最小可验证节点”。从这之后每个版本都可以回答三个问题上版本遗留了什么本版本新增了什么下版本要解决什么。2. 技术选型与工程目录调整2.1 为什么还在用 Unity3D 做这款游戏在选择引擎时Unity3D、Godot、Cocos 都有自己的适用场景。当前项目继续使用 Unity3D主要原因是团队对 Unity 的工作流更熟现成的 2D 物理、动画状态机和 UGUI 能减少很多基础工作。另一个原因是后续要考虑微信小程序游戏开发Unity 提供的小游戏导出方案和社区案例比较多踩坑时更容易找到参考。Godot 在轻量级 2D 开发上也很合适尤其是纯逻辑型和工具型游戏。如果项目是从零起步并且没有存量代码选择 Godot 完全可行。但对当前项目来说v0.1 阶段换引擎会让原本已经验证过的玩法原型失效反而增加风险。技术选型没有绝对的“最好”只有团队当前最合适。真正重要的是选定之后不要频繁更换否则日志里记录的性能数据和资源方案都会失去可比性。Unity3D 的版本选择也需要固定。这个项目使用 Unity 2021.3 LTS 作为 v0.1 的基础版本。LTS 版本的特点是稳定期更长插件兼容信息更容易查。如果你在做一个会持续几个月的项目建议直接锁定 LTS并在一开始就记录 Unity 版本和各个插件版本否则半年后回看日志很可能已经不知道当时的构建环境是什么。2.2 目录结构按资源类型和功能模块拆分v0.1 版本刚起步时我犯过一个错误所有场景、脚本、美术资源都放在 Assets 根目录下。这种结构在资源少的时候没问题但进入资源管理阶段后收集器配置会变得非常混乱因为分不清哪些资源属于哪个模块哪些资源需要打进哪个包。这次调整后的目录结构比较简洁适合小型独立项目Assets/ Art/ # 美术资源 Sprites/ Materials/ Audio/ # 音效和背景音乐 Plugins/ # YooAsset 等插件 Scripts/ Core/ # 启动、资源管理、全局配置 Gameplay/ # 玩法逻辑 UI/ # 界面相关脚本 Utils/ # 通用工具 Settings/ # 渲染、物理、播放器设置 Bundles/ # 资源包配置 Scenes/ # 场景文件目录拆分的核心逻辑是“按功能模块聚合按资源类型分类”。Art 和 Audio 负责存放原始资源Scripts 下的 Core、Gameplay、UI 负责代码逻辑Bundles 负责配置哪些资源要打包。这样 YooAsset 收集资源时可以按目录或按标签批量配置不会把美术资源和代码逻辑搅在一起。这里要注意目录结构不是一成不变的。v0.1 版本只需要保持这个结构后续如果增加关卡编辑、角色养成等模块再在 Gameplay 下拆分子目录。不要让目录结构在前期过度设计否则日常开发反而会被目录管理消耗大量时间。2.3 版本管理用 Git 标签记录 v0.1代码层面v0.1 的节点通过 Git 标签固化下来。标签不需要长得多复杂但一定要包含版本号和阶段信息。git tag -a v0.1 -m 游戏开发日志09: v0.1 可玩闭环 git push origin v0.1标签一旦打好就不要随便移动。它代表的是一段可验证的代码状态而不是临时的分支记录。如果后续 v0.1 发现问题需要修复可以在 v0.1 的基础上切出 hotfix 分支修复后再打 v0.1.1而不是把 v0.1 标签直接挪走。除了代码标签版本记录里还应该写明构建时间、Unity 版本、插件版本、目标平台。这些信息和 Git 标签配合起来才能让一个版本在几天甚至几个月后仍然可以被完整复现。3. 资源管理与 YooAsset 分析从日志09看资源框架怎么选3.1 为什么这个阶段要引入资源管理框架最初的玩法原型里所有资源都通过 Resources.Load 加载。这个方式在资源量很少时完全没有问题代码也简单。但随着资源数量增加问题开始出现Resources 目录下的资源会被全部打进包里无法按需加载资源之间的依赖关系不透明改一个预制体可能导致多个加载点出错后续如果要做微信小游戏包体大小有限制必须考虑分包和按需更新。YooAsset 是 Unity 社区里常用的资源管理框架它把资源收集、打包、加载、卸载、更新串成一套完整流程。对于 v0.1 版本我不需要立刻启用热更新但需要提前把资源加载方式从 Resources.Load 切换到统一资源管理接口。这样后面的包体控制和资源更新不需要推翻重写。学习阶段可以先用 Resources.Load 跑通玩法但只要是奔着发布去的项目建议在进入第一个可玩版本时就把资源管理框架接进去。否则后期重构资源加载层场景里每个用到资源的地方都可能要改一遍成本会明显上升。3.2 YooAsset 的核心概念扫盲YooAsset 的几个核心概念需要先理解清楚否则配收集器时会找不到方向。概念通俗理解容易忽视的点Package一个资源包容器类似一个独立资源域启动时要先初始化对应 PackageCollector收集器指定哪些资源要打进包配置不当会导致资源重复打包Bundle构建后生成的资源包文件一个资源可能依赖多个 BundleAssetHandle加载资源后返回的操作句柄用完后必须 ReleasePlayMode编辑器、离线、联机等运行模式不同模式对应不同初始化参数YooAsset 做的事情本质上是在 Unity 的 AssetBundle 之上加了一层管理和调度。它帮你决定资源什么时候加载进内存什么时候可以卸载以及资源之间的依赖如何处理。v0.1 版本先用离线模式跑通流程后续做更新时再切到联机模式。3.3 最小接入步骤初始化、加载、卸载下面这段代码是 v0.1 版本里最基础的资源加载示例。不同 YooAsset 版本的 API 可能有差异实际项目要以你引入的版本为准这里只是展示标准流程。using UnityEngine; using YooAsset; public class Bootstrap : MonoBehaviour { IEnumerator Start() { // 1. 初始化资源包 var package YooAssets.GetPackage(DefaultPackage); var initParameters new OfflinePlayModeParameters(); yield return package.InitializeAsync(initParameters); // 2. 异步加载角色预制体 var handle package.LoadAssetAsyncGameObject(Prefabs/Player); yield return handle; if (handle.Status EOperationStatus.Succeed) { GameObject player handle.InstantiateSync(); player.transform.position Vector3.zero; } else { Debug.LogError($资源加载失败{handle.LastError}); } // 3. 使用完成后释放句柄 handle.Release(); } }整个流程可以归纳为三步初始化 Package加载资源并拿到 AssetHandle使用完释放句柄。很多内存问题都出在第三步被遗漏。句柄不释放资源就一直挂在内存里场景反复切换后内存自然持续上涨。这里还要注意加载路径和资源类型的统一。v0.1 版本里所有资源加载最好都通过一个封装好的 ResourceService 类而不是散落在各个玩法脚本里。这样后续想增加缓存、引用计数、加载超时等机制时只需要改封装层不需要改所有调用点。3.4 三个容易踩的坑资源管理是 v0.1 版本里坑最多的地方这里记录三个最典型的错误。第一个坑是句柄不释放。现象切换场景后内存持续增长最终在手机上触发卡顿甚至闪退。原因异步加载资源后没有调用 Release或者只在部分错误分支里调用了。解决把所有资源加载都经过同一个封装方法在 finally 或协程结束时统一 Release。第二个坑是重复打包。现象构建出来的 Bundle 体积比预期大很多部分资源在多个 Bundle 里出现。原因收集器配置时把同一资源同时放进了多个收集目录或者父目录和子目录都被收集了。解决收集器只配置一个入口资源统一定位不要出现重复收集。第三个坑是加载路径不一致。现象编辑器里能加载构建后加载失败。原因YooAsset 的加载路径以收集器配置的资源路径为准真实场景中拼前缀或后缀最容易出错。解决不使用手写字符串加载而是用常量表或代码生成资源路径降低人为拼写错误。注意资源管理框架不是接入就能一劳永逸。如果加载代码没有统一封装即使框架本身很稳定项目里也仍然会出现重复加载和难以释放的问题。4. 把帧率目标写进代码“多少 Hz 合适”4.1 显示帧率和物理更新频率是两件事“游戏开发多少 Hz 合适”这个问题经常被理解成“游戏要跑多少帧”。实际上 Hz 在不同语境下含义不同。显示器刷新率是 Hz游戏渲染帧率是 FPSUnity 的物理更新频率则是 Fixed Timestep。这三者互相影响但不能直接画等号。对大多数 2D 休闲游戏来说60 FPS 是一个合适的基准目标。到了手机或微信小游戏环境如果低端机跑不到 60 FPS可以考虑锁 30 FPS 以保证稳定但能在 60 FPS 跑就尽量不要主动降。比帧率数字更重要的是帧率的稳定性。一个游戏如果多数时间在 60 FPS但每隔几秒掉到 20 FPS体验反而比稳定 30 FPS 更差。Unity 的物理更新频率默认是 0.02 秒也就是每秒 50 次这个值通常不需要随意改动。如果游戏使用了 Rigidbody2D 和物理碰撞物理步长和渲染帧率不一致时可能会出现物件抖动或穿透。v0.1 版本里我们使用固定物理步长渲染帧率尽量适配显示刷新率而不是把物理频率强行拉高。4.2 按目标平台设置 Application.targetFrameRate在 Unity 中可以通过 Application.targetFrameRate 控制目标帧率。不同平台可以写不同逻辑下面是一个简单的示例。using UnityEngine; public static class FrameRateConfig { public static void Apply() { #if UNITY_EDITOR Application.targetFrameRate 60; QualitySettings.vSyncCount 0; #elif UNITY_ANDROID || UNITY_IPHONE Application.targetFrameRate 60; QualitySettings.vSyncCount 0; #elif UNITY_WEBGL Application.targetFrameRate 60; #else Application.targetFrameRate 120; #endif } }代码里把移动端目标帧率设为 60不开启垂直同步是为了减少输入延迟并尽量接近 60 FPS。WebGL/微信小游戏端同样设为 60但如果设备性能不稳定可以在运行时动态调整比如掉帧严重时先降分辨率再考虑降帧率。一个常见的误区是设置 targetFrameRate 后游戏一定按这个帧率运行。实际上这只是一个目标值实际帧率取决于渲染耗时和平台限制。想要真正稳定还需要借助 Profiler 找出耗时瓶颈而不是重复调整代码里的帧率数字。目标平台目标帧率主要考虑独立游戏 PC60 FPS兼顾画质和稳定性中低端手机45 或 30 FPS优先保证稳定不追求画质微信小游戏60 FPS 尝试30 FPS 兜底包体和内存限制更严格编辑器不强制限制方便调试4.3 用 Profiler 建立性能基线v0.1 版本的性能优化不是追求“每台机器都满帧”而是建立一条可对比的性能基线。我使用 Unity Profiler 分别记录了主菜单、单局游戏、结算界面三个场景的数据。场景目标帧率CPU 耗时内存占用主菜单60 FPS4 ms310 MB单局游戏60 FPS9 ms348 MB结算界面60 FPS5 ms335 MB这些数据只是一次普通设备上的记录不代表所有环境的标准值。真正的价值在于它让你知道当前版本最耗时的模块是谁。比如单局游戏 CPU 耗时集中在物理碰撞和渲染批处理下一阶段就可以优先优化这两个方向而不是盲目删资源。Profiler 记录完成后要把结果写进开发日志并保留 Profiler 数据文件。v0.1 的版本记录里如果只看功能列表会显得很普通但配合性能基线数据后续每次优化是否有效就有了客观判断。5. 为微信小程序游戏开发做的兼容准备5.1 小游戏环境对资源管理的限制微信小游戏虽然是 Unity 支持的导出目标之一但它的运行环境比较特殊。小游戏对首包大小有明确限制普通包体过大时必须使用分包加载。资源管理上小游戏环境没有传统意义上的文件系统不能直接用 IO 的方式读取本地文件所有资源都要走 Unity 的资源和 AssetBundle 加载流程。这意味着 v0.1 版本里用 YooAsset 管理资源的方式后续比较容易迁移到小游戏平台。只要确认当前使用的 YooAsset 版本支持微信小游戏模式并把运行时资源包配置为对应平台就可以用同一套加载接口在不同平台上运行。如果项目一开始用 Resources.Load后面要接入小游戏包体限制时改造范围会更大。不同 YooAsset 版本的平台支持和配置方式有差异落地前不要凭印象写配置要先看对应版本的文档。这个信息在项目里属于关键工程事实必须记录到开发日志里否则换电脑或换人维护时很难还原。5.2 启动流程需要按平台分支v0.1 版本在启动流程里预留了平台分支。因为不同的平台可能需要处理不同的登录、用户设置、缓存路径或性能策略这些逻辑如果全部堆在同一个 Start 方法里后面会越来越难维护。using UnityEngine; public class PlatformBootstrap : MonoBehaviour { void Awake() { #if UNITY_WECHAT InitializeWeChatPlatform(); #elif UNITY_ANDROID InitializeAndroidPlatform(); #elif UNITY_EDITOR InitializeEditorPlatform(); #else InitializeStandalonePlatform(); #endif } void InitializeWeChatPlatform() { // 微信小游戏初始化逻辑v0.1 阶段先留空 } void InitializeAndroidPlatform() { // Android 平台初始化逻辑 } void InitializeEditorPlatform() { // 编辑器调试初始化逻辑 } void InitializeStandalonePlatform() { // PC 初始化逻辑 } }这段代码的核心是把“平台差异”和“游戏逻辑”分开。游戏逻辑只关心启动后做什么平台差异通过注入或配置方式提供。v0.1 阶段这部分可能只是空壳但接口先定好后面接微信登录、广告组件、用户隐私协议时不需要回头改启动流程。5.3 日志和远程配置的落地方式在微信小游戏真机上Unity 的 Debug.Log 不会像 PC 一样直接出现在控制台。要排查问题需要把日志输出到小游戏提供的日志面板或者自己搭一个简单的内存日志面板把最近几十条日志显示在屏幕上。远程配置在这个阶段不需要完整实现但接口可以先预留。比如定义一个 GameConfigServicev0.1 里从本地静态配置读取数据后续切换成远程配置时只改实现类不改调用方。这样做的原因很简单版本记录里的技术决策要能演进而不是每加一个新需求就推翻一套代码。6. 版本验证、打包和记录模板6.1 v0.1 自测清单v0.1 版本不能只靠“感觉能玩”就完成。需要有一份自测清单逐项确认后才打 Git 标签。模块检查项通过标准启动流程冷启动后进入主菜单不崩溃日志无关键报错核心玩法开始游戏、控制角色、失败判定、结算重开整个循环可重复执行资源加载所有预制体、图片、音效能正常加载无资源缺失加载失败有日志内存表现反复进入单局 5 次无持续上涨无闪退帧率表现Profiler 记录主菜单和单局耗时达到目标帧率记录数据输入响应键盘、触摸、鼠标测试输入无明显延迟构建产物目标平台构建成功包体大小、构建时间已记录自测清单不要放在最后才做。v0.1 开发几天里每完成一个模块就验证一项避免把所有问题留到版本收尾时集中爆发。6.2 构建产物记录构建产物是版本记录的重要组成部分。除了 Git 标签还要记录构建时的环境信息。这里整理一份字段清单可以直接复制进开发日志版本号v0.1 构建时间2025-01-20 15:30 Unity 版本2021.3.30f1c1 YooAsset 版本2.1.0 目标平台Android / WebGL 包体大小45.2 MB 资源包总大小28.6 MB 构建分支feature/v0.1-playable 构建机器Dev-Machine-01实际项目中的版本号、时间和包体大小每次都会变但字段结构保持一致。这样前后版本才能真正对比出包体增长、构建时长变化和资源体积变化。6.3 开发日志09的固定记录模板开发日志不一定要写很长但必须把关键信息记下来。从 v0.1 开始我使用下面的固定模板。# 开发日志 09 - v0.1 - 日期2025-01-20 - 版本v0.1 - 目标平台Android / 微信小游戏 / PC - Unity 版本2021.3.30f1c1 - YooAsset 版本2.1.0 ## 完成功能 - 核心玩法闭环开始、操作、结算、重开 - 接入 YooAsset 离线资源加载 - 设置目标帧率并记录性能基线 ## 遗留问题 - 小游戏分包加载尚未验证 - 部分 Android 设备上内存占用偏高 ## 性能基线 - 主菜单60 FPS / 4 ms - 单局游戏60 FPS / 9 ms ## 下一步计划 - 验证微信小游戏分包 - 优化单局物理碰撞耗时这个模板最大的好处是下次写 v0.1.1 时可以直接复制上一版模板把“遗留问题”挪到“已完成”再继续写。注意版本记录不是写给别人看的作文而是写给未来自己看的排错索引。内容可以不华丽但日期、版本号、平台、问题现象必须完整。7. 常见问题排查7.1 资源重复下载和内存上涨v0.1 阶段最常遇到的问题是反复进入同一场景后内存持续上涨。表面上是场景没有卸载干净实际上很可能是 YooAsset 的句柄没有释放。排查顺序是先看 Profiler 内存增长趋势再确认 AssetHandle 是否都在使用结束后被 Release。如果代码里有多处直接调用 LoadAssetAsync就容易漏掉 Release。解决方式是把加载做统一封装并在加载失败、加载成功、场景切换三条路径上都释放句柄。7.2 小游戏分包加载失败如果在微信小游戏环境里加载某个资源时提示找不到资源优先检查 YooAsset 的收集器是否把该资源打进了分包并确认加载路径和收集目录一致。小游戏的包体大小限制很严格资源如果被错误地放在首包之外加载时就会失败。检查方式是在 YooAsset 的构建窗口重新生成资源包并确认目标资源出现在对应的 Bundle 列表中。不要只改代码里的加载路径那通常不是根因。7.3 Profiler 帧率高但手感卡帧率高手感卡是移动端很典型的问题。Profiler 显示 60 FPS但角色移动有延迟可能原因包括垂直同步带来的输入缓冲、Fixed Timestep 与显示帧率不同步、GC 分配导致的微卡顿。排查时先打开 Profiler 的 Player Loop确认 FixedUpdate 和 Update 的耗时。如果 GC Alloc 持续增加优先处理高频物体生成和字符串拼接。帧率数字只反映最终结果不等于手感和输入响应。v0.1 版本记录里要保留这类现象后续优化才有对比基础。8. 下一步计划与复盘建议8.1 从 v0.1 到 v0.2 要解决的优先级v0.2 不会继续无脑加功能而是先把 v0.1 的欠账解决掉。当前优先级从高到低是这样排序的验证微信小游戏平台的完整资源加载流程确认分包策略可行。优化单局玩法的物理耗时让低端机也能稳定跑到目标帧率。把资源加载封装层的缓存和引用计数补齐避免内存问题继续积累。增加更完整的音效和 UI 反馈让玩法手感更明确。开始考虑存档、设置和关卡扩展但只做最小实现。这个顺序来自 v0.1 记录中的性能基线和遗留问题。版本规划如果脱离版本记录很容易变成“想做哪个就做哪个”这样开发日志就失去了规划工具的作用。8.2 给新手开发者的记录习惯建议如果你刚开始写游戏开发日志不要只记录“今天完成了什么功能”。可以尝试每一条记录都包含“为什么做、怎么实现、结果如何、卡点在哪”。这四条听起来简单但能逼着你想清楚每个版本的真实状态。一个最简单的习惯是每天收工前花十分钟写一条日志内容包括今天的版本号、一个新现象、一个排查路径、一个明天要验证的问题。哪怕只有几行积累一个月后再回看就能知道项目是如何一步步走到今天的。v0.1 版本记录就是在这种记录习惯下形成的。8.3 如果换用 Godot哪些经验可以迁移Godot 是另一个很受独立开发者关注的引擎。如果未来某个项目决定使用 Godot本文里的很多思路依然适用。关注点Unity3DGodot场景组织Prefab SceneScene PackedScene资源管理AssetBundle / YooAssetGodot Resource / 自研加载层脚本语言C#GDScript / C#帧率控制Application.targetFrameRateEngine.max_fps版本记录Git 标签 构建清单Git 标签 构建清单换用引擎后具体 API 会变但“先定版本目标、再管理资源、再记录性能基线”的节奏不会变。对独立游戏项目来说保持一致的版本记录习惯比纠结某个引擎本身更重要。v0.1 版本的最大收获不是功能列表有多长而是建立了一套能验证、能记录、能排错的开发节奏。下一个版本开始前先把这条日志里的遗留问题逐个解决再继续加新内容。只要每个版本都有清晰的目标和记录这个项目就能在后续迭代里保持可控。