游戏立项时期随笔记录(1)

模拟经营的项目还没有完全结束，这几天又有可能涉及到一个新项目。感想随笔记录一下，防止忘记。今天一天整理这个，搞得今天没时间看数学和AI。

在 Unity3D 游戏前端主程序的立项时期，核心目标是明确技术方向、评估可行性、搭建基础框架、规避风险，为后续开发奠定基础。以下是详细的工作清单（按优先级和逻辑顺序排列）：

一、需求与目标对齐（与策划 / 制作人同步）

1. 深度解读《立项文档》

   • 立项文档一般来自于制作人。明确核心玩法（如 ARPG / 开放世界 / 卡牌/模拟经营/塔防,核心玩法决定了游戏类型）、美术风格（卡通渲染 / 写实 PBR / 水墨，美术决定了视觉市场受众）、目标平台（PC / 手机 / 主机，这部分一般都会做多平台兼容，多平台兼容的工作非常琐碎）、性能指标（如移动端 60 帧、低端机 30 帧，这部分只能说理想和现实是有冲突的，性能优化是无止尽的，核心的优化，UI的优化，各方面的优化）。
   • 标注技术敏感点：如大世界无缝加载、多角色同屏战斗、物理交互（布料 / 刚体）、动态天气等，休闲对战。只会考虑核心玩法和几个重要的玩法，周边的功能立项时期一般指不会过于考虑，因为这部分的套路都是实际上是运营决定的赚钱套路，本质和游戏无关。一般一组功能遵循着“胚子数值 - 模块核心玩法 - 养成玩法 - 对应活动”的封装方式。可以无限扩展n组封装。
   • 接受到文档到，主程序需要解构文档为大致最小可行方案的可执行列表，文档不可量化，可执行列表才能估算工作量。立项阶段条件好的团队一般只有主程序 + 一个核心程序，小团队需要一个程序搞定立项阶段的所有事情。

2. 竞品技术拆解

   • 分析同类游戏的 Unity 实现方案，输出《技术对标报告》。
   • 重点关注引擎限制的各个点：如 Unity 的 Draw Call 优化、LOD 分级、Shader 变体控制。游戏体量决定着实现方式必然不同，一个人的项目分拆的过于细节化和深入意味着项目永远无法可以落地执行。同样类型的游戏，最终定位是微型，小型，中型还是大型项目，他们的实现必然不同。

二、技术预研与风险评估（核心任务）

1. 引擎版本选型与兼容性验证

   • 测试目标平台的 Unity 版本（如 2023.3LTS 对安卓 14 的适配），规避已知 Bug（如 URP 在某些 GPU 的渲染错误）。个人习惯了解最新的技术，但是一般不会去使用最新的技术，新技术意味着未必稳定，有一定的风险。程序实际上是游戏的支撑，稳定是第一要务。
   • 预研关键技术模块：
     • 渲染：HDRP/URP 选择（如果兼容移动端优先 URP）、自定义 Shader（如水体 / 毛发）的性能测试。如果个人没什么追求，中小型游戏其实可以不考虑很多性能问题。
     • 性能：内存泄漏预研（Mono/IL2CPP 对比）、GC 优化（对象池 / 结构体代替类）。
     • 框架：ECS（Hybrid/Entitas）是否引入？数据驱动架构（配置表热更）的设计。
   • 输出《技术可行性报告》，明确不可行项。注意主程序不但需要知道技术前沿的上限，也要知道自己的上限，某种意义上立项期间的最小化demo（实际上在非职业开发的角度来看，这就是一个完整的半成品游戏）。在当前的项目要求下，自己能做什么，不能做什么，估计的时间，一定要写在可行性报告里，如果心里没数，必然而且一定会导致项目delay。

2. 原型 Demo 开发（最小可行性验证）

   • 用 1个月时间开发垂直切片（不包括代码框架部分）：核心玩法 + 核心技术（如战斗镜头 + 技能特效 + UI 交互）。注意，一个项目一般不会去直接自己从0-1去写一套框架，框架是需要实际项目去验证的。我自己的经历是，框架是之前项目的经验总和，或者使用稳定的开源框架，或者从成功上线过的游戏中拆分出框架

   • 框架重点验证：
     • 场景加载耗时（AB 包策略、异步加载）。
     • 多线程优化（Job System 处理寻路 / AI）。
     • 热更新方案（ILRuntime/Huatuo）的集成测试。
   • 记录瓶颈数据（如 CPU/GPU 占用率、内存峰值），作为后续优化基准。
   • 实际游戏验证，这不到一个月的时间里需要和制作人和策划不停的对。

三、基础框架搭建（技术地基）

这部分在主程序实现demo的过程中应该已经可以形成一套行为模式，把这个模式标准化然后复制到每个组成员身上就可以。

1. 项目结构标准化

   • 目录规范：Assets/[Core (框架)/Game (玩法)/Tools/ThirdParty]，制定资源命名规则（如 UI_LoginBtn_Selected）。
   • 配置管理：接入 Git/GitLFS，分支策略（主干开发 + 特性分支）。
   • 比如：强制使用 Addressable 替代传统 AB 包，避免路径硬编码。

2. 核心框架设计

   • 模块拆分：EventCenter（事件总线）、PoolManager（对象池）、ResourceManager（资源加载）、UIManager（界面栈）。
   • 数据层：设计热更层与原生层的交互接口（如 C# 绑定 Lua/ILRuntime）。
   • 日志与监控：集成 APM 工具（如 Unity Profiler + 自定义性能看板），埋点记录 FPS、内存、卡顿帧。
   • 以上都是老生常谈。每个项目会应自身特点而生的特定基础框架模组，这个需要应需求来发，demo期间是不管遮这些的。

3. 工具链搭建

   • 自动化：编写编辑器脚本（如美术资源自动打标、配置表转代码）。
   • 协同：接入 Perforce 或 Plastic SCM，解决美术资源（FBX/PNG）的版本冲突。
   • 测试：集成 Playable Tests（自动化 UI 测试）、构建流水线（Jenkins/CircleCI），这部分需要测试团队做，如果没有那就自己手动打包吧，或者自己用python写个自动打包脚本。

四、资源与团队规划

1. 美术资源预规划

   • 与美术确认资源规范：贴图尺寸（UI 2048x2048、模型 1024x1024）、骨骼数量（角色≤100 根）、动画压缩格式（Hantro/Optimal）。
   • 制定《资源交付清单》：如首周需完成的 10 个 UI 预制体、3 个角色模型。
   • 对技术来说美术并非非完备不可。我负责的几个项目中一大半使用方块开始的，条件好的是素模。如果制作人觉得创意可行，那么才会继续投入资源继续推进。

2. 团队分工与开发规范

   • 前端组细分：渲染组（Shader / 后处理）、逻辑组（玩法系统）、工具组（编辑器扩展）。如果小团队，那就玩法先行是必须的，渲染和工具一遍搞一边做。但是基本渲染管线需要一开始确定，最基本的用默认管线也不是不可以。
   • 编码规范：强制使用 C# 9.0+、注释模板、错误处理（Try-Catch 记录堆栈）。
   • 制定《开发公约》：比如禁止在 Update 中做复杂计算，UI 事件统一走 EventCenter。

3. 里程碑与风险预案

   • 立项阶段里程碑：原型 Demo 通过、框架初稿完成（这个一般会注明框架来自哪里，使用过的上线项目）、首版性能报告输出（这个只是预计的，初版demo别指望性能完善）。
   • 风险预案：如渲染性能不足，备选方案为动态分辨率缩放或降低阴影质量。

五、文档与流程管理

        这部分并不是必须的，每个团队有自己的做法，有的团队干脆就是word说明，没技术文档。

1. 编写《技术设计文档（TDD）》

   • 包含：架构图、模块接口、性能指标、资源规范、工具链说明。

2. 制定《开发流程 SOP》

   • 提测标准：代码需通过 SonarQube 扫描、单元测试覆盖率≥70%。
   • 热更流程：Lua 脚本修改需经过灰度测试（AB 包分批次发布）。

六、立项评审与迭代

1. 组织立项评审会

   • 演示原型 Demo后，同步技术风险（如 “某个技术难点实现需要多久，另外需额外 2 人月优化”，零需要专人维护）。
   • 确认资源预算（如美术外包费用、引擎授权费）、排期（如 Alpha 版 6 - 9个月）。主程有时候确实会参加和技术无关的会议。

2. 建立迭代反馈机制

   • 每周同步技术债（如 “20 个未优化的 Shader 变体”），优先处理阻塞性问题。
   • 若原型 Demo 中发现 UI 渲染卡顿，立即启动 Canvas 动态合批方案预研。

总结

通过原型验证→结合框架落地→风险量化，确保前端主程序在开发初期 “走对路、少返工”（笑，不存在的，走对了路也会经常返工，demo期这很正常）。尤其注意性能前置（如在原型阶段发现内存和渲染的问题 - 一定会有的0-0）和结构规范先行（如果结构太乱，后期必然重构，不然无法维护。因为一般项目结构清晰的话，内部逻辑代码再怎么乱整个项目也会一目了然，猜也能猜出个大概。如果项目结构乱七八糟，以后自己找都找不到具体功能位置，乱了不便于管理。而不管项目成功与否，中后期的人员交替都是很正常的事，让新人便于查找功能位置，这是另外一个问题。）这是 Unity 项目后期维护的关键之一。