hoatv2211 Game Feature Brainstorming
Overview
Clarify the desired player experience, then compare a small set of meaningfully different options before implementation details harden.
When to use
Use for new mechanics, progression, combat, economy, social features, tools, UX flows, or technical approaches with real design trade-offs.
When NOT to use
Do not use when an approved option already needs a formal specification, when the request is a micro-fix, or when safety requires immediate containment rather than ideation.
Required inputs and context discovery
Collect player goal, target audience, platform, session length, constraints, production budget, content burden, technical limits, accessibility needs, success signals, and non-goals.
Safety and risk level
Brainstorming is read-only. It does not authorize prototypes, purchases, schema changes, service work, or asset mutation.
Workflow
- Frame the player problem and the experience the feature should create. Completion criterion: outcome and non-goals are testable statements.
- Identify constraints and the decisions with the highest downstream cost. Completion criterion: technical, content, UX, and production limits are explicit.
- Propose two or three distinct options rather than cosmetic variants. Completion criterion: each option has a different core loop or implementation shape.
- Compare player value, complexity, risk, tuning leverage, exploit surface, and testability. Completion criterion: a trade-off table makes the recommendation inspectable.
- Recommend one option and list assumptions requiring prototype or playtest evidence.
Completion criterion: the selected direction can move to
game-feature-to-spec.
Evidence and output contract
Produce problem framing, constraints, two or three options, trade-off table, recommendation, rejected alternatives, assumptions, and required prototype/playtest evidence.
Handoff contract
Record chosen and rejected options, decision rationale, unresolved assumptions, tuning risks, and the prompt for creating the specification.
Pitfalls and anti-rationalization
- Do not present one real option and two strawmen.
- Do not hide production cost behind player-facing language.
- Do not treat untested fun or retention claims as observed metrics.
- Do not implement before the direction is approved.
Verification checklist
- Player goal and non-goals are explicit.
- Two or three distinct options exist.
- Trade-offs cover player, technical, and production concerns.
- Recommendation separates evidence from assumptions.
- Next step is specification, prototype, or BLOCKED.
References and scripts
Use product constraints, existing design pillars, telemetry definitions, and technical architecture only as verified inputs.