mcpField
P
phaser4-gameplay-development

phaser4-gameplay-development

github.com/weberwang开发0194 次安装2 周前更新
代码仓库

关于 phaser4-gameplay-development

面向 Phaser 4 游戏玩法开发的技能,覆盖规则、状态、交互实现及动态验收。它按场景 Work Item 的 V1 至 V4 阶段推进,并要求通过控制流程审计和证据验证。

主要功能

  1. 01管理玩法规则与状态
  2. 02按 V1 至 V4 阶段交付
  3. 03明确玩法与美术职责
  4. 04验证动态可玩轨迹
  5. 05记录截图对比证据
  6. 06清理灰盒代码与资源

适用场景

  1. 01定义场景行为和状态迁移
  2. 02实现正式场景玩法
  3. 03验收碰撞与反馈表现
  4. 04对照视口截图验证视觉

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/weberwang/phaser-skills --skill phaser4-gameplay-development

安装后在 Claude Code 中输入/phaser4-gameplay-development确认已加载。

附带文件agents/openai.yaml

详细介绍

来自项目 README

Phaser 4 玩法开发

全局阶段、视觉硬门和场景前置以控制模型、状态、阶段与停止门及对应 Schema 为准。本领域只负责玩法规则、状态、交互和动态验收;场景使用同一 Work Item 的 V1→V2→V3→V4 链,V2 的拆解与布局确认分别执行。

全局控制接入

控制面边界:可提议、可审查、可在当前用户任务的 Work Item 范围内修改,且必须回到 $phaser4-game-workflow-control 审计和状态迁移;仅涉及外部写入、付费、真机、破坏性或外部删除、发布副作用的 A4-A6 操作请求批准。

本领域可提议、审查,并在当前用户任务、冻结 Implementation Package、A 等级与路径范围内修改;任何实现前运行 phaser4-game-workflow-control preflight,实施后执行 diff-audit 与 evidence-check,再回总控审计和状态迁移;仅涉及外部写入、付费、真机、破坏性或外部删除、发布副作用的 A4-A6 操作请求批准。

所有权

玩法独占玩法规则、状态、碰撞、交互代码、功能灰盒和低保真清理。美术可以拥有纯表现层资源配置、布局/表现预制数据和视觉集成调整,但不得改变玩法规则、碰撞语义或状态所有权;V4 由玩法与美术协作完成运行态联合验收。发现职责、公开契约、状态所有权或依赖方向变化时停止受影响实现,返回模块审计和风险触发的专业审核;只有仍存在受保护取舍时 grilling。

涉及汁水感或动态反馈时按需参考汁水感设计指南。玩法继续拥有规则结果、碰撞、状态及反馈触发条件;击退、顿帧或输入窗口等会改变实际玩法的行为仍由玩法定义和验收,纯表现偏移不覆盖玩法状态。

实现

玩家可见内容遵守游戏内文案:正式界面只绑定当前场景/状态的可见表达、短标签/本地化键与动态数值,不直接显示 GDD/brief 的规则段落、功能描述或验收字段。此规则覆盖无效果图路径、HUD、按钮、弹窗、Toast 和奖励浮字;必要引导与操作后果按已定义条件保留。

  1. 读取 GDD、TDD、控制面、总控的审核漏斗和游戏实现规则。视觉任务同时读取视觉质量门、玩法视觉契约;UI 读取 phaser4-game-ui-layout;参考还原读取视觉还原规则。
  2. 按当前场景 Work Item 的阶段门推进玩法交付:V1 冻结功能规格与必要灰盒,V2 冻结拆解和布局事实,V3 验收正式资源,V4 直接消费 V2/V3 产物实现正式 SCENE/DISPLAY_LAYER,并完成功能与视觉联合验收。foundation-only 的基础能力和跨场景 INTEGRATION 由控制面计划调度;本领域不得把玩法实现提前放入基础包或另建场景生命周期。
  3. 对当前场景明确可观察玩家行为、状态迁移、时序、反馈、成功/失败和异常恢复。截图无法证明的行为标为待定义,不自行推断。
  4. 只在 V1 需要证明结构、交互或节奏时建立隔离的可运行灰盒,记录稳定 ID、层级、交互区和资源依赖。已冻结结构不为形式重复灰盒;灰盒不得作为场景完成证据。
  5. foundation-only 阶段先完成场景无关的 SHARED/MODULE;V2 布局确认与 V3 资源验收通过后,直接在 V4 启动正式 SCENE 代码。场景实现只闭环玩法、正式资源、场景自有 UI/常驻 HUD、清理和场景证据。modal/popup 等弹窗必须拆为独立 DISPLAY_LAYER Work Item,读取自己的 V2/V3 证据并在自身 V4 验收;弹窗不属于大厅或其他宿主场景实现,也不阻断其验收。hostSceneId 仅用于公开接口和运行上下文接线。
  6. 只使用绑定当前 scene_id 或合规 shared 且 V3 accepted 的资源进入正式功能实现。用独立 GameObject、命名容器和图层结构化装配,按显示对象锚点与显示层分层显式设置可设原点对象的默认中心 (0.5, 0.5),逐对象记录非中心例外,并声明背景、世界、特效、HUD 与瞬态层的合成顺序和输入归属;UI 从 phaser4-game-ui-layout 布局契约计算,区分坐标空间、资源 origin、布局停靠点与动画偏移,并在视口、安全区、方向、状态和内容变化后通过唯一入口幂等重排。普通测试验证相对关系,不把绝对屏幕坐标当作通用验收标准。
  7. 在 V4 与美术重放动态可玩轨迹,检查识别、预警、命中/受击/奖励反馈、遮挡、响应式、性能和功能契约。忠实还原在冻结目标视口/状态提供同条件完整 viewport 并更新逐状态、逐区域忠实度矩阵,其他视口验证布局关系不变量;玩法处理规则/交互失败,美术处理纯表现失败,跨域问题进入 F3。
  8. 正式结构通过后,玩法清除低保真代码、纹理键、资源、fallback 和运行时引用,重新执行测试与生产构建。场景功能、资源、接入、场景自有显示层、占位清理和验证关闭后即可标记当前场景完成;独立弹窗另行验收。

证据

截图对比记录相同视口、设备像素比、状态、操作轨迹、语言、时间点、ROI、预先定义的项目容差、稳定帧和遮罩说明。完整 viewport 为主证据,ROI、叠加和像素差仅作补充;生成式内容、动画和 VFX 不得只靠像素差判断。未解释或超容差差异、缺同条件双方证据、缺已批准例外或仅凭主观结论不得报告完成;源码、固定坐标、类型检查、构建成功和元素存在只能证明结构或工程状态。

F0 只校验任务范围与流程,F1 核对既定规格,F2 由非作者验证玩法领域质量,F3 绑定当前候选工程证据,F4 只做带副作用的 A4-A6 集成/发布操作批准。行为或验收变化建立 Change Request 并记录用户决定。新增或修改的类、函数、实体及复杂逻辑使用简体中文注释。

评论

支持 Markdown