gavinmcfall/game-research

game-research

Research for someone who is learning to build, not someone who already knows how.

---

Before Starting

1. Invoke the research skill. This skill extends it, not replaces it. The research skill's stance, evidence hierarchy, and citation requirements all apply.
2. Invoke the decision-journal skill. Know the output format before gathering.

---

The Solo Dev Filter

Every research direction must pass through this question:

Can one person, who is still learning, achieve this within a reasonable timeline?

This filter eliminates:

• AAA production pipelines requiring teams of 50+
• Technologies with 2+ year learning curves before productive use
• Art styles requiring professional training the user doesn't have
• Scope that assumes full-time development when this is a side project

When presenting findings, always include a feasibility assessment for a solo learner.

---

Research Domains

Domain Dependency Map

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 Reference

| 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). |

---

Research Process

1. Frame the question

What decision will this research inform? Be specific.

• Good: "Which game engine has the best learning curve for a beginner targeting 2D games on Steam?"
• Bad: "What game engine should I use?"

2. Identify the domain and dependencies

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.

3. Define research directions

For each domain, consider:

• Technical capability — Can it do what I need?
• Learning curve — How long to become productive?
• Community & resources — Tutorials, forums, Stack Overflow presence?
• Solo dev track record — Have solo devs shipped with this? Examples?
• Cost — Free? One-time? Subscription? Revenue share?
• Longevity — Is this actively maintained? Growing or dying?

4. Conduct research

Follow the research skill's process:

• Launch parallel subagents for different directions
• Include one subagent for "directions I haven't thought of"
• Apply the solo dev filter to all findings

5. Synthesize

Present findings using the research skill's output format. Add:

• Solo dev feasibility: explicit rating (high/medium/low) with justification
• Learning investment: estimated time to become productive (not to mastery)
• Decision recommendation: what the evidence points toward (synthesis, not prescription)

6. Record the decision

After the user decides, invoke decision-journal to create an entry with:

• Alternatives considered (from research)
• Evidence links (from research output)
• Revisit trigger (from the findings)
• Confidence level (based on research depth)

---

Steam Market Context

When researching genres, include Steam market data:

• What sells for solo devs? Look at indie success stories, not AAA.
• Saturated vs underserved genres — 2D platformers are saturated. Niche genres may have smaller but more passionate audiences.
• Price expectations by genre — An RPG can charge $20. A puzzle game struggles above $10.
• Wishlist-to-sale conversion — Industry benchmarks for indie games.
• Time to recoup — How many units at what price to cover costs?

Sources: SteamDB, Steam Spy (limited), GDC talks, indie postmortems, How to Market a Game (Chris Zukowski).

---

Constraints

• Apply the solo dev filter to every finding. Don't present options that require a team.
• Cite sources for every claim. The research skill's evidence hierarchy applies.
• Present synthesis, not prescription. "The evidence suggests..." not "You should..."
• Check the decision-journal before researching. Don't re-research settled decisions unless the revisit trigger has been met.
• Account for learning curve, not just capability. "Can do X" means nothing if it takes 2 years to learn.

---

Deeper

• The research skill — Core research methodology and subagent coordination
• The decision-journal skill — Where decisions land after research
• references/research-domains.md — Detailed questions for each domain

---

Research for a learner, not an expert. Feasibility before capability.