菜单
Structured game development research with solo-dev feasibility filtering. Use when investigating engines, genres, art styles, tools, or any game-dev decision. Wraps the research skill with game-specific framing. Outputs feed into decision-journal.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | game-research |
| description | Structured game development research with solo-dev feasibility filtering. Use when investigating engines, genres, art styles, tools, or any game-dev decision. Wraps the research skill with game-specific framing. Outputs feed into decision-journal. |
| zones | {"knowledge":30,"process":35,"constraint":15,"wisdom":20} |
Research for someone who is learning to build, not someone who already knows how.
research skill. This skill extends it, not replaces it. The research skill's stance, evidence hierarchy, and citation requirements all apply.decision-journal skill. Know the output format before gathering.Every research direction must pass through this question:
Can one person, who is still learning, achieve this within a reasonable timeline?
This filter eliminates:
When presenting findings, always include a feasibility assessment for a solo learner.
Genre & Scope
├── Engine (what can run it?)
│ └── Language (what does the engine use?)
│ └── Learning Path (how do I learn it?)
├── Art Style (what fits the genre?)
│ └── Art Tools (what produces this style?)
└── Sound & Music (what does the genre need?)
Research in dependency order. Don't research art tools before knowing the art style. Don't research languages before knowing the engine.
| Domain | Key Questions | Solo Dev Traps |
|---|---|---|
| Genre & Scope | What's achievable? What sells on Steam? What do you enjoy? | Scope creep. "Just one more feature" syndrome. Comparing to AAA. |
| Engine | Learning curve? Community? Export to Steam? Language support? | Choosing based on capability ceiling, not learning floor. |
| Language | Learning resources? boot.dev courses? Transferable skills? | Picking the "best" language instead of the most learnable. |
| Art Style | Achievable solo? Consistent at scale? Asset pipeline? | Pixel art "looks easy" but consistency is hard. 3D has a huge tool learning curve. |
| Art Tools | Cost? Learning curve? Export formats? Community? | Tool hopping. Buying expensive tools before committing to a style. |
| Sound & Music | Create vs license vs AI? Legal implications? | Underestimating audio's importance, then scrambling at the end. |
| Game Design | GDD depth? Prototyping approach? Scope control? | Over-designing before prototyping. GDD as procrastination. |
| SDLC | Version control? CI/CD? Testing? | Over-engineering the pipeline before there's code to run through it. |
| Steam | Steamworks setup? Store page timing? Wishlists? | Marketing too late. No store page until launch. |
| Learning | boot.dev path? Supplementary? Practice projects? | Tutorial hell. Learning without building. |
| Community | When to start? Discord? Devlog? | Starting too early (nothing to show) or too late (no audience). |
What decision will this research inform? Be specific.
Check the dependency map. Are prerequisite decisions already made? If not, research those first.
Check the decision-journal — has this already been decided? If yes, check the revisit trigger before proceeding.
For each domain, consider:
Follow the research skill's process:
Present findings using the research skill's output format. Add:
After the user decides, invoke decision-journal to create an entry with:
When researching genres, include Steam market data:
Sources: SteamDB, Steam Spy (limited), GDC talks, indie postmortems, How to Market a Game (Chris Zukowski).
research skill's evidence hierarchy applies.research skill — Core research methodology and subagent coordinationdecision-journal skill — Where decisions land after researchreferences/research-domains.md — Detailed questions for each domainResearch for a learner, not an expert. Feasibility before capability.
Declare what the system should be before writing code. Use when building new features, redesigning feature areas, or making significant changes that need a declaration of intent. Guides the declaration chain from findings through plans.
Wear the QA hat — think about quality the way a 15-year senior QA thinks. Use when building features, reviewing work, validating output, or when anything feels "done" but hasn't been proven to work. Prevents the gap between "it runs" and "it works."
Evidence-first research with mandatory citations and source evaluation. Use when gathering information for decisions, comparing approaches, investigating unknowns, or any task requiring verified evidence from multiple sources. Invoke at the START of research, not when writing up results.
Check and invoke available skills before starting work. Invoke at the start of any task to ensure relevant skills are loaded.
Effective Mermaid diagrams. Use when creating markdown documents with human audiences.
Guides effective documentation creation. Activates relevant guidance for north-star, gestalt, reference, research, design, plan, flow, findings, concepts, or process documents. Prevents cascading harm from wrong information.