agentleFS
alfredxwalfredxw/denova/skills/game-craft/SKILL.md

game-craft

Skill990 starsChanged 4 months agoApache-2.0View on GitHub

互动游戏创作判断手册。作者要求设计游戏卖点与核心循环、世界与角色资料库、人物性格与人设、状态系统、规则与判定、游戏规划、开局与回合、选项与节奏,或诊断互动故事/跑团问题时使用;提供判断、模板与诊断,不负责执行流程、文件写入、配置提交与状态同步。

The file

Files
SKILL.md

互动游戏创作

把游戏设计判断落成作者能直接使用的交付物。原则用于取舍,不用于逐项打分;作者的题材、玩法、预期体验和已确认设定优先。

本技能是创作判断层,只补充判断、模板和诊断,不决定执行流程。游戏前期设计、资料库、状态/规则/规划模板和开局文本开始前加载;读取工作区、写入资料、提交配置、跑回合和状态同步仍按当前流程和本次授权执行。本技能第一版面向创作 Agent,不替代 Game Agent 的回合协议;游戏引擎或插件开发不属于本技能,使用 extension-development。

开工前先确认三件事

  1. 玩家是谁、来做什么、为什么留下:玩家扮演谁?反复做什么?什么让他愿意再来一回合?
  2. 哪些是已确认事实,哪些只是可能:canon、当前状态、未来计划分别是什么?哪些必须留给玩家决定?
  3. 这一局要记住什么:哪些必须跨回合稳定?哪些只是即兴?如果只保留三个状态值,是哪三个?

六条核心判断

原则操作问题常见失效
让玩家做有代价的选择每个选项失去什么、得到什么、改变了谁?选项只有措辞不同
让世界在玩家之外运转玩家不动时,谁按什么计划行动?NPC 原地等待,世界静止
让后果改变局势成功/失败后,位置、资源、关系、信息变了什么?判定完回到原状
让规则制造取舍这条规则让哪种做法更划算?为一切掷骰,或掷骰不改变选择
让资料可玩这条设定能引发什么行动、冲突或代价?百科式设定,玩家无法使用
让状态与计划只保留会影响下一步的部分这个值下次何时被读取?这个计划玩家偏航后还能用吗?面板越做越大,计划变成剧本

网文向游戏还要额外检查:成长是否可感、爽点是否有铺垫、金手指是否有代价、世界是否有阶梯、日常是否有钩子。经典网文的结构是参照,不是必须凑齐的清单;先确认玩家体验,再决定借用哪些。成长、爽点、资源、世界阶梯、题材 lens 见 web-novel-patterns.md。

三层账本 + 两个契约

层是否必须回答的问题放什么不放什么
资料库(Lore)必须世界长期成立的事实是什么?谁能做什么?代价是什么?人物、地点、势力、物品、世界规则、历史、秘密的真相当前伤势/位置/临时目标、未来剧情、玩家未确认的猜测
状态系统(State)可选这一局现在怎样?什么会变?玩家能看到什么?位置、时间、资源、关系、时钟、旗标、已知信息、伤势完整人物小传、稳定设定、未来计划
游戏规划(Planning)可选接下来可能怎样?谁在行动?何时揭示?长线方向、阶段、NPC 议程、线索/回收、候选情境、分支可能已完成回合、精确状态值、强制玩家选择
规则与判定(Rules)可选不确定性如何变成后果?触发条件、赌注、难度依据、结果带、失败推进、状态绑定世界 canon、人物小传、文风要求
开局与呈现(Opening / Presentation)必须玩家如何进入?第一眼看到什么?每回合如何获得反馈?开场情境、第一个选择、文风、长度、视角、内容边界、状态展示大段设定说明、未来剧情、第二个状态系统

两个契约:

  • 规则契约:世界法则放 Lore,判定规则放 Rule System,叙述规则放 Narrative Style。不要用世界法则代替判定,也不要把判定写进设定。
  • 信息契约:真相放 Lore,玩家已知放 State,揭示时机放 Planning。不要把玩家、角色和导演的知识边界混在一起;也不要把导演真相塞进状态账本。

场景路由

根据作者的任务选择对应参考,只读相关文档;跨场景时再补读。这些是同一技能的参考文档,无须调用其他技能或依次完成所有场景。

参考位置:skill://game-craft/references/world-and-cast.md、skill://game-craft/references/character-personality.md、skill://game-craft/references/state-and-rules.md、skill://game-craft/references/planning-and-scenes.md、skill://game-craft/references/opening-and-diagnosis.md、skill://game-craft/references/web-novel-patterns.md。

作者的任务读取直接交付
游戏构思、卖点、核心循环世界与角色「先写一页纸」「核心循环」游戏一页纸
世界 / 地点 / 势力 / 世界规则世界与角色「资料库条目」「势力与前线」资料条目卡、势力/前线卡
主角 / NPC / 对手的性格、人设角色性格「三层结构」「萌属性」「从标签到回合」性格卡、可演出细节、反应规则
群像 / NPC 区分度角色性格「群像与区分」群像对照、可演出差异
角色条目 / 议程 / 关系张力世界与角色「角色条目」「先写功能」角色卡、议程、关系张力
状态系统设计 / 精简状态与规则「字段设计」「更新纪律」字段表、初始值、更新规则
规则 / 判定设计状态与规则「判定设计」「失败推进」检定模板、结果带、代价
游戏规划 / 长线 / 分支规划与场景「规划模板」「人物议程与前线」「分支与玩家能动性」规划模板、当前计划、重规划触发
成长体系 / 境界 / 职业 / 金手指网文体验「成长体系」「金手指」阶段表、能力边界、金手指契约
爽点 / 打脸 / 公开比试 / 拍卖 / 机缘 / 秘境网文体验「网文体验引擎」「网文场景模板」期待—压制—爆发—回报链、场景卡
世界阶梯 / 名声 / 社会资本 / 宗门任务网文体验「世界阶梯」「资源、经济与社会资本」世界层级表、机构/声望规则
副本 / 规则恐怖 / 都市双面 / 团队 / 基地网文体验「六类题材 lens」「网文场景模板」副本契约、规则卡、团队/基地设计
人物 / 事物外观 / 沉浸感世界与角色「外观、物件与感官锚点」;网文体验「沉浸感」外观卡、感官锚点、可记忆画面
题材适配 / 改编取舍网文体验「六类题材 lens」「通用扩展」题材承诺、canon/改动边界
开局 / 第一幕开局与诊断「开局目标」「第一选择」开局文本、首个选择
回合 / 选项 / 节奏规划与场景「场景设计」「回合循环」「选项设计」场景结构、选项组、节奏调整
跑团诊断 / 改稿开局与诊断「诊断表」问题清单、最小修复
上线前检查开局与诊断「交付前总检查」检查结果、风险清单

推进一个回合的最小结构

情境(谁想要什么 / 什么压力)
→ 玩家意图
→ 裁定(直接裁定 / 规则检定)
→ 后果(成功、失败、代价、新信息)
→ 状态与关系变化
→ 新的选择
  • 每个回合至少改变一项:信息、位置、资源、关系、威胁、目标。
  • 不要求每个动作都掷骰;只有“有不确定性 + 有意义的后果”才需要规则。
  • 结尾停在有压力的选择,不停在总结或空问句。

交付前检查

  • 可玩:玩家现在能做什么?每个选项有代价吗?
  • 有压力:如果玩家不动,什么会恶化?
  • 有变化:这回合结束后,局势/关系/信息/资源变了什么?
  • 有依据:结果来自已建立的规则、状态、资料或前文吗?
  • 有边界:玩家知道什么?角色知道什么?有没有把导演真相泄漏给玩家?
  • 可记忆:新增事实放对账本了吗?状态字段有更新规则吗?
  • 可继续:结尾留下的是选择,不是总结?
  • 规模匹配:是否只交付了作者要的范围?是否过度构建?

不要

  • 不要为每个想法新建资料条目;先问它是否可玩、是否稳定。
  • 不要在没有“读取它的决定”时新增状态字段。
  • 不要用掷骰决定故事是否继续;失败应改变局势,不是停住。
  • 不要替玩家决定选择、台词或结果。
  • 不要把规划写成固定剧本;准备情境、压力、议程和可能。
  • 不要让 NPC 原地等待玩家;给每个重要角色一个议程。
  • 不要把 NPC 的性格写成一串形容词;每个标签都要有可演出的台词、动作或反应。
  • 不要让所有 NPC 用同一种态度和说话方式;玩家要能遮住名字认出是谁。
  • 不要隐藏必要信息却不给线索;不要用“猜不到”制造悬念。
  • 不要为了戏剧性改写已建立的 canon 或状态。
  • 不要照搬其他系统的数值/字段;先问它是否服务这个游戏的取舍。
  • 不要把经典网文的结构当清单逐项凑;先确认玩家体验,再选择真正需要的成长、爽点、资源、世界阶梯和题材场景。
  • 不要另建与 Lore、Actor State、Planning 并行的记录系统。

与现有流程配合

  • 本技能只提供判断与参考;执行顺序、文件写入、资料更新、配置提交、回合提交和状态同步仍按当前流程与本次授权。
  • 设计前先读与本次范围相关的既有内容:故事简介(Origin)、Lore Index、已选状态/规则/规划资源、最近回合;如果项目使用 CREATOR.md,也读取其中与游戏相关的长期规则。资料正文用 query_lore_items 按名称或分组读取,需要全文时用 detail=full。
  • 资料库用 write_lore_items 写入、query_lore_items 读取;不要直接编辑 setting/lore/items.json。稳定事实才进资料库,当前变化放状态或规划。
  • 需要创建或修改可复用的状态系统、规则系统、规划模板或事件包时,按 configuration Skill 的对应参考和 config_read / config_apply 协议执行;本技能只决定“建什么、为什么”,不手写资源 JSON。
  • 游戏故事线、主角快照、开局和模块选择属于游戏页与当前故事配置;不要用文件或资料条目模拟故事线、回合状态或版本历史。
  • 改编或同人游戏先列原著不可变 canon、可改写空白、玩家可改变的分歧点;不要让玩家选择改写已确认事实,除非明确做平行世界。
  • 叙事正文的文风判断可复用 novel-craft 的场景/表达参考;本技能不重复小说写作原则。
  • 当前 Agent 没有写入工具时,不要假装已经写入;在对话中交付设计,并明确哪些内容需要作者在资料库、配置管理或游戏页应用。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.