perf: 优化底图可走路径
This commit is contained in:
richarjiang
167
.kilocode/rules/memory-bank-instructions.md
Normal file
167
.kilocode/rules/memory-bank-instructions.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# Memory Bank
|
||||
|
||||
I am an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional. The memory bank files are located in `.kilocode/rules/memory-bank` folder.
|
||||
|
||||
When I start a task, I will include `[Memory Bank: Active]` at the beginning of my response if I successfully read the memory bank files, or `[Memory Bank: Missing]` if the folder doesn't exist or is empty. If memory bank is missing, I will warn the user about potential issues and suggest initialization.
|
||||
|
||||
## Memory Bank Structure
|
||||
|
||||
The Memory Bank consists of core files and optional context files, all in Markdown format.
|
||||
|
||||
### Core Files (Required)
|
||||
1. `brief.md`
|
||||
This file is created and maintained manually by the developer. Don't edit this file directly but suggest to user to update it if it can be improved.
|
||||
- Foundation document that shapes all other files
|
||||
- Created at project start if it doesn't exist
|
||||
- Defines core requirements and goals
|
||||
- Source of truth for project scope
|
||||
|
||||
2. `product.md`
|
||||
- Why this project exists
|
||||
- Problems it solves
|
||||
- How it should work
|
||||
- User experience goals
|
||||
|
||||
3. `context.md`
|
||||
This file should be short and factual, not creative or speculative.
|
||||
- Current work focus
|
||||
- Recent changes
|
||||
- Next steps
|
||||
|
||||
4. `architecture.md`
|
||||
- System architecture
|
||||
- Source Code paths
|
||||
- Key technical decisions
|
||||
- Design patterns in use
|
||||
- Component relationships
|
||||
- Critical implementation paths
|
||||
|
||||
5. `tech.md`
|
||||
- Technologies used
|
||||
- Development setup
|
||||
- Technical constraints
|
||||
- Dependencies
|
||||
- Tool usage patterns
|
||||
|
||||
### Additional Files
|
||||
Create additional files/folders within memory-bank/ when they help organize:
|
||||
- `tasks.md` - Documentation of repetitive tasks and their workflows
|
||||
- Complex feature documentation
|
||||
- Integration specifications
|
||||
- API documentation
|
||||
- Testing strategies
|
||||
- Deployment procedures
|
||||
|
||||
## Core workflows
|
||||
|
||||
### Memory Bank Initialization
|
||||
|
||||
The initialization step is CRITICALLY IMPORTANT and must be done with extreme thoroughness as it defines all future effectiveness of the Memory Bank. This is the foundation upon which all future interactions will be built.
|
||||
|
||||
When user requests initialization of the memory bank (command `initialize memory bank`), I'll perform an exhaustive analysis of the project, including:
|
||||
- All source code files and their relationships
|
||||
- Configuration files and build system setup
|
||||
- Project structure and organization patterns
|
||||
- Documentation and comments
|
||||
- Dependencies and external integrations
|
||||
- Testing frameworks and patterns
|
||||
|
||||
I must be extremely thorough during initialization, spending extra time and effort to build a comprehensive understanding of the project. A high-quality initialization will dramatically improve all future interactions, while a rushed or incomplete initialization will permanently limit my effectiveness.
|
||||
|
||||
After initialization, I will ask the user to read through the memory bank files and verify product description, used technologies and other information. I should provide a summary of what I've understood about the project to help the user verify the accuracy of the memory bank files. I should encourage the user to correct any misunderstandings or add missing information, as this will significantly improve future interactions.
|
||||
|
||||
### Memory Bank Update
|
||||
|
||||
Memory Bank updates occur when:
|
||||
1. Discovering new project patterns
|
||||
2. After implementing significant changes
|
||||
3. When user explicitly requests with the phrase **update memory bank** (MUST review ALL files)
|
||||
4. When context needs clarification
|
||||
|
||||
If I notice significant changes that should be preserved but the user hasn't explicitly requested an update, I should suggest: "Would you like me to update the memory bank to reflect these changes?"
|
||||
|
||||
To execute Memory Bank update, I will:
|
||||
|
||||
1. Review ALL project files
|
||||
2. Document current state
|
||||
3. Document Insights & Patterns
|
||||
4. If requested with additional context (e.g., "update memory bank using information from @/Makefile"), focus special attention on that source
|
||||
|
||||
Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on context.md as it tracks current state.
|
||||
|
||||
### Add Task
|
||||
|
||||
When user completes a repetitive task (like adding support for a new model version) and wants to document it for future reference, they can request: **add task** or **store this as a task**.
|
||||
|
||||
This workflow is designed for repetitive tasks that follow similar patterns and require editing the same files. Examples include:
|
||||
- Adding support for new AI model versions
|
||||
- Implementing new API endpoints following established patterns
|
||||
- Adding new features that follow existing architecture
|
||||
|
||||
Tasks are stored in the file `tasks.md` in the memory bank folder. The file is optional and can be empty. The file can store many tasks.
|
||||
|
||||
To execute Add Task workflow:
|
||||
|
||||
1. Create or update `tasks.md` in the memory bank folder
|
||||
2. Document the task with:
|
||||
- Task name and description
|
||||
- Files that need to be modified
|
||||
- Step-by-step workflow followed
|
||||
- Important considerations or gotchas
|
||||
- Example of the completed implementation
|
||||
3. Include any context that was discovered during task execution but wasn't previously documented
|
||||
|
||||
Example task entry:
|
||||
```markdown
|
||||
## Add New Model Support
|
||||
**Last performed:** [date]
|
||||
**Files to modify:**
|
||||
- `/providers/gemini.md` - Add model to documentation
|
||||
- `/src/providers/gemini-config.ts` - Add model configuration
|
||||
- `/src/constants/models.ts` - Add to model list
|
||||
- `/tests/providers/gemini.test.ts` - Add test cases
|
||||
|
||||
**Steps:**
|
||||
1. Add model configuration with proper token limits
|
||||
2. Update documentation with model capabilities
|
||||
3. Add to constants file for UI display
|
||||
4. Write tests for new model configuration
|
||||
|
||||
**Important notes:**
|
||||
- Check Google's documentation for exact token limits
|
||||
- Ensure backward compatibility with existing configurations
|
||||
- Test with actual API calls before committing
|
||||
```
|
||||
|
||||
### Regular Task Execution
|
||||
|
||||
In the beginning of EVERY task I MUST read ALL memory bank files - this is not optional.
|
||||
|
||||
The memory bank files are located in `.kilocode/rules/memory-bank` folder. If the folder doesn't exist or is empty, I will warn user about potential issues with the memory bank. I will include `[Memory Bank: Active]` at the beginning of my response if I successfully read the memory bank files, or `[Memory Bank: Missing]` if the folder doesn't exist or is empty. If memory bank is missing, I will warn the user about potential issues and suggest initialization. I should briefly summarize my understanding of the project to confirm alignment with the user's expectations, like:
|
||||
|
||||
"[Memory Bank: Active] I understand we're building a React inventory system with barcode scanning. Currently implementing the scanner component that needs to work with the backend API."
|
||||
|
||||
When starting a task that matches a documented task in `tasks.md`, I should mention this and follow the documented workflow to ensure no steps are missed.
|
||||
|
||||
If the task was repetitive and might be needed again, I should suggest: "Would you like me to add this task to the memory bank for future reference?"
|
||||
|
||||
In the end of the task, when it seems to be completed, I will update `context.md` accordingly. If the change seems significant, I will suggest to the user: "Would you like me to update memory bank to reflect these changes?" I will not suggest updates for minor changes.
|
||||
|
||||
## Context Window Management
|
||||
|
||||
When the context window fills up during an extended session:
|
||||
1. I should suggest updating the memory bank to preserve the current state
|
||||
2. Recommend starting a fresh conversation/task
|
||||
3. In the new conversation, I will automatically load the memory bank files to maintain continuity
|
||||
|
||||
## Technical Implementation
|
||||
|
||||
Memory Bank is built on Kilo Code's Custom Rules feature, with files stored as standard markdown documents that both the user and I can access.
|
||||
|
||||
## Important Notes
|
||||
|
||||
REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
|
||||
|
||||
If I detect inconsistencies between memory bank files, I should prioritize brief.md and note any discrepancies to the user.
|
||||
|
||||
IMPORTANT: I MUST read ALL memory bank files at the start of EVERY task - this is not optional. The memory bank files are located in `.kilocode/rules/memory-bank` folder.
|
||||
108
.kilocode/rules/memory-bank/architecture.md
Normal file
108
.kilocode/rules/memory-bank/architecture.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# 系统架构
|
||||
|
||||
## 整体架构
|
||||
|
||||
项目采用组件化架构，基于 Cocos Creator 3.8.7 的实体组件系统（ECS）设计。
|
||||
|
||||
## 核心模块
|
||||
|
||||
### 1. 寻路系统
|
||||
- **TiledMapPathfinder** (`assets/scripts/TiledMapPathfinder.ts`)
|
||||
- 瓦片地图寻路管理器
|
||||
- 负责世界坐标与瓦片坐标转换
|
||||
- 集成A*算法进行路径计算
|
||||
- 提供路径平滑功能
|
||||
|
||||
- **AStarPathfinding** (`assets/scripts/AStarPathfinding.ts`)
|
||||
- 纯A*算法实现
|
||||
- 支持8方向移动
|
||||
- 包含对角线移动的墙角检测
|
||||
- 可配置的移动代价
|
||||
|
||||
### 2. 玩家控制系统
|
||||
- **PlayerController** (`assets/scripts/PlayerController.ts`)
|
||||
- 核心游戏逻辑控制器（1455行）
|
||||
- 处理触摸输入和玩家移动
|
||||
- 管理动画状态切换
|
||||
- 实现战斗逻辑
|
||||
- 处理道具收集和升级系统
|
||||
- UI弹窗管理
|
||||
|
||||
### 3. 相机系统
|
||||
- **CameraFollow** (`assets/scripts/CameraFollow.ts`)
|
||||
- 平滑相机跟随
|
||||
- 地图边界限制
|
||||
- 可配置的跟随速度和偏移
|
||||
- 支持初始焦点设置
|
||||
|
||||
### 4. 游戏管理
|
||||
- **Manager** (`assets/scripts/Manager.ts`)
|
||||
- 游戏初始化管理
|
||||
- 组件间协调
|
||||
- 地图信息管理
|
||||
|
||||
- **Start** (`assets/scripts/Start.ts`)
|
||||
- 资源分包加载
|
||||
- 场景跳转管理
|
||||
|
||||
### 5. 辅助组件
|
||||
- **Shadow2D** (`assets/scripts/Shadow2D.ts`)
|
||||
- 2D阴影效果渲染
|
||||
- **PathfindingTest** (`assets/scripts/PathfindingTest.ts`)
|
||||
- 寻路系统测试工具
|
||||
|
||||
## 数据流
|
||||
|
||||
```
|
||||
用户触摸输入 → PlayerController → TiledMapPathfinder → AStarPathfinding
|
||||
↓
|
||||
动画系统 → 相机跟随 → UI更新
|
||||
↓
|
||||
碰撞检测 → 战斗逻辑 → 游戏状态更新
|
||||
```
|
||||
|
||||
## 关键设计模式
|
||||
|
||||
### 1. 组件模式
|
||||
- 利用Cocos Creator的组件系统实现模块化
|
||||
- 每个功能独立封装为组件
|
||||
|
||||
### 2. 观察者模式
|
||||
- 碰撞事件监听
|
||||
- 动画完成事件处理
|
||||
|
||||
### 3. 状态模式
|
||||
- 玩家动画状态管理
|
||||
- 游戏状态控制
|
||||
|
||||
## 关键实现路径
|
||||
|
||||
### 寻路流程
|
||||
1. 触摸输入转换世界坐标
|
||||
2. 世界坐标转瓦片坐标
|
||||
3. A*算法计算路径
|
||||
4. 路径平滑处理
|
||||
5. 瓦片坐标转世界坐标
|
||||
6. 执行移动动画
|
||||
|
||||
### 战斗流程
|
||||
1. 碰撞检测触发
|
||||
2. 玩家对齐到攻击位置
|
||||
3. 播放攻击动画
|
||||
4. 比较生命值
|
||||
5. 执行胜负逻辑
|
||||
6. 更新游戏状态
|
||||
|
||||
### 升级流程
|
||||
1. 击败特定怪物触发
|
||||
2. 道具飞行动画
|
||||
3. 播放升级特效
|
||||
4. 切换动画资源
|
||||
5. 更新玩家状态
|
||||
|
||||
## 性能考虑
|
||||
|
||||
- 寻路算法使用开放列表和关闭列表优化
|
||||
- 动画切换避免重复播放
|
||||
- 对象池管理（待实现）
|
||||
- 资源分包加载减少初始加载时间
|
||||
40
.kilocode/rules/memory-bank/brief.md
Normal file
40
.kilocode/rules/memory-bank/brief.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# 项目概述
|
||||
|
||||
这是一个基于 Cocos Creator 3.8.7 的 2D 平面游戏项目，主要玩法是通过 TiledMap 进行寻路打怪。
|
||||
|
||||
## 核心玩法
|
||||
|
||||
- 玩家在 2D 瓦片地图上移动
|
||||
- 使用 A* 寻路算法进行路径规划
|
||||
- 与怪物进行战斗，通过比较生命值决定胜负
|
||||
- 收集道具升级角色
|
||||
- 相机跟随玩家移动
|
||||
|
||||
## 技术特点
|
||||
|
||||
- 使用 Cocos Creator 3.8.7 引擎
|
||||
- TypeScript 开发
|
||||
- TiledMap 地图系统
|
||||
- A* 寻路算法
|
||||
- 2D 物理碰撞系统
|
||||
- 动画系统（支持角色升级后的动画切换）
|
||||
- 音效系统
|
||||
- UI 弹窗系统
|
||||
|
||||
## 项目结构
|
||||
|
||||
- `assets/scripts/` - 核心游戏逻辑
|
||||
- `assets/scenes/` - 场景文件（main.scene, start.scene）
|
||||
- `assets/bundle1/` - 资源分包（动画、图片、音乐）
|
||||
- `assets/resources/` - 游戏资源
|
||||
- `settings/` - 引擎和项目配置
|
||||
|
||||
## 主要组件
|
||||
|
||||
- PlayerController - 玩家控制器
|
||||
- TiledMapPathfinder - 瓦片地图寻路
|
||||
- AStarPathfinding - A*寻路算法
|
||||
- CameraFollow - 相机跟随
|
||||
- Shadow2D - 2D阴影效果
|
||||
- Manager - 游戏管理器
|
||||
- Start - 启动场景管理
|
||||
37
.kilocode/rules/memory-bank/context.md
Normal file
37
.kilocode/rules/memory-bank/context.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# 当前状态
|
||||
|
||||
## 项目状态
|
||||
|
||||
项目处于开发阶段，核心功能已基本实现，包括：
|
||||
- 玩家移动和寻路系统
|
||||
- 战斗机制
|
||||
- 角色升级系统
|
||||
- 相机跟随
|
||||
- UI弹窗系统
|
||||
|
||||
## 最近变更
|
||||
|
||||
- 完成了玩家控制器的核心逻辑
|
||||
- 实现了A*寻路算法与TiledMap的集成
|
||||
- 添加了角色升级后的动画切换机制
|
||||
- 完善了战斗系统的视觉反馈
|
||||
|
||||
## 当前工作重点
|
||||
|
||||
- 优化寻路算法性能
|
||||
- 完善角色动画系统
|
||||
- 调整游戏平衡性
|
||||
- 添加更多游戏内容
|
||||
|
||||
## 已知问题
|
||||
|
||||
- 寻路算法在复杂地图上可能存在性能问题
|
||||
- 角色升级后的动画切换需要进一步优化
|
||||
- 战斗系统的反馈机制可以更加丰富
|
||||
|
||||
## 下一步计划
|
||||
|
||||
- 添加更多关卡和怪物类型
|
||||
- 实现存档系统
|
||||
- 优化移动端适配
|
||||
- 添加音效和背景音乐
|
||||
39
.kilocode/rules/memory-bank/product.md
Normal file
39
.kilocode/rules/memory-bank/product.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# 产品描述
|
||||
|
||||
## 产品定位
|
||||
|
||||
这是一款 2D 瓦片地图冒险游戏，结合了策略寻路和角色扮演元素。游戏通过简洁的操作方式和丰富的视觉反馈，为玩家提供轻松愉快的游戏体验。
|
||||
|
||||
## 解决的问题
|
||||
|
||||
- 提供简单易上手的移动游戏体验
|
||||
- 通过寻路机制增加策略性
|
||||
- 角色成长系统提供长期游戏动力
|
||||
- 视觉和音效反馈增强游戏沉浸感
|
||||
|
||||
## 核心玩法循环
|
||||
|
||||
1. **探索阶段**：玩家在瓦片地图上点击移动，使用 A* 寻路算法自动规划路径
|
||||
2. **战斗阶段**：遇到怪物时自动触发战斗，通过比较生命值决定胜负
|
||||
3. **成长阶段**：击败怪物获得生命值，收集道具升级角色
|
||||
4. **挑战阶段**：面对更强的敌人和更复杂的地图布局
|
||||
|
||||
## 用户体验目标
|
||||
|
||||
- **直观操作**：单点触控即可完成所有操作
|
||||
- **流畅动画**：角色移动、攻击、升级都有平滑的动画过渡
|
||||
- **即时反馈**：战斗结果、道具收集都有明确的视觉和音效反馈
|
||||
- **渐进难度**：从简单到复杂的地图和敌人设计
|
||||
|
||||
## 目标用户
|
||||
|
||||
- 喜欢休闲游戏的移动端用户
|
||||
- 偏好策略思考的玩家
|
||||
- 寻求短期娱乐体验的用户群体
|
||||
|
||||
## 成功指标
|
||||
|
||||
- 用户留存率
|
||||
- 游戏完成率
|
||||
- 用户操作流畅度
|
||||
- 动画和音效的正面反馈
|
||||
97
.kilocode/rules/memory-bank/tech.md
Normal file
97
.kilocode/rules/memory-bank/tech.md
Normal file
@@ -0,0 +1,97 @@
|
||||
# 技术栈
|
||||
|
||||
## 核心技术
|
||||
|
||||
### 游戏引擎
|
||||
- **Cocos Creator 3.8.7**
|
||||
- 基于 TypeScript 的游戏开发引擎
|
||||
- 支持跨平台发布（Web、iOS、Android）
|
||||
- 组件化开发模式
|
||||
|
||||
### 开发语言
|
||||
- **TypeScript**
|
||||
- 静态类型检查
|
||||
- 面向对象编程
|
||||
- ES6+ 语法支持
|
||||
|
||||
## 引擎配置
|
||||
|
||||
### 启用模块
|
||||
- **2D渲染** - 2D图形渲染
|
||||
- **UI系统** - 用户界面组件
|
||||
- **动画系统** - 帧动画和骨骼动画
|
||||
- **音频系统** - 背景音乐和音效
|
||||
- **物理系统** - 2D物理碰撞检测
|
||||
- **瓦片地图** - Tiled地图支持
|
||||
- **Spine 3.8** - 骨骼动画支持
|
||||
- **DragonBones** - 骨骼动画支持
|
||||
|
||||
### 项目设置
|
||||
- **设计分辨率**: 720x1334 (移动端竖屏)
|
||||
- **物理引擎**: Box2D (2D物理)
|
||||
- **碰撞组**: player(1), npc(2)
|
||||
- **TypeScript严格模式**: 关闭
|
||||
|
||||
## 资源管理
|
||||
|
||||
### 分包加载
|
||||
- **bundle1** - 主要游戏资源（动画、图片、音乐）
|
||||
- **bundle2** - 预留资源包
|
||||
- **resources** - 基础资源
|
||||
|
||||
### 动画资源
|
||||
- 玩家动画序列帧（站立、行走、攻击、死亡）
|
||||
- 升级前后不同动画版本
|
||||
- 怪物动画
|
||||
- 特效动画
|
||||
|
||||
## 开发工具
|
||||
|
||||
### 地图编辑
|
||||
- **Tiled Map Editor** - 瓦片地图编辑
|
||||
- **WalkableLayer** - 可行走区域定义
|
||||
|
||||
### 版本控制
|
||||
- **Git** - 代码版本管理
|
||||
- **.gitignore** - 排除构建文件和临时文件
|
||||
|
||||
## 性能优化
|
||||
|
||||
### 寻路算法
|
||||
- A*算法优化
|
||||
- 路径平滑处理
|
||||
- 开放列表和关闭列表管理
|
||||
|
||||
### 内存管理
|
||||
- 资源分包加载
|
||||
- 动态资源释放
|
||||
- 对象池模式（待实现）
|
||||
|
||||
### 渲染优化
|
||||
- 2D渲染管线
|
||||
- 批量绘制
|
||||
- 纹理压缩
|
||||
|
||||
## 平台适配
|
||||
|
||||
### 移动端优化
|
||||
- 触摸输入处理
|
||||
- 屏幕适配
|
||||
- 性能调优
|
||||
|
||||
### 调试工具
|
||||
- Cocos Creator调试器
|
||||
- 浏览器开发者工具
|
||||
- 自定义寻路测试工具
|
||||
|
||||
## 构建配置
|
||||
|
||||
### 开发环境
|
||||
- 热重载支持
|
||||
- 调试信息输出
|
||||
- 性能监控
|
||||
|
||||
### 生产环境
|
||||
- 代码压缩
|
||||
- 资源优化
|
||||
- 错误处理
|
||||
Reference in New Issue
Block a user