القائمة
从多个玩家视角评估游戏概念。识别有趣性、参与度钩子和可执行的改进建议，使用 Bartle 类型、心流理论和玩家心理学。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | player-evaluator |
| description | 从多个玩家视角评估游戏概念。识别有趣性、参与度钩子和可执行的改进建议，使用 Bartle 类型、心流理论和玩家心理学。 |
| license | MIT |
多视角游戏概念评估，从玩家角度而非设计者假设出发。
| 命令 | 行动 |
|---|---|
/player-evaluator | 评估当前游戏概念 |
/player-evaluator profiles | 查看可用玩家视角 |
/player-evaluator add [profile] | 添加特定视角评估 |
READ:
design/gdd/game-concept.md → 游戏概念文档.opencode/skills/player-evaluator/perspectives/profiles.yaml → 视角配置IF no game-concept.md:
/brainstorm 生成 GDD。"基于 game-concept.md 的 "Target Player" 部分：
| 目标玩家指标 | 添加视角 |
|---|---|
| "休闲/Casual" | P01, P03, P05, P09, P12 |
| "核心/Core" | P02, P04, P06, P08, P11 |
| "硬核/Hardcore" | P04, P08, P10 |
| "多人/Multiplayer" | P05, P06, P07 |
| "单人/Single-player" | P01, P02, P03, P04 |
| "探索" 重点 | P01, P02 |
| "战斗" 重点 | P07, P08, P04 |
| "建造" 重点 | P09, P10 |
| "剧情" 重点 | P02, P05 |
默认 (如果不明确): P02, P04, P06, P08, P11 (5 个视角)
ASK:
自动选择了 [N] 个玩家视角:
- P01: 探索者 (休闲/放松)
- P02: 探索者 (核心/发现)
- ...
是否添加或移除特定视角？
A) 使用推荐视角
B) 手动选择视角
C) 查看所有可用视角
STOP: Wait for user confirmation.
FOR EACH selected profile, 同时启动:
task(
category="deep",
load_skills=["game-designer"],
run_in_background=true,
description="Evaluate as [Profile ID]",
prompt="
你正在以特定玩家类型评估一个游戏概念。
## 你的玩家档案
**类型**: [Bartle 类型]
**经验水平**: [休闲/核心/硬核]
**主要动机**: [主要游戏动机]
**特征**: [关键心理特征]
## 游戏概念
[从 GDD 提取相关部分]
## 你的任务
从**你的玩家视角**评估这个概念。回答：
1. "我会玩这个游戏吗？为什么？"
2. "对我来说，什么会让它更好？"
## 评分维度 (1-5分)
1. **有趣性 (Fun Factor)**: 内在享受感
2. **参与度 (Engagement)**: 我会持续玩吗？
3. **学习曲线 (Learning Curve)**: 我能快速理解吗？
4. **动机循环 (Motivation Loop)**: 进度是否吸引我？
5. **目标玩家匹配 (Target Player Fit)**: 这适合像我这样的人吗？
## 输出格式
用第一人称"我"表达:
### 整体印象 (2-3句话)
### 维度评分
- 有趣性: X/5 — [理由]
- 参与度: X/5 — [理由]
- 学习曲线: X/5 — [理由]
- 动机循环: X/5 — [理由]
- 目标匹配: X/5 — [理由]
### 我喜欢的 (2-3点)
### 我担心的 (2-3点 + 具体建议)
"
)
必须并行启动所有视角 — 不要顺序执行。
等待所有后台任务完成。系统会发送 <system-reminder> 通知。
For each completed task:
background_output(task_id="...")共识问题 = 被 2+ 视角提及的问题
严重问题 = 被 3+ 视角提及 或 2+ 视角标记为"严重"
独特洞察 = 仅被 1 个视角提及
WRITE: design/gdd/player-evaluation-report.md
# 玩家评估报告
**游戏**: [Game Title]
**日期**: [Timestamp]
**评估视角**: [N] 个视角
---
## 执行摘要
**整体评分**: ⭐⭐⭐⭐☆ (X.X/5.0)
**前 3 个优点**:
1. [优点 + 证据]
2. [优点 + 证据]
3. [优点 + 证据]
**前 3 个担忧**:
1. 🟡 [担忧] — [为什么重要]
2. 🟡 [担忧] — [为什么重要]
3. 🔴 [严重担忧] — [影响]
---
## 维度评分汇总
| 维度 | 评分 | 趋势 |
|------|------|------|
| 有趣性 | X.X/5 | ⬆️/➡️/⬇️ |
| 参与度 | X.X/5 | ⬆️/➡️/⬇️ |
| 学习曲线 | X.X/5 | ⬆️/➡️/⬇️ |
| 动机循环 | X.X/5 | ⬆️/➡️/⬇️ |
| 目标匹配 | X.X/5 | ⬆️/➡️/⬇️ |
**评分图例**: ⬆️ 4.0+ (强), ➡️ 3.0-4.0 (良好), ⬇️ <3.0 (需改进)
---
## 各视角分析
### P01: 探索者 (休闲/放松)
**整体印象**: "作为休闲玩家，这个概念..."
**维度评分**:
- 有趣性: 4.5/5 — "..."
- 参与度: 4.0/5 — "..."
- 学习曲线: 3.5/5 — "..."
- 动机循环: 3.8/5 — "..."
- 目标匹配: 4.2/5 — "..."
**我喜欢的**:
- [具体正面反馈 + GDD 证据]
**我担心的**:
- 🟡 [问题] — [为什么对我重要]
- 💡 [建议] — "试试这样..."
---
[其他视角类似结构]
---
## 共识问题 (2+ 视角提及)
### 🔴 问题 #1: [问题标题]
**提及视角**: P02, P04, P08
**严重程度**: 严重
**为什么重要**:
[解释玩家体验影响]
**建议**:
1. [具体可执行的修复]
2. [替代方案]
3. [参考现有游戏如何解决]
**实施难度**: 低 / 中 / 高
---
### 🟡 问题 #2: [问题标题]
**提及视角**: P01, P05
**严重程度**: 重要
[类似结构]
---
## 独特洞察 (单视角)
### P09: 创造型 (休闲/表达)
- [独特观察，其他视角未提及]
- [为什么这个视角看到不同的东西]
---
## 优先级行动项
**原型前必须修复**:
1. [ ] [来自严重问题的行动]
2. [ ] [来自严重问题的行动]
**应该改进**:
3. [ ] [来自重要问题的行动]
**可以考虑**:
4. [ ] [增强建议]
---
## 方法说明
本次评估使用:
- **视角**: [N] 个玩家视角 (基于目标玩家自动选择)
- **框架**: MDA + 心流理论 + 自我决定理论
- **维度**: 5 个核心指标 (有趣、参与、学习、动机、匹配)
ASK:
评估完成！
**整体评分**: [X]/5
**首要担忧**: [最严重问题]
选择:
A) 查看完整报告
B) 直接讨论关键改进建议
C) 重新运行特定视角评估
D) 跳过，继续下一步
STOP: Wait for user's choice.
支持的 skills:
creative-director — 解决评估中发现的支柱冲突game-designer — 实施建议的改进design-review — 更改后的后续验证委托:
| Phase | 行动 | 并行? |
|---|---|---|
| 1 | 加载上下文 | No |
| 2 | 选择视角 | No |
| 3 | 启动评估 | Yes (强制) |
| 4 | 收集结果 | No |
| 5 | 生成报告 | No |
| 6 | 呈现结果 | No |
The Godot Engine Specialist is the authority on all Godot-specific patterns, APIs, and optimization techniques. Guides C# (primary) vs GDScript (optional) vs GDExtension decisions, ensures proper use of Godot's node/scene architecture, signals, and resources.
快速恢复项目上下文 — 新会话中读取已有配置，无需重新走 /start 流程。
First-time onboarding — asks where you are, then guides you to the right workflow. No assumptions.
引导式美术圣经编写。创建视觉规范文档，作为所有资产制作的基础。在 /brainstorm 完成后、/map-systems 或 GDD 编写之前运行。
美术与程序协调桥梁。处理资产规格、命名规范、导入管道和美术-程序沟通。
从 GDD、关卡文档或角色档案生成资产规格。包含 AI 图像生成提示词和详细规格。在美术圣经和 GDD 批准后、制作开始前运行。