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

关于Demo制作的技术流程

这部分没有什么可说的，前端先行，不需要后端。前端也不需要做网络部分的开发，用8-10天做项目的外壳。这部分策划给个粗放的设计，主要是UI和UE的演示，美术给点基本素材就能开动，战斗用空场景代替就可以。

有时候粗放的设计都没有，直接找个老产品复刻大型，总之外壳这东西这样也能做就是了。

策划设计好战斗大型后，再开始往战斗场景内塞内容。在这之前框架，UI的选择要做好。如果真做了个家庭作业式的demo，立项成功后肯定要把立项期间工作重新来一遍。

关于框架

框架列表，除去自有的代码库外，线上有一系列成熟框架可选。

一、核心架构框架

1. Unity Game Framework

   • 特点：官方生态中的轻量级框架，提供模块化架构设计，适合中小型项目快速搭建基础功能。
   • 优势：
     • 资源管理：内置 AssetBundle 编辑工具，支持热更新与资源分包。
     • 数据驱动：通过 Excel 配置数据表，结合代码生成工具简化数据读取。
     • 流程控制：基于有限状态机（FSM）管理游戏流程（如登录、关卡切换）。
   • 适用场景：独立游戏、原型开发或需要快速迭代的项目。
   • 学习资源：官网教程 | GitHub 示例（部分模块兼容）。

2. QFramework

   • 特点：社区流行的轻量级框架，支持 MVC / 分层架构，提供 UIKit、ResKit 等实用工具。
   • 优势：上手快，适合快速实现界面管理、事件驱动和资源加载。
   • 适合场景：中小型项目、需要灵活扩展的团队。

3. Entitas

   • 特点：基于 ECS（实体 - 组件 - 系统）模式，适合高性能 3D 项目。
   • 优势：数据驱动，内存管理高效，适合复杂逻辑或多人在线游戏。

二、工具型框架

1. UniTask

   • 功能：异步编程库，替代 C# 原生 async/await，支持 Unity 特定操作（如 WaitForSeconds）。
   • 优势：轻量、高效，避免协程性能开销。

2. Addressables

   • 功能：官方资源管理框架，支持 AB 包动态加载与版本控制。
   • 优势：优化内存管理，适合上线项目的资源分包。

3. C# Job System

   • 功能：多线程处理框架，利用 CPU 多核性能加速计算密集型任务（如路径寻路、物理模拟）。

三、网络框架

1. Photon Engine

   • 功能：商业级多人联机解决方案，支持 P2P 和服务器权威模式。
   • 优势：文档完善，适合实时对战、MMO 等复杂网络需求。

2. Mirror

   • 功能：开源网络框架，基于 Unity 的 HLAPI，轻量灵活。
   • 适合场景：中小型联机项目，如休闲游戏或独立游戏。

四、UI 与交互框架

1. FairyGUI

   • 功能：可视化 UI 编辑器，支持复杂动画和交互逻辑，导出为 UGUI 预制体。
   • 优势：高效开发重度 UI 项目（如 RPG、SLG），这玩应很好，拼UI的工作可以扔给非程序人员。

2. UGUI 框架模板

   • 功能：基于 UGUI 的轻量级框架，提供界面栈管理、对象池复用等功能。
   • 优势：适合中小项目快速搭建 UI 层级。

五、其他实用工具

• ILRuntime/Xlua：热更新方案，适合需要频繁迭代的项目。
• HDRP/URP：渲染管线框架，优化不同平台的画面表现。
• DOTS（数据导向技术栈）：提升性能，支持大规模数据处理。

六、框架选择建议

大部分的休闲游戏属于“重度 UI 项目”

七、注意事项

1. 适配性：

   • 适合已有一定 Unity 基础的团队，需注意与第三方插件的兼容性（如 Photon、Addressables）。

   • 很多开源框架官方文档较基础，复杂功能需结合社区案例扩展（如 QQ 群、GitHub 讨论区）。

2. 技术债务管理：

   • 避免过度依赖旧版本 Unity 的向后兼容性，定期重构代码以适配新版本特性（如 DOTS、URP）。
   • 优先使用官方工具（如 Addressables、UGUI）减少维护成本。

3. 多平台优化：

   这部分细节太多，可以单独开一篇了，项目结束后总结。

通过合理选择框架组合，开发者可高效构建可扩展的游戏架构，平衡开发效率与项目复杂度。

关于UI

UI放在战斗之前说，因为这东西确实很重要。如果自己有项目验证过的UGUI解决方案，并且新人易于学习，那么直接用就好了。至于UIToolKit，我至今没在商业项目上用过。认识的人中有用过的，但是有坑没踩过去。

如果没验证过或者新人学起来不容易，用NGUI或者FGUI，这两者相对不需要做太多的优化工作。

UGUI使用相对比较好用的库也可以比如：

• Unity-UI-Framework：这是一个在 GitHub 上开源的基于 UGUI 的框架模板。它包含界面管理、上下文栈、动画控制等核心功能，支持动态加载 UI 预制体，通过UIType枚举管理界面路径，简化了界面跳转逻辑。还提供了GridScroller组件来优化滑动列表性能，支持无限滚动和对象池复用。
• QFramework UIKit 模块：作为 QFramework 框架的一部分，UIKit 提供了 UI 界面管理、事件绑定和模块化设计功能。通过UIKit可以实现界面生命周期管理（如OnEnter/OnExit），支持 MVC 模式，方便开发者构建复杂的 UI 系统。

关于战斗

战斗这东西算是所有游戏的核心，有人说模拟经营没有战斗 - 其实模拟经营的战斗就是经营的模拟，只是表现方式不同。不管是什么游戏类型有两个东西是不会变 - 技能和Buff -_-!。

demo期间一开始就必须和策划沟通好。商业游戏开发团队成熟，资深的策划一开始就会给到成型的数值结构模板，基本不需要改动，程序根据表格来实现完成就可以。

关于技能编辑器这个东西是可视化操作，人力不足的情况下先不做，甚至可以上线后加人后补。前期完全可以和约定好数据公约策划来手填。

通用核心

1. 技能

   • 范围攻击：通过配置表定义技能半径、持续时间、伤害逻辑，并支持动态插入事件（如初始化、伤害计算、特效触发）。如果是定向范围攻击，利用点乘叉乘算出范围内对象的方向就可以
   • 点对点攻击：展示不同技能类型的独立处理逻辑，支持自定义属性与流程。

2. Buff 

   • 加成 Buff：通过配置表设置加成系数、冷却时间与持续时间。
   • 状态 Buff：支持瞬发和持续类型，多 Buff 叠加机制，支持动态状态切换。

通用设计需求

1. 技能系统需求

   • 分类模板化：为不同技能类型（如区域、单体）提供通用计算模板，允许通过重载关键节点实现特殊逻辑。
   • 流程可扩展性：定义技能生命周期，也支持在技能生命周期中插入自定义事件。

2. Buff 系统需求

   • 多 Buff 叠加：支持同一角色同时应用多个 Buff，自动处理属性叠加与冲突。
   • 动态属性扩展：通过配置表轻松添加新 Buff 类型（如攻击、防御、搜索半径加成）。

3. 核心设计理念

   • 机制与数据分离：将技能 / Buff 的通用机制与具体逻辑解耦，通过配置表和模板实现灵活扩展。
   • 最小侵入性扩展：新增技能 / Buff 时，只需修改模板或配置表，无需改动底层框架。

可扩展性

1. 技能配置表

   • 定义技能 ID、动画、特效、半径、持续时间等基础属性。
   • 通过时间轴（Time Stamp）配置事件节点（如 Init、CalculateDamage），支持自定义事件扩展。

2. Buff 配置表

   • 定义加成系数、冷却时间、持续时间、消耗条件（如蓝量、红量）。
   • 支持多类型属性叠加，通过配置表实现不同 Buff 的组合效果。

工作量大概6周左右，但实际上可能时间会更长。如果算上不断返工，其实成型时间很难估计。所以一般游戏立项都是在老项目进行的同时来做。（差不多快立项成功了，才会抽专人做，这时候就要开始核算成本）。