game-development

游戏开发

按照用户要求的规模，打造用户要求的体验。保留项目的引擎、操控方式、风格及无关部分。原型可以继续保持原型状态；完整游戏则需要包含用户要求的内容、进度、失败和重试路径。

构建前先了解游戏

对于新游戏或大幅重设计玩法，至少研究两款类似游戏。观看相关实机画面或检查可玩的演示，而不要只依赖文字介绍、预告片或搜索结果摘要。研究玩家的操作、时机、反馈、难度，以及犯错后的恢复方式。如果实现细节不明确，请查阅相关引擎文档。

简要记录信息来源、视频时间戳或游玩片段、观察结果，以及这些观察所支持的设计决策。提出设计前，确认确实检查过两个示例。优先选择简短且相关的实机画面或易于访问的演示。如果抓取失败，请尝试其他来源和其他可用的访问方式，例如浏览器或直接下载。对于被沙盒阻止的操作，使用常规审批流程；一个工具遇到网络故障，并不能说明无法开展研究。如果其他方式仍然受阻，请说明缺失了哪些证据。复用项目现有的研究。对于成熟设计中的错误修复或小型新增功能，应专注于复现和检查，而非开展新的研究项目。

明确核心操作、目标、挑战、奖励、操控方式，以及游戏开始后的第一分钟。尽早实现核心交互并实际游玩，再围绕它构建其余内容。根据观察到的行为进行调整；借鉴来的时机数值只是起点，并非通用规则。对于仅涉及设计的请求，给出用户要求的提案，并区分参考案例中的观察与未经测试的想法。

打造用户要求的体验

让操作清晰易懂且响应灵敏。衔接玩法、动画、镜头、声音和界面反馈，让玩家能够明白发生了什么。确保效果强度适当，并能恢复到静止状态。在适用的情况下，支持所需的输入方式，并提供清晰的暂停、失败、重试和结束方式。

使用现有架构，并采用满足需求的最简单实现。仅在涉及模拟、移动、程序化世界、持久化或性能的改动中，才阅读技术检查。

在条件允许时，使用 game-development-asset-generation 制作素材，并使用 research-backed-frontend-development 制作菜单和 HUD。复用它们已有的研究，避免重复。开发过程中融入视觉呈现，并以实际游戏尺寸和动态效果进行检查。保留有意设置的占位内容范围；交付完成的美术时，请替换临时素材。

游玩、检查并修复

通过实际键盘、指针、触控或控制器输入，体验受影响的游戏流程。直接调用游戏函数并不能测试输入路径。检查操作后果：命中会改变生命值，失败会改变游戏状态，重试会恢复可玩的游戏。难以到达的状态可以使用可重复的测试装置，但也要测试进入这些状态的过程。

实际查看游玩截图或录像，检查日志，并在再次游玩受影响的场景前修复发现的问题。检查可读性、镜头构图、碰撞、反馈，以及相关屏幕尺寸。使用现有测试；如果新增针对性回归检查能够捕获该问题，就添加检查。仅仅成功构建并不能证明玩法正确。

在操作浏览器或预览前，应用 polite-browser-use；条件允许时，查看录像应使用 view-video。在用户要求的行为和相关检查均通过后完成工作；否则说明具体的阻碍。报告实际游玩了哪些内容，以及哪些内容仍未验证。除非用户要求，否则不要发布或上传游戏。