2026.05.22日报-刘鹏

用户2416

5月22日修改

一、工作概述

1.
完成订单系统和美术的基础包装​

2.
借鉴同组成员的工作流，对自身的原工作流做调整​

二、主要产出

2.1-完成订单系统和基础包装

2.1.1-订单系统：

订单系统运作逻辑

数据层：一个订单长什么样

OrderData.cs 定义了订单结构：

核心逻辑：OrderManager 做了什么

OrderManager.cs 是单例，负责全部订单逻辑：

1. 初始化时订阅棋盘事件

代码块

BoardEvents.OnMergeSuccess → 记录玩家最高合成等级

2. 检查是否能交付（CanFulfillOrder）

遍历棋盘所有格子，统计每种物品数量，对比订单所需 — 全部满足则可交付。​

3. 提交订单（TrySubmitOrder）

代码块

检查能否交付 → 从棋盘移除对应物品 → 发放金币/经验 → 标记完成 → 刷新新订单​

UI层：OrderUI 做了什么

OrderUI.cs：

•
最多显示 3 个订单卡片​

•
每张卡片布局：左侧人物头像 | 右上方奖励（金币/经验）| 右下方所需物品格子 + 交付按钮​

•
每 0.5 秒检查一次棋盘状态，更新按钮可否点击（橙色=可交付，灰色=物品不足）​

•
点击"交付"→ 调用 OrderManager.TrySubmitOrder​

•
订单完成后弹出奖励横幅（2.5秒后消失）​

完整链路总结

代码块

JSON配置加载 → ConfigManager缓存所有OrderData​
                    ↓​
OrderManager.Init() → 根据权重+难度+前置条件 选出3个活跃订单​
                    ↓​
玩家在棋盘合并物品 → OnMergeSuccess更新最高等级​
                    ↓​
OrderUI每0.5秒检查 → 棋盘物品够了就亮起"交付"按钮​
                    ↓​
玩家点"交付" → 从棋盘扣除物品 → 发金币/经验 → 标记完成 → 解锁后续订单 → 刷新列表​

关键设计： 订单解锁是链式的（UnlockOrderId），保证玩家按设计好的顺序推进内容。难度上限（最高等级+2）防止出现玩家根本做不到的订单。​

待完善的功能：

1.
订单的横向滑动和显示逻辑：目的是让游戏后期要显示多订单时，控制同时显示的数量，避免玩家目标混乱。​

2.
订单的刷新逻辑还需要进一步调研：调研的目标是确定订单的出现节奏、物品分配和奖励投放等细节设计点。​

2.1.2-基础包装：

目前尝试了三套claude生成Unity项目的UI布局方案

1.直接给游戏界面参考生成：界面具备大致的结构，但UI密集复杂的区域会发生色块混乱，无法正常布局UI​

2026.05.22日报-刘鹏​

2026.05.22日报-刘鹏