Files
daluandou/CODELY.md
T
huadexuan d26d323912 ```
feat(materials): 删除TowerEnemy和TowerPlayer材质文件

移除项目中不再需要的TowerEnemy.mat和TowerPlayer.mat材质文件,
以及对应的.meta元数据文件。这些材质文件已通过其他方式重构或不再使用。
```
2026-09-23 22:26:01 +08:00

39 KiB
Raw Blame History

Codely Structured Memories

User

  • [2026-09-09 13:43:50] 用户是 10 年 Java 后端开发,可以提供后端接口,但当前项目处于原型验证阶段,暂不需要服务器。

Feedback

  • [2026-08-28 11:36:37] 用户偏好 Unity 操作分步骤执行:一次只做一个明确动作并先验证结果,避免连续执行大量工具调用导致超时。Why: 之前连续操作出现 Stream idle timeout。How to apply: Unity 场景、Prefab、组件和运行验证都采用“读取→单步修改→确认”的节奏。
  • [2026-08-30 22:44:50] 每实现一个角色技能,都要同步更新《场景和角色设计.md》文档末尾的角色与技能描述表格。Why: 用户希望实现进度与设计文档保持同步。How to apply: 后续新增或修改角色技能时,在同一任务中追加或更新对应表格行。
  • [2026-08-31 14:52:17] 角色配色应以自然、克制的主体色为主,每个角色加入一到两处对比度较强的颜色作为识别点,避免整体过于花哨或过于朴素。Why: 用户希望角色既有视觉记忆点,又保持统一、易建模的造型。How to apply: 后续角色提示词使用材质和种族决定主体配色,仅在围巾、护腕、局部毛色等少量位置加入强对比色。
  • [2026-08-31 15:30:02] 角色技能表中的攻击速度应以“普攻间隔(秒/次)”展示,而不是“次/秒”。Why: 用户更直观地关注单位每隔多少秒攻击一次。How to apply: 后续新增或调整角色数值时统一使用秒/次,并按间隔数值维护平衡。
  • [2026-09-01 14:10:12] 用户在 Unity 脚本或 Animator 问题排查中可优先要求“先改、不运行验证”,此时只执行读取、针对性修改和必要的编译/配置确认。Why: Play Mode 或视频验证容易触发 Stream idle timeout。How to apply: 除非用户明确要求运行验证,否则遇到类似超时后先不进入 Play Mode。
  • [2026-09-03 14:32:39] 眩晕状态特效应优先使用 Unity Particle System,并以星星贴图作为粒子,而不是用运行时复制多个 Sprite 作为最终实现。Why: 用户明确希望得到真正的粒子效果,Sprite 复制只能作为临时占位。How to apply: 后续制作眩晕及类似循环状态特效时,优先创建可复用的粒子 Prefab 并接入通用状态系统。
  • [2026-09-04 10:39:23] 后续所有角色图片生成提示词禁止出现米白色衣服,并一并排除象牙白、奶油白、乳白色及其他近似暖白色服装。Why: 用户明确要求角色服装不再使用米白色。How to apply: 新增或改写任何角色提示词时,服装与护甲优先使用明确的冷色、深色或自然色,并在提示词中写出排除项。
  • [2026-09-04 11:21:06] 角色辨识度优先依靠大轮廓、简化脸部、职业特征大色块和少量核心识别点,不依赖复杂细节或精细贴图;尤其要适配 2.5D 远距离显示。Why: 用户希望即使模型和贴图较粗糙,也能一眼识别角色职业与身份。How to apply: 后续角色提示词优先设计头部框架、面部符号、服装剪影和能力核心,控制小装饰与高频纹理。
  • [2026-09-04 14:12:02] 需要 Play Mode 验证时先询问用户,由用户手动点击 Play 并反馈结果,不要自动进入 Play Mode。Why: 可节约时间并避免 Unity 运行验证导致工具等待或超时。How to apply: Unity 动画、角色行为和运行时问题排查中,完成编辑态修改后停在编辑器等待用户验证。
  • [2026-09-05 10:16:49] Unity 运行验证默认不由助手自动进入 Play Mode;完成编辑态修改、编译和场景保存后,等待用户手动点击 Play 并反馈结果。Why: 用户希望避免运行验证导致等待或超时。How to apply: 角色、动画 Event 和技能接入任务优先做编辑态验证,除非用户明确要求自动运行测试。
  • [2026-09-09 12:11:59] 当用户明确指出现象和修复目标时,优先按用户给出的事实做针对性修改,不继续进行冗长排查。Why: 用户明确指出法师没有生成火球,并要求直接给新建火球 Prefab 补脚本。How to apply: 先读取目标资产确认,再执行最小必要修改;只有修改仍失败时才扩大排查范围。
  • [2026-09-09 13:43:50] 能量恢复速度应该更慢一些,用户建议改为 3 秒恢复 1 格。Why: 1 秒 1 格太快,不利于战斗节奏控制。How to apply: 召唤系统能量恢复速率应偏慢,给玩家资源压力。
  • [2026-09-09 20:37:24] 用户希望提前实现数据架构而非临时方案,即使当前阶段功能简单。Why: 用户有 10 年后端开发经验,理解数据分层的重要性,希望逐步完善而非推倒重来。How to apply: 对于有明确扩展方向的功能(升级、存档、联网),优先设计可扩展架构并临时写死数据,而非等需求明确后再重构。
  • [2026-09-10 18:38:45] 正交俯视视角(38-43°)下,垂直墙面几乎看不见(只能看到墙顶),因为墙面平行于视线方向被自身遮挡。适合的装饰物:高耸物体(旗帜、石柱)、有明显剪影的物体(木箱、碎石堆)、对比色强的物体;不适合:低矮平面物(矮墙、栅栏)、细长水平物(绳索)。Why: 这是正交俯视视角的固有盲区,无法通过调整角度完全解决(角度太平会牺牲战场全局视野)。How to apply: 场景装饰设计时优先使用垂直高度≥2米的物体,避免依赖水平或低矮结构。
  • [2026-09-14 18:24:56] 用户认可"参考游戏是基地离得远、镜头更远、单位推进慢"的观感方向(2026-09-14 数值改慢后反馈"好多了")。Why: 之前双方距离近+移速快,单位两三秒就接触,战斗缺乏观察窗口。How to apply: 后续地图/镜头调整优先加长双方距离、拉远摄像机;数值宁慢勿快。
  • [2026-09-16 22:18:14] 召唤系统:找不到合适位置时直接在召唤师前方强制生成,不显示警告,不退还能量。Why: 用户要求召唤必须成功,不被取消。How to apply: MainCharacterCombat.cs 的召唤逻辑
  • [2026-09-16 22:18:30] 召唤打断移动:主角点击召唤时必须立即停止移动,调用 SummonerClickMovement.ClearTarget() 来实现。Why: 用户要求召唤时即使在移动也要立刻停下。How to apply: BeginSummon 开始时停止移动
  • [2026-09-17 10:06:34] 召唤师移动后连续召唤动画超时问题:SummonerClickMovement.HandleMovement() 每帧设置 animator.SetInteger("speed", 1) 干扰召唤动画。Why: 即使召唤时调用了 ClearTarget(),下一帧 Update 还是会覆盖动画参数。How to apply: 召唤期间禁用移动脚本 (clickMovement.enabled = false),召唤完成后重新启用 (enabled = true)。已在 MainCharacterCombat.Summon() 和 FinishSummon() 中实现。
  • [2026-09-18 17:16:47] 小游戏阶段优先使用低成本的材质发光方案(Emission 球体 + 一层透明 Additive 光晕),不使用实时灯光、粒子系统和全屏 Bloom。Why: 用户关注小程序性能,且项目为内置渲染管线;Bloom 会影响整屏性能。How to apply: 后续制作阵营识别光球、传送门能量等发光效果时默认走材质光晕路线,仅在高端设备上考虑 Bloom。

Project

  • [2026-08-28 14:26:56] 弓箭手远程箭矢的设计要求:保持发射时高度水平飞行,命中目标后直接结算伤害并销毁,不产生实体物理击退。Why: 当前玩法希望远程攻击是命中判定而非物理推动。How to apply: 后续调整箭矢、Projectile 或弓箭手攻击逻辑时保持这一行为。

  • [2026-08-28 18:06:13] 小游戏对外名称确定为《召唤之战》,整体采用竖屏布局;主界面不需要“技能、背包、属性”入口或相关模块。Why: 备案与产品定位已确定,UI 需保持简洁并适配竖屏。How to apply: 后续设计备案图、主菜单或游戏 UI 时遵循此名称、方向和功能范围。

  • [2026-08-29 11:44:51] 《召唤之战》战斗设计倾向简化:单位解锁后立即拥有完整技能,升级只提升基础数值;战斗召唤栏采用底部正方形头像卡片,战斗场景第一版优先将背景图贴到现有 BattlePlatform,而非制作完整3D场景。

  • [2026-08-31 11:31:00] 角色图片生成统一采用 3D 卡通、非写实、单角色正视图;人形角色使用标准 A-pose,非人形角色使用稳定自然姿态。Why: 便于 3D 建模与动画制作,并符合《召唤之战》的视觉方向。How to apply: 后续新增各章节角色提示词时遵循该标准,并记录在《角色与技能说明.md》。

  • [2026-09-02 16:44:35] 主角定位确定为“召唤师优先、法师辅助”的人类召唤师,主要战斗力来自召唤单位,主角仅用基础法术补刀和牵制;视觉上需要通过召唤核心、学院符文和独特剪影与普通法师区分。Why: 保持召唤系统的核心地位并提高主角辨识度。How to apply: 后续主角技能、模型、动画和 UI 设计都应围绕召唤师身份展开。

  • [2026-09-02 23:50:59] 《召唤之战》状态效果方案确定:所有可控制单位共用 Stun/StatusEffect 系统,眩晕暂停当前 Animator 与战斗逻辑,使用通用头顶星星提示,重点角色以后再补专属眩晕动画。Why: 降低首版制作量并保持各单位行为一致。How to apply: 新增眩晕、减速、沉默等控制效果时优先扩展通用状态组件,不在技能脚本中直接操作具体角色动画。

  • [2026-09-03 18:09:56] 《召唤之战》大招统一在下一次普攻开始前判定:先通过现有寻敌逻辑获得有效目标,能量满则优先释放大招并消耗能量,跳过本次普攻;没有有效目标时不释放且保留能量。Why: 避免普攻命中击杀目标后仍立即触发大招。How to apply: 后续新增或修改角色技能时遵循该统一触发时机。

  • [2026-09-03 18:52:21] 《召唤之战》采用 2.5D 战斗呈现,角色设计需要在俯视斜角和远距离下保持清晰剪影与可读的大色块。Why: 用户希望角色在实际战斗镜头中仍容易区分。How to apply: 后续角色图片、模型、服装和特效设计优先考虑 2.5D 视角下的轮廓识别,不依赖细小装饰。

  • [2026-09-03 19:12:39] 角色图片提示词与游戏内装备分离:盾卫的角色本体图片必须明确不出现盾牌,塔盾作为独立武器/装备资产单独生成与配置。Why: 便于后续替换和挂载装备,避免角色模型自带盾牌影响游戏配置。How to apply: 后续生成盾卫或其他可换装角色图片时,只描述身体与服装本体,不把可独立配置的装备画进角色图。

  • [2026-09-06 22:14:43] 《召唤之战》当前先确定每关携带 5 种角色,战斗中固定显示 5 张召唤卡;UI 采用大框底图加独立可复用卡片、角色头像和运行时状态元素。Why: 先控制竖屏战斗界面复杂度并便于调试。How to apply: 后续召唤 UI、卡组和能量系统按 5 个固定卡位设计,不把动态文字、冷却和能量豆烘焙进静态图片。

  • [2026-09-09 12:23:17] 攻击系统已从动画结束 Event 改为攻击命中 Event 触发。UnitBase 通过 OnAttackEffect() 统一处理四种攻击类型:MeleeDirect(近战直接伤害,已实现)、RangedProjectile(远程锁敌飞行物,已实现)、MeleeArea(近战范围,预留)、RangedArc(远程抛物线,预留)。攻击动画结束由脚本自动检测 normalizedTime,不再依赖 OnAttackAnimationEnd Event。Why: 用户需要远程攻击等箭矢碰撞后才扣血,而非动画中途直接伤害。How to apply: 所有攻击动画只需在命中帧添加 OnAttackEffect Event;近战保持 MeleeDirect,远程单位设为 RangedProjectile 并配置 projectilePrefab/projectileSpawnPoint。

  • [2026-09-09 20:37:24] 召唤能量和冷却系统已完成,玩家角色数据架构已完成:ManaSystem 单例管理能量(最大 10,3 秒恢复 1 点),MainCharacterCombat 扩展能量检查(人类士兵消耗 2,弓箭手消耗 3),SummonCardButton 接入冷却逻辑(5 秒冷却,UI 显示遮罩和倒计时),能量豆 UI 已配置,冷却遮罩在非冷却时完全隐藏。CharacterData 支持基础属性和升级成长,PlayerCharacterData + PlayerDataManager 实现玩家角色等级和属性计算,召唤时传递最终属性给 UnitBase。

  • [2026-09-09 20:37:24] 玩家角色数据架构已完成:CharacterData 存储基础属性(1级)和成长值(每级加成),PlayerCharacterData 存储玩家角色等级和星级,PlayerDataManager 单例管理玩家拥有的角色和当前卡组(临时写死)。召唤时从 CharacterData + PlayerCharacterData 计算最终属性并传递给 UnitBase.InitializeFromPlayerData()。升级系统正常工作(1级 100血/50攻,3级 120血/60攻)。后续扩展:存档系统、卡组配置界面、升级界面、角色解锁、后端接口。

  • [2026-09-09 22:17:58] 第一关地图重新设计已完成:地图扩展到120单位(Z: -24到96),创建3个波次生成器(WaveSpawner)在Z=25/55/85,添加视觉标识物(旗帜、石柱、石墙)标记战斗区域。摄像机修正:旋转(43,0,0)位置(0,18,-5),朝向+Z方向与主角前进方向一致。召唤系统优化:初始状态无冷却遮罩,冷却时间从5秒改为1秒(能量已控制召唤频率)。

  • [2026-09-10 11:03:00] 第一章第一关地图(Level1-1.scene)已完成:120单位长地图(Z: -24到96),使用用户自制的6类真实3D模型装饰(石墙/木栅栏/旗帜/木箱/石柱/碎石堆),共34个物体分布在左右装饰带和3个波次标记位置。摄像机设置为2.5D视角(位置0,18,-5,旋转43°)。Why: 地图基础结构已完成,可以开始添加战斗逻辑和敌人生成器。How to apply: 后续关卡可复制此场景作为模板,调整装饰布局即可。

  • [2026-09-10 18:38:13] 第一关地图(Level1-1.scene)已采用"皇室战争"风格简化设计:移除所有边界矮墙(俯视角只能看到墙顶),改用旗帜+石柱交替排列标识边界(X=±5.5,Z轴8个位置交替);保留中间战道掩体(木箱×6、碎石堆×4);天空改为纯色蓝灰色+线性雾效(起始40m,结束100m);摄像机添加边界Clamp限制(X: -77, Z: -3293,宽松模式),主角靠近边界时摄像机停止跟随;光照调整为从后上方照射(50°, 0°, 0°),角色正面清晰可见。Why: 正交俯视视角下垂直墙面几乎看不见(只能看到墙顶),旗帜+石柱有高度和轮廓,视觉识别强。How to apply: 后续关卡延续此风格,避免使用低矮平面装饰物。

  • [2026-09-10 18:38:32] 召唤逻辑已优化碰撞处理:当目标位置被占用时,自动螺旋搜索周围空位(左右搜索8次×前后3层×2方向,约102个候选点);如果所有位置都被占用,自动退还能量豆并取消召唤,避免浪费能量。参数:summonSearchCount=8, summonDepthSearchCount=3, summonSearchStep=0.8f, summonDepthSearchStep=1f。

  • [2026-09-11 14:55:27] 敌人血条颜色问题已修复:WorldHealthBar 在 Awake() 时根据 GameObject.tag 判断颜色,WaveSpawner 在 Instantiate() 后设置标签会导致时序错误(血条已创建成绿色)。解决方案:直接在敌人 Prefab 上设置 Enemy 标签,确保 Awake() 时标签已正确。已修改狼人/蓝色怪物/弓箭猎人/石巨人四个 Prefab。Why: 血条颜色在对象创建时确定,后设置标签无法自动刷新。How to apply: 后续新增敌人 Prefab 时直接在 Prefab 上设置 Enemy 标签,不依赖运行时代码设置。

  • [2026-09-16 14:22:13] 2026-09-13 玩法大转向:从闯关推图改为"建筑生产+自动作战+主角辅助"的对攻玩法(见《召唤之战-核心玩法.md》)。旧闯关玩法由用户在另一台电脑的分支保存,当前 main 按新玩法开发。提交 beab4cf 已实现:GoldSystem/GoldMine 金币经济、Barracks 兵营产兵、BuildingPlacementManager 建筑摆放、CharacterData 新增 productionInterval/buildingCost、UnitBase/Projectile 支持攻击建筑、CoreBattleTest.scene 验证场景、CameraFollow 重写(WASD/鼠标/触摸拖动+缩放)。胜负目标改为摧毁对方主建筑。How to apply: 2026-09-16 起玩法进一步改为"召唤师对决"(见同日新条目),建筑/经济/产兵系统已封存、不再作为主线,相关脚本留作素材。

  • [2026-09-14 18:24:46] 2026-09-14 性能实测(9 个角色 Prefab):大多数 5~8k 三角面/22 骨骼/512 贴图,性能没问题;两个待处理异常——蓝色怪物 34408 面(是量产低价单位,建议减面到 8k 左右)、法师贴图 2048x2048(建议缩到 512)。另建议设计层限制每方场上单位上限(约15)保性能与 2.5D 可读性,并确认方向光关实时阴影,最终以低端安卓真机小游戏包为准。How to apply: 后续做性能优化或新增量产型敌人时按此基准控制面数。

  • [2026-09-14 21:19:53] 2026-09-13 新增建筑系统核心脚本:BuildingHealth(建筑血量+生产进度接口)、GoldSystem/GoldMine(金币经济与产出)、Barracks(兵营产兵,读取 CharacterData.productionInterval)。WorldHealthBar 增加 SetEnergy() 通用下方条接口,建筑复用该条显示生产进度,单位仍用于技能能量。BuildingPlacementManager 支持虚拟网格吸附、占位检测、金币扣除,新放置建筑自动挂 BuildingHealth。UnitBase/Projectile 的 ApplyDirectDamage/ApplySkillHit/ApplyAreaSkillDamage/HitTarget 均已接入 BuildingHealth,建筑可被近战/技能/范围/飞行物伤害。兵营 Prefab(Assets/Prefabs/建筑/兵营.prefab)已写入 Barracks+WorldHealthBar+BuildingHealth,默认阵营 Friend,场景实例保留 Enemy 覆盖。Why: 建筑作为可攻击目标是新对攻玩法的核心,生产进度条复用血条下方条避免额外 UI。How to apply: 后续新增建筑类型(防御塔/资源建筑)参照 BuildingHealth 接口;修改血条下方条逻辑时注意区分单位和建筑语义。

  • [2026-09-14 21:34:17] 2026-09-14 发现:团结引擎 1.10.2 (macOS) 原生 NavMesh 烘焙失效——空场景放一个静态 Cube,用 NavMeshBuilder.BuildNavMeshData / UpdateNavMeshDataAsync / 经典全局 BuildNavMesh 烘焙全部产出 0 三角形,无报错;收集源(CollectSources)、Job 系统、AI 模块包均正常;换构建目标/域重载/重启编辑器均无效。Why: 原生导航烘焙在此安装上深层失效,继续用 NavMesh 会浪费时间。How to apply: 本项目寻路不要用 NavMesh/NavMeshAgent/NavMeshSurface,改用纯 C# 网格 A*(见 GridPathfinder.cs);若未来升级团结版本可先重跑最小 Cube 烘焙测试再决定。

  • [2026-09-14 22:55:12] 2026-09-14 伤害数字系统(WorldHealthBar.SpawnDamageNumber + DamageNumber 组件)已上线:白字黑边样式(1 白主字 + 4 向偏移黑副本,TextMesh 无原生描边所以用副本组合),入口在 TakeDamage/Heal,全场并发上限 60。两个关键坑:1) TextMesh 可读面朝本地-Z,billboard 必须用 LookRotation(selfPos - cameraPos),方向写反会左右镜像;2) 同材质同 sortingOrder 的多个 TextMesh 渲染顺序不确定,后创建的黑色副本会盖住白字——必须显式分层:黑边 sortingOrder=60、白主字=61,白字必须最后创建或层级更高。Why: 用户要求白色黑边,先后修复了镜像和纯黑覆盖问题。How to apply: 后续做其他 3D 漂浮文字(暴击、金币)沿用 DamageNumber 模式、朝向写法和 sortingOrder 分层。

  • [2026-09-15 08:09:51] 2026-09-15 决战玩法(BattleTest.scene)布阵系统已实现:BattleSetupManager 单例管理 Setup/Battle/Ended 三状态。布阵阶段:己方半场 2x2 米虚拟网格(X:-88, Z:-20-8),底部 8 张卡片(代码生成 UI),点卡片选兵种→点格子放置(绿/红高亮预览),manaCost 作为人口消耗(上限 30),点已放单位可移除退人口。开战按钮生成敌方预设阵型(前排近战 Z=14 / 后排远程 Z=18,共 28 人口),全灭判定胜负(0.5 秒轮询)。SummonCardButton 已支持双模式:有 BattleSetupManager 走人口判断选兵,否则走金币建筑放置——两个场景共存互不干扰。Why: 用户确定决战玩法方向,网格布阵解决开局扎堆且让排兵布阵成为策略。How to apply: 后续决战玩法迭代(AI 阵型多样化、主角辅助技能、重开按钮)都基于 BattleSetupManager 扩展;不要在 CoreBattleTest 场景放 BattleSetupManager。

  • [2026-09-15 16:03:53] NavMesh 寻路已成功接入所有单位。团结引擎完全支持 NavMesh(需安装 com.unity.ai.navigation 包)。实现方式:1) 添加 NavMeshSurface 组件并烘焙;2) 为所有角色预制体添加 NavMeshAgent;3) 修改 UnitBase.cs 的 move() 方法优先使用 NavMeshAgent.SetDestination(),并在 Start() 中禁用 CharacterController 避免冲突。CoreBattleTest 场景已创建中央分隔墙形成左右两路,单位能够自动沿路线寻路并绕过障碍物。

  • [2026-09-15 17:33:54] NavMesh 寻路攻击漂移问题修复方案:单位攻击时会因 NavMeshAgent 继续工作而漂移。解决方法是在 attack() 方法和 Update() 的 State.Attack 分支中直接禁用 NavMeshAgent (navAgent.enabled = false),在 move() 方法中重新启用。同时修复了 applyGravity() 调用已禁用 CharacterController 导致的警告(添加 controller.enabled 检查)。性能优化:寻路路径更新频率限制为 0.5 秒一次(nextPathUpdateTime + PathUpdateInterval),减少 93% 路径计算开销。

  • [2026-09-15 18:42:26] 伤害数字显示规则:友方单位(Friend tag)受伤显示红色数字向下浮动,敌方单位(Enemy tag)受伤显示白色数字向上浮动,治疗显示绿色向上。技术实现:8方向黑色描边(DamageNumberOutlineWidth = 0.025f 常量)+ 1个彩色主字,共9个TextMesh。通过 gameObject.CompareTag("Friend") 判断受击者阵营。已更新到《召唤之战-核心玩法.md》文档 2.3 章节。

  • [2026-09-15 19:33:31] 金币系统已完成:GoldManager 单例管理,初始500金币,右上角UI实时更新。金矿建筑产出50金币/5秒,主角产出30金币/8秒。WorldHealthBar 的 currentEnergy 改为属性(带 setter 自动调用 UpdateEnergyFill),能量条尺寸从8像素增加到12像素(EnergyPixelHeight=12,EnergyPixelWidth=100)。能量条显示金币产出进度,满了产出并重置。已更新核心玩法文档。

  • [2026-09-16 14:22:13] 2026-09-16 玩法定稿为"召唤师对决"并已写入《召唤之战-核心玩法.md》:无基地/金矿/兵营/防御塔,玩家手动点地操控召唤师(移动不攻击、站定攻击),限己方半场(三分屏:己方/交战/敌方区),能量直购出兵(单位在召唤师身边生成),击杀敌方召唤师获胜,超时毒圈收缩并解除半场限制,中期混沌裂缝事件,召唤师技能 3~4 种,摇杆留作实测后升级项。Why: 用户多轮迭代后的最终方向,旧"建筑生产+自动作战"对攻玩法封存不删。How to apply: 新战斗开发一律基于召唤师对决方案;不要在新玩法场景引入金矿/兵营/建筑摆放;BuildingPlacementManager/Barracks/GoldMine 等封存留作后续建筑卡或 PVE 特殊关素材。

  • [2026-09-16 14:48:52] 召唤师对决首版场景已完成(SummonerDuelTest.unity,2026-09-16):新场景地面20×80、固定正交相机43°/orthoSize28、召唤师z=0(敌方z=35)均避开底部UI;新增 SummonerClickMovement(点地走位+clamp X[-9,9] Z[-19,6],移动中关攻击、到点恢复)、SummonerDuelManager(点卡片按能量直召,单位在召唤师身边生成)、UnitBase 新增 summonerMode 开关(不追击、站定攻击,默认关闭不影响旧单位);战斗界面UI从 CoreBattleTest 整树搬运复用,SummonCardButton 增加对决模式分支(无布阵/金币管理器时走能量直召+冷却)。主角已存为 Assets/Prefabs/主角/召唤师主角.prefab。How to apply: 后续对决玩法迭代(毒圈/胜负判定/召唤师技能)基于该场景与脚本扩展;Play Mode 验证等用户手动执行。

  • [2026-09-17 09:33:46] 阵营 ID 系统已实现(替代 Unity Tag 判断敌我):UnitTeam 组件标记 teamId,GameManager.LocalPlayerTeamId 标识本地玩家阵营,支持 PVP(真人 vs 真人 / 真人 vs 机器人)。Why: PVP 需要动态敌我判断,Tag 系统无法支持(双方客户端看到的 tag 矛盾)。How to apply: 所有敌我判断改用 UnitTeam.IsEnemy(),血条颜色用 IsLocalPlayerTeam(),新生成单位必须设置 teamId(Barracks/BattleSetupManager 已修改)。

  • [2026-09-17 09:33:58] 召唤师组件精简:移除了 NavMeshAgent、UnitBase、StatusEffectController,保留 MainCharacterCombat(战斗)+ SummonerClickMovement(移动)+ WorldHealthBar(血条)。SummonerClickMovement 已改为依赖 MainCharacterCombat 而非 UnitBase。Why: 召唤师是特殊单位,不应使用通用 UnitBase 逻辑;直线移动不需要 NavMesh。How to apply: 召唤师专属逻辑用 MainCharacterCombat,普通单位用 UnitBase。

  • [2026-09-17 09:34:13] 《召唤之战》场地规格:60×20(Z×X),三区划分各 20 单位 - 己方区 z∈[-30,-10](召唤师 z=-20),交战区 z∈[-10,10],敌方区 z∈[10,30](敌方召唤师 z=+20)。召唤师移动限制在己方区内(SummonerClickMovement clamp Z[-29,-11])。相机 orthoSize=22,位置(0,40,-40),角度 43°。Why: 竖屏竞技场设计,双方对称 40 单位间距,防风筝规则(召唤师不能进入交战区)。How to apply: 所有位置/spawn 相关代码使用新的 Z 坐标范围。

  • [2026-09-17 10:06:48] Projectile 伤害判定逻辑:HitTarget() 检查 UnitBase(普通单位)、BuildingHealth(建筑)、WorldHealthBar(召唤师等特殊单位)三种受击组件。召唤师使用 MainCharacterCombat + WorldHealthBar,不挂 UnitBase。Why: 召唤师是玩家控制的特殊单位,行为逻辑与普通 AI 单位不同。How to apply: 新增特殊单位必须有 WorldHealthBar 或 UnitBase 之一才能被攻击;法术球击中后调用对应组件的受伤方法(UnitBase.ReceiveDamage / WorldHealthBar.TakeDamage)。

  • [2026-09-17 10:38:49] 召唤师(MainCharacterCombat)与普通单位(UnitBase)的架构差异:召唤师使用 MainCharacterCombat + WorldHealthBar + StatusEffectController,不挂 UnitBase。Why: 召唤师是玩家控制的特殊单位,行为逻辑与 AI 单位不同。How to apply: 涉及单位的通用系统(伤害、眩晕、范围效果)必须同时支持 UnitBase 和非 UnitBase 路径。已修复:Projectile.HitTarget()、UnitBase.ApplyDirectDamage()、UnitBase.ApplyAreaStun() 均添加了 WorldHealthBar / StatusEffectController 的检测分支。

  • [2026-09-17 16:52:28] 已于2026-09-17新建分支转向拆家版玩法(以《召唤之战 - 核心玩法拆家版.md》V1.1为准),旧《召唤之战-核心玩法.md》召唤师对决文档作废。拆家版无主角:只做“选目标+点卡出兵”,单位从己方城堡出生并永久绑定目标。Why: 原地图太小导致打据点的兵被中路兵吸引成大混战。场景现状(按参考图十字布局定稿):CoreBattleTest平台40x70(Z 070),我方城堡Z=8/敌方城堡Z=62,纵向通道宽10(X±5)、横向通道高8(Z 3139),四角用4块障碍物Cube封锁(14x2x31,材质ObstacleBlock.mat,后续可换岩石/树林模型),中央圆柱已删;水晶矿(-14,1,35)/随机出兵点(14,1,35)为金矿模型占位(scale2),相机正交(55°, size36, pos(0,70,-14)),NavMesh已重烘;主角/GoldManager/GoldUI/BuildingPlacementManager已删。后续按拆家版开发:目标按钮UI→出生目标绑定→红蓝进度条据点系统。

  • [2026-09-18 17:17:04] 拆家版地图路线为"四边菱形外环 + 中央十字路网":我方主基地、水晶矿、敌方主基地、随机出兵点四点构成菱形,中央交叉区向四个顶点各连一条快捷路。Why: 用户希望主基地到资源点有直达路线并体现分路玩法。How to apply: 后续地图贴图、障碍物摆放和寻路区域设计必须同时保留四条外环边线和四条中心连接线,不能退化成单一十字或平行多路。

  • [2026-09-18 17:17:26] 主基地采用"一套共用模型 + 独立阵营视觉部件"方案:城堡主体、出兵门、炮台结构红蓝共用,仅中央核心、出兵门能量膜、炮台能量和徽记按 teamId 切换材质颜色。Why: 避免两套模型比例/挂点不一致并减少维护成本。How to apply: 后续制作或替换主基地资产时保持共用结构,阵营区分只走 TeamVisual 子节点材质。

  • [2026-09-18 22:37:49] 水晶矿血条/光球方案(2026-09-18 定稿):争夺血条 Canvas 在运行时创建于场景根(不挂水晶矿子级,规避 100 倍根缩放),血条高度由所有子 Renderer 世界包围盒顶部自动计算 + heightOffset 余量。AdjustableGlowOrb 同时控制主体球(_Color/_EmissionColor)和 GlowHalo 子渲染器(Legacy Additive 用 _TintColor + haloAlpha≈0.25)。CrystalMineCapture 新增 autoSetNeutralTeam 开关(拆家版设为 false,避免单位自动锁敌水晶矿);新增可选 riftVisual 字段同步裂缝颜色。随机出兵点也复用 CrystalMineCapture + RiftPortalVisual + BoxCollider。

  • [2026-09-18 20:13:29] 随机出兵点(拆家版)已复用水晶矿争夺系统:根节点挂 CrystalMineCapture(新增可选 riftVisual 字段)+ BoxCollider(8.3×6.5×8.3,按世界包围盒/100 配局部值,供飞行物命中),UnitTeam 在 Awake 自动补 teamId=2 中立。裂缝视觉 RiftPortalVisual 随争夺进度白/红/蓝变色(CrystalMineCapture.RefreshVisuals 同步驱动)。注意:PortalEnergyVisual(UV 滚动动画)已从随机出兵点能量膜移除但脚本保留——城堡出兵门能量膜仍在用它,勿删脚本;两个 [ExecuteAlways] 视觉脚本不要同时挂同一 Renderer(会互抢 MPB)。

  • [2026-09-19 09:52:40] 拆家版寻敌系统(2026-09-18):UnitBase.FindNearestOpponent() 改为两阶段——Phase1 在 detectionRange(默认25m)内搜索敌方战斗单位(跳过 Building Tag),Phase2 无敌方单位时搜索有 UnitTeam 的敌方建筑物(不限距离)。四个建筑统一挂 "Building" Tag:蓝/红城堡有 UnitTeam(teamId 0/1)+ BoxCollider,水晶矿/随机出兵点无 UnitTeam(中立不被自动锁敌)。旧 detectRange 字段已删除,替换为 detectionRange。NavMeshSurface 烘焙体积曾只覆盖 Z<40 导致红堡不可达,已扩为 center=(0,0,36.7) size=(50,10,70)。

  • [2026-09-18 22:37:49] 拆家版出兵系统(2026-09-18):CastleSpawnManager 单例管理从城堡出兵,SummonCardButton.OnClick/CanAfford 优先走 CastleSpawnManager(在 SummonerDuelManager 之前)。出兵点是城堡子对象(localPosition 需除以100补偿缩放),带绿色 Marker 球体需注意局部缩放反算。ManaSystem 能量系统直接复用。场景 CoreBattleTest 中无 SummonerDuelManager/MainCharacterCombat。

  • [2026-09-19 09:52:40] 拆家版建筑攻击修复(2026-09-18):单位不攻击建筑的根因是城堡无碰撞体+中心点距离永远超出判定。修复:IsWithinAttackReach 对 Building tag 目标用 Collider.ClosestPoint 计算到建筑表面的水平距离(不用半径扣减,会误判隔空攻击),攻击缓冲从 1.5 调到 0.2(用户要求贴近)。两座城堡已加 BoxCollider(编辑态保存,世界尺寸约12x12,局部值=世界值/100)。注意:用户移动建筑时碰撞体/序列化字段可能丢失,出问题先查碰撞体是否存在。

  • [2026-09-19 19:15:25] 拆家版双阵营攻击标志系统(2026-09-19 定稿含"出生即使命"):AttackTargetController 维护 blueTarget/redTarget 独立标志(各默认敌方主城堡,名字+LocalPlayerTeamId 反推,0.5s缓存重查)。点击建筑只切本地玩家阵营标志(点己方主城无效);双箭头并排显示(同建筑±1.1错开),颜色=标志所属阵营。单位使命快照:UnitBase.Start() 时 missionTarget = GetTeamTarget(teamId) 一次性快照,之后标志变化不影响场上单位(支持分兵);FindTarget() = Phase1 detectionRange内敌方单位 → Phase2 missionTarget(销毁时兜底敌方主城);到达使命建筑是己方阵营→该单位 missionTarget 改为敌方主城(不碰全局标志)。水晶矿/混沌之门根节点 CapsuleCollider(4.2/3.6米半径)。GetTeamTarget 仅供出生快照用,ResetTeamTargetToMainCastle 已删。

  • [2026-09-19 20:59:31] UnitBase 根运动架构(2026-09-19 定稿):applyRootMotion 全局 true,OnAnimatorMove() 统一协调——走路(agent 开):只叠加动画侧向摇摆(垂直朝向分量)+ root 转身差量,前向分量丢弃防双倍速,transform 变更后同步 navAgent.nextPosition;攻击/技能(agent 已禁用):根运动全量位移(前冲/后撤,垂直分量丢弃防漂离地面)+ 转身。死代码已删:CC 移动分支/applyGravity/getVerticalVelocity/ComputeSeparation/GetHorizontalCollisionRadius/randomTargetPos/range/gravity/useRootMotion/separationRadius/separationWeight/targetPos/startPos/controller 字段——所有单位统一 NavMeshAgent 寻路(CharacterController 从架构移除,但保留单位 Prefab 上的 CC 组件用于受击碰撞检测?不——CC 已不 disable 也不 enable,Projectile 靠它命中)。场景蓝色怪物实例已修:删 CC 加 NavMeshAgent,Y 归位 0.16。走路摇摆是烘焙在根骨骼上的动画,root motion 关闭时身体锁死只剩脚动("脚扭腰不动"现象)。

  • [2026-09-19 19:48:47] 拆家版NavMesh平坦化(2026-09-19):建筑模型网格被烘进NavMesh形成≤45°斜坡导致单位被抬上建筑(Y到2.15)。修复:创建Buildings层(layer 8),四个建筑(两城堡/水晶矿/混沌之门)整棵层级改入该层,NavMeshSurface layerMask排除Buildings(-257)后重烘→NavMesh恒定平坦Y=0.16。另在场景根级创建4个空物体"XX-寻路障碍"挂NavMeshObstacle(carving=true需显式设置,capsule半径=建筑CapsuleCollider世界半径)运行时挖空建筑足迹防单位穿模。障碍物体放场景根级而非建筑子级,避免100倍缩放歧义。平台顶面y=0.09,NavMesh烘焙时注意平台移动后必须重烘。

  • [2026-09-19 22:17:52] 单位贴地方案调整:UnitBase 不再根据 Renderer 包围盒最低点自动计算或延迟重设 NavMeshAgent.baseOffset,统一固定为 0,避免模型原点与脚底偏移被误当作寻路高度导致角色运行时整体抬升。

  • [2026-09-19 22:38:39] 2026-09-19 拆家版规则更新:水晶矿占领后按固定间隔为归属方增加1点能量,不改变基础能量回复速度;混沌之门自动产兵按当前出战卡组概率抽取,低费用卡高概率、高费用卡低概率。设计文档已同步,具体间隔和概率留待战斗测试。

  • [2026-09-20 13:36:59] 2026-09-20 三路测试布局已在 CoreBattleTest.scene 临时搭建:蓝堡/红堡居中,水晶矿 X=-10、混沌之门 X=10、Z=35;两条临时长方体屏障位于 X=-5 和 X=5,均带 BoxCollider 与 NavMeshObstacle carving,形成左/中/右三条路。

  • [2026-09-20 20:44:52] 2026-09-20 固定卡组与轮转已接入 CoreBattleTest:8卡组为人类士兵、弓箭手、盾卫、精锐士兵、法师、狂暴狼人、石巨人、弓箭猎人;底部显示4槽,出牌成功后当前卡进入队尾并由队列补下一张。BattleDeckCycle 挂在 CastleSpawnManager。当前弓箭猎人、狂暴狼人、石巨人的 CharacterData.unitPrefab 仍为空,暂不能正常出兵。

  • [2026-09-20 21:43:39] 2026-09-20 卡牌故障修复:8卡组中的弓箭猎人、狂暴狼人、石巨人已分别绑定第二章对应 Prefab,轮转不会再因 unitPrefab 为空而卡死;CastleMageSkill、ArcherSkill、ArcherHunterSkill 和 UnitBase 已移除废弃的 GetOpponentTag/OpponentTag,统一使用 UnitTeam 阵营判断。

  • [2026-09-21 11:10:20] 2026-09-21 UnitBase 目标锁定规则已更新:单位只有在没有有效目标时才寻敌;锁定后移动和攻击期间保持当前目标,新敌人不打断;当前目标死亡、失活或攻击状态下离开攻击范围时才解除锁定,下一帧重新寻敌。单位与建筑目标统一使用同一规则,并通过 WorldHealthBar.IsDead 判断死亡。

  • [2026-09-21 11:16:19] 2026-09-21 UnitBase 目标锁定规则修正:攻击状态一旦进入就不再寻敌,保持当前目标,避免多个单位奔向同一建筑时擦肩后切换目标。仅当当前目标死亡/失活,或因技能等原因不再满足攻击距离时才退出攻击状态;退出后才重新寻敌。单位和建筑目标统一使用同一规则。

  • [2026-09-21 14:26:28] 2026-09-21 据点目标规则修复:CrystalMineCapture 占领后会实时把 UnitTeam.teamId 改为蓝方/红方/中立;UnitBase.IsTargetValid 必须同时检查目标存活状态和目标是否仍属于敌方。出生使命建筑若已被己方占领或变为中立,应立即失效并回退攻击敌方主城堡。

  • [2026-09-22 10:58:17] 2026-09-21 远程弹道视觉方案调整建议:普通远程弹道继续使用 Projectile.cs 处理锁敌、飞行、碰撞和伤害;火球等圆形视觉优先使用 SpriteRenderer 始终朝向摄像机,不强制使用 Quad,以避免贴图方向难调。若有明显尾焰,再拆分核心 billboard 与按飞行方向旋转的尾焰层。

  • [2026-09-22 13:39:47] 2026-09-22 投射物斜向问题修复:UnitBase 发射普通攻击和技能投射物时,不再把骨骼下 attackPos.rotation 传给 Projectile 根节点,统一使用 Quaternion.identity;attackPos 只负责提供生成位置。原因是法师/弓箭手的 attackPos 挂在手骨骼下,会继承动画旋转导致火球和箭矢斜着出现。

  • [2026-09-23 22:13:21] 2026-09-23 角色黑色描边系统:Outline_Black.mat(Assets/Shader/Outline.shader,反向外扩 + Cull Front)以 SkinnedMeshRenderer 的 materials[1] 挂在全部 10 个角色 Prefab(人类士兵/弓箭手/法师/盾卫/精锐士兵/弓箭猎人/狼人/石巨人/蓝色怪物/召唤师主角),武器(短剑/盾牌/大剑/弓)不加描边。关键坑:_OutlineWidth 是物体空间数值,会被物体缩放放大,所以网格局部尺寸很小的模型描边会巨大化——蓝色怪物网格局部尺寸仅 0.02(被缩放约 160x),已改用专用材质 Outline_Black_小比例.mat(_OutlineWidth=0.0002)。零厚度平面(盾牌/大剑/弓)无法用反向外扩描边,会整块变黑或不可见,这是武器不描边的原因。已实测描边能跟随骨骼动画姿势。Why: 后续新增或替换角色模型时若局部缩放与 1 相差较大,必须同步调整描边宽度,否则整个模型会被黑色吞没。

Reference

  • [2026-09-09 12:23:17] 飞行物脚本 Projectile.cs 负责锁敌追踪、碰撞检测和伤害结算。箭矢预制体 ArrowProjectile_White.prefab 已配置 Projectile 组件和 CapsuleCollider(Is Trigger)。远程单位需在攻击动画松弦帧添加 OnAttackEffect Event,并在 UnitBase 中设置 attackType=RangedProjectile、projectilePrefab、projectileSpawnPoint。