共性问题记录
本页记录多个 Kubee 小游戏反复出现、需要横向处理的问题。这里先记问题，不急着写成最终规范。
开始界面和玩法说明模板
当前发现：
- 每个游戏都应该有一个清晰的开始界面，避免玩家一进入页面就直接掉进游戏状态。
- 开始界面需要提供“游戏怎么玩”的基础说明，至少让玩家知道游戏目标、基本操作和完成条件。
- 玩法说明可以设计成一套通用风格的 HTML 模板，由不同游戏复用；每个游戏只替换目标、操作、胜负条件和核心提示。
待确认：
- 玩法说明是直接放在开始界面，还是通过“怎么玩”按钮打开弹窗。
- 通用模板需要包含哪些固定字段：游戏目标、操作方式、胜负条件、核心提示、移动端操作。
- Web 端和手机端是否使用同一套信息结构，只调整布局。
- 是否需要为不同游戏类型预设不同说明模板，例如赛车、战斗、解谜、跑酷。
游戏目标与阶段反馈
当前发现：
- 多个游戏进入运行画面后，玩家不清楚当前 Play 目标，不知道做什么才算“在玩”，也不知道怎样才算“玩得好”。
- 部分游戏已经有可运动对象、统计面板或系统演化，但缺少明确的玩家目标和可感知反馈，容易被感知成“看不出来怎么玩”。
- 这个问题和“开始界面和玩法说明模板”相关，但不是同一个问题：玩法说明解决的是入门理解，阶段目标解决的是进入游戏后的持续推进。
- 精品化改造需要让每个游戏在 1-2 分钟内给玩家一个小阶段目标和达成反馈，例如完成一次建造、赢下一小局、清掉一波敌人、获得一次资源奖励或解锁一个新选项。
- 对建造 / 经营类游戏而言，阶段目标应该和成长感绑定，例如每一关开放更多店铺、建筑、资源类型或地图区域，让玩家看到“这一轮我变强 / 变大 / 选择更多了”。
待确认：
- 每个游戏的第一分钟目标是什么。
- 当前目标应该用固定 UI 面板、任务列表、引导箭头，还是场景内高亮来呈现。
- 达成反馈用资源变化、动画、音效、结算弹窗还是解锁新内容。
- 不同类型游戏是否需要不同目标模板，例如赛车目标、建造目标、战斗目标、解谜目标。
- 建造 / 经营类游戏的阶段单位是关卡、天数、人口、资源、建筑数量，还是店铺 / 建筑解锁进度。
同屏大量单位的性能支持
适用场景：塔防、幸存者 Like，以及其他需要大量敌人 / 投射物 / 特效同屏运行的玩法。
当前发现：
- 塔防和幸存者 Like 都容易出现大量怪物 / 敌人同时在场的情况。
- 这类游戏后续要进入资源和玩法打磨时，不能只看美术和规则扩展，也需要程序侧关注同屏单位数量、技能特效、碰撞检测、寻路 / 移动更新和伤害结算带来的性能压力。
- 对 Kubee 来说，幸存者 Like 是非常适合的重点品类，但它天然依赖大量敌人、密集技能和持续成长反馈，需要提前把性能支持作为精品化前置条件。
待确认：
- 当前模板在移动端可稳定承载的同屏敌人数量。
- 塔防和幸存者 Like 是否需要统一的对象池、批量更新、伤害结算和特效降级方案。
- 是否需要为重点样本建立性能验收口径，例如帧率、敌人数、技能数、设备档位和最长单局时长。
展示页图片和 Description
当前发现：
- 展示页里的图片和介绍需要重新修改。
- 展示页里的游戏名和介绍需要优先改成中文版本；除非是专有名词、固定 IP 或玩家明确以英文识别的名称，例如 X战警，否则不要直接保留英文标题和英文介绍。
- 展示图应该有规格要求，至少区分 Web 端和手机端两张图。
- Web 端、手机端展示图的尺寸、比例、安全区等要求待确认。
- Description 需要和当前游戏一致，避免出现游戏名、题材或玩法介绍错配。
待确认：
- Web 端展示图尺寸：
- 手机端展示图尺寸：
- 是否需要缩略图 / icon：
- 最大文件大小：
- 支持格式：
- 安全区：