|
|
|
|
@ -0,0 +1,115 @@
|
|
|
|
|
### **个人项目总结与课程反思报告**
|
|
|
|
|
**项目名称**：《Living for the dream》回合制策略游戏开发
|
|
|
|
|
**担任角色**：主程序（底层框架设计+技能系统实现）兼副策划（系统设计优化）
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
### **1. 项目概述**
|
|
|
|
|
- **个人职责**：
|
|
|
|
|
- **主程序**：搭建游戏核心框架（数据层、逻辑层、控制器层），实现Ego系统、技能系统、攻击系统等核心模块。
|
|
|
|
|
- **副策划**：优化Ego机制设计，确保玩法与代码实现的可行性。
|
|
|
|
|
- **技术栈与工具**：
|
|
|
|
|
- 语言：C# 9.0（.NET Framework 4.7.1）
|
|
|
|
|
- 引擎：Unity
|
|
|
|
|
- 工具：Visual Studio（IDE）、GitHub（版本控制）、Excel（数据配置）
|
|
|
|
|
- 开发模型：瀑布模型
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
### **2. 项目实施过程**
|
|
|
|
|
#### **需求分析与设计**
|
|
|
|
|
- **核心机制设计**：
|
|
|
|
|
- 主导设计**Ego系统**（情感资源管理系统），将技能消耗、情感爆发/失控机制与先攻值关联，增强策略深度。
|
|
|
|
|
- 采用**模块化架构**：数据层（`GlobalData`）、逻辑层（`EgoMachine`/`SkillManager`）、控制器层（`IController`），确保职责分离。
|
|
|
|
|
- **设计质量保障**：
|
|
|
|
|
- 数据驱动：通过Excel配置静态数据（单位/技能），由`GlobalData`统一加载反序列化。
|
|
|
|
|
- 反射注册机制：支持动态扩展Ego/技能类型（新增方法自动注册，无需修改核心逻辑）。
|
|
|
|
|
|
|
|
|
|
#### **编码与实现**
|
|
|
|
|
- **关键技术实现**：
|
|
|
|
|
- **Ego系统**：
|
|
|
|
|
- 实现`EgoContainer`管理单位情感值，`EgoMachine`批量触发效果（如`TriggerEgo()`），`EgoExecutor`通过反射处理效果逻辑。
|
|
|
|
|
- 解决难点：情感爆发与消耗的时序控制（通过状态机管理情感阈值）。
|
|
|
|
|
- **技能系统**：
|
|
|
|
|
- `SkillManager`统一处理请求，`SkillExecutor`反射分发技能行为，支持批量执行（如`ExecuteSkill()`）。
|
|
|
|
|
- **数据交互**：
|
|
|
|
|
- 设计`RuntimeUnitData`动态继承`UnitData`，分离静态属性与运行时状态（如当前生命值）。
|
|
|
|
|
- **代码规范**：
|
|
|
|
|
- 遵循单例模式（`Manager`类）、MVC思想（UI与逻辑解耦），采用C#命名规范，关键模块注释覆盖率>90%。
|
|
|
|
|
|
|
|
|
|
#### **测试与迭代**
|
|
|
|
|
- **测试策略**：
|
|
|
|
|
- 单元测试：核心逻辑（如Ego增减、伤害计算）通过Mock数据验证。
|
|
|
|
|
- 缺陷管理：GitHub Issues跟踪Bug，但因时间限制，异常处理覆盖不足（如空引用校验缺失）。
|
|
|
|
|
- **迭代问题**：
|
|
|
|
|
- 前期设计未明确UI交互逻辑，导致后期对接困难（如`Powerable`组件与UI层通信冗余）。
|
|
|
|
|
|
|
|
|
|
#### **项目管理**
|
|
|
|
|
- **进度与协作**：
|
|
|
|
|
- **计划缺陷**：瀑布模型导致需求冻结后难以调整（如后期无法加入新功能）。
|
|
|
|
|
- **沟通机制**：腾讯会议+实验室线下对接，但进度管理松散。
|
|
|
|
|
- **协作痛点**：
|
|
|
|
|
- 部分成员不熟悉Unity，需本人临时调整分工并协助修复Bug（如数据加载失败问题）。
|
|
|
|
|
- 个人时间冲突（竞赛/面试）影响协调效率，导致部分模块延期。
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
### **3. 贡献与达成度**
|
|
|
|
|
- **个人贡献**：
|
|
|
|
|
- 代码量：约2000行。
|
|
|
|
|
- 关键成果：
|
|
|
|
|
- 实现**数据驱动架构**：支持Excel配置→二进制数据→运行时动态生成。
|
|
|
|
|
- 构建**高扩展性框架**：Ego/技能/攻击系统可通过反射无侵入扩展。
|
|
|
|
|
- **目标达成度**：
|
|
|
|
|
- **超额完成**：核心战斗逻辑（Ego机制、技能系统）、数据层可扩展性。
|
|
|
|
|
- **未完成部分**：Buff系统深度交互、完整事件消息机制（因UI对接问题搁置）。
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
### **4. 问题与改进**
|
|
|
|
|
#### **技术层面**
|
|
|
|
|
- **未解决难点**：
|
|
|
|
|
- 全局单例过多（如`XxxManager`），导致模块耦合（如`PowerManager`直接调用`AttackManager`）。
|
|
|
|
|
- 缺乏统一事件系统，跨模块通信依赖直接调用。
|
|
|
|
|
- **改进方向**：
|
|
|
|
|
- 引入**事件总线**（如C# `Action`委托）解耦模块。
|
|
|
|
|
- 更加深入探索ECS架构，减少单例模式依赖，提升并发能力。
|
|
|
|
|
|
|
|
|
|
#### **协作层面**
|
|
|
|
|
- **痛点实例**：
|
|
|
|
|
- 成员不熟悉Unity，导致`GlobalData`反序列化错误频发（需本人紧急修复）。
|
|
|
|
|
- 瀑布模型缺乏灵活性，无法响应后期策划案变更。
|
|
|
|
|
- **改进策略**：
|
|
|
|
|
- 采用**敏捷开发**：拆分双周迭代目标，每日站会同步风险。
|
|
|
|
|
- 技术预研：新成员需完成Unity基础培训后再参与开发。
|
|
|
|
|
|
|
|
|
|
#### **管理层面**
|
|
|
|
|
- **当前工具与局限**：
|
|
|
|
|
- **GitHub**（代码管理）：
|
|
|
|
|
- *优势*：行业标准、PR/Issue跟踪完善；
|
|
|
|
|
- *局限*：Git Bash操作门槛高（如冲突解决）。
|
|
|
|
|
- **未来改进方案**：
|
|
|
|
|
- **GitHub升级**：
|
|
|
|
|
- 用**GitHub Desktop**图形工具替代Bash；
|
|
|
|
|
- 集成**AI工具**辅助Git指令（如“如何撤销提交”）。
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
### **5. 课程反思**
|
|
|
|
|
#### **课程收获**
|
|
|
|
|
- **硬技能**：
|
|
|
|
|
- 掌握**数据驱动设计**：通过Excel配置动态生成游戏数据。
|
|
|
|
|
- 深入**反射机制**应用：实现模块自动注册，提升扩展性。
|
|
|
|
|
- **软技能**：
|
|
|
|
|
- 技术决策能力：权衡架构优劣（如单例模式 vs. 依赖注入）。
|
|
|
|
|
- 危机处理：快速定位并修复团队阻塞性问题（如数据加载异常）。
|
|
|
|
|
|
|
|
|
|
#### **课程改进建议**
|
|
|
|
|
- **实践优化**：
|
|
|
|
|
- **强化流程了解**：在课程项目启动到验收的过程中更多地了解引导学生进行更加科学合理的开发
|
|
|
|
|
- **加深工具科普教学**：比如教授Git分支管理、Code Review工具（如GitHub PR）,以及Copilot学生认证使用之类的实用开发辅助工具
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
**总结**：
|
|
|
|
|
本项目通过模块化架构与反射机制实现了高扩展性的游戏框架，但瀑布模型的僵化性和团队协作问题暴露了开发流程的不足。未来需拥抱敏捷方法，并通过事件系统解耦架构。课程若能加强现代工程实践培训，将更契合工业需求。
|
张佳辉