#Slot Game Design Document — Template

Заповнюйте всі обов'язкові поля. Якщо розділ не застосовується, вкажіть N/A і коротку причину. Не використовуйте TBD у версії, що передається девелоперам.

#1. Document control

#Change log

#2. Approval status

#3. High concept

#One-sentence pitch

<What the slot is, its primary mechanic, and why it is distinct.>

#Player experience goals

• <experience goal 1>
• <experience goal 2>
• <experience goal 3>

#Design pillars

#Target audience and session context

<Audience, expected familiarity, intended pacing. Do not describe harmful or exploitative targeting.>

#Non-goals

• <Explicitly excluded mechanic or experience>

#4. Game summary

#5. Core gameplay loop

flowchart LR
    A["Ready"] --> B["Player commits bet"]
    B --> C["Outcome generated"]
    C --> D["Wins evaluated"]
    D --> E{"Feature triggered?"}
    E -- "No" --> F["Result presented"]
    E -- "Yes" --> G["Feature sequence"]
    G --> F
    F --> A

Describe deviations from this flow:

<Exact deviations, player choices, intermediate wagers, persistent state.>

#6. Terminology

#7. Symbols

Payout values belong to the linked Math Spec/PAR sheet. This table defines design behavior and presentation.

#7.1 Symbol presentation metrics

Required before placeholder implementation. These values are presentation metadata only: they do not change reel occupancy, evaluation, RNG, RTP or the canonical math-config identity.

Use one reel cell as the resolution-independent reference box: 1.0 × 1.0. Width and height are maximum visible-content bounds inside that box, not source-image dimensions. Placeholder art and final art must use the same bounds so replacing placeholders does not change reel composition.

Global rules:

• symbol_safe_area: <0.00–1.00> of the reel cell on each axis.
• placeholder_label_safe_width: <0.00–1.00> of the reel-cell width.
• Default anchor is [0.5, 0.5]; any exception must be explicit in the table.
• Bounds include glow, frame and persistent ornament, but exclude temporary win/anticipation VFX.
• No required content may touch or cross the reel-cell clipping edge in its idle state.
• Multi-cell or expanding presentation needs its own row stating occupied visual cells and bounds; visual expansion does not imply a larger mathematical symbol footprint unless the Math Spec says so.
• Frontend placeholder acceptance must verify the configured bounds at the reference layout and at the smallest supported viewport.

#8. Base-game rules

Define unambiguously:

1. When the bet is committed.
2. How the visible grid is constructed from the outcome.
3. Which evaluator runs: lines, ways, clusters, or multiple evaluators.
4. Minimum match size and allowed directions.
5. Wild substitution and exclusions.
6. Scatter/bonus evaluation.
7. Simultaneous-win aggregation.
8. Multiplier application order.
9. Cascade/respin order and termination.
10. Rounding and win-cap application.

#Evaluation order

#Base-game pseudocode

<Short normative pseudocode. It must agree with the evaluation-order table.>

#9. Feature specification

Copy this section once per feature.

#Feature: <feature name>

#State machine

stateDiagram-v2
    [*] --> Enter
    Enter --> Active
    Active --> Active: Continue/retrigger
    Active --> Summary: Termination condition
    Summary --> [*]

#Feature rules

1. <normative rule>
2. <normative rule>

#Feature edge cases

#10. Player controls and UX states

#11. Win presentation

#12. Anticipation rules

Anticipation must not alter the generated outcome or imply player control where none exists.

#13. Art direction

#Theme and visual language

<Description>

#Asset inventory

#14. Animation direction

All animation completion events must be deterministic from the runtime state and must not change payouts.

#15. Audio direction

#16. Help, paytable and disclosures

The player-facing rules must explain:

• bet basis and payout basis;
• paylines/ways/clusters;
• every special symbol;
• feature triggers and retriggers;
• multipliers and their order;
• max-win/win-cap rules;
• published RTP and the conditions under which it applies;
• jackpot or variable contribution where applicable;
• interrupted-game behavior;
• market-required responsible-gaming information.

#17. Market and compliance matrix

This matrix is a design aid, not legal advice. Compliance must approve each target market.

#18. Error and recovery behavior

#19. Telemetry

#20. Acceptance criteria

• Every payout-affecting rule is normative and unambiguous.
• Evaluation order matches the Math Spec and runtime evaluator.
• Every feature has trigger, state, termination, recovery, and cap rules.
• Player-facing help can be derived without inventing behavior.
• Edge cases have deterministic test-vector IDs.
• GDD and Math Spec reference the same Game ID and Math Version.
• Every wire-visible symbol has approved normalized presentation metrics for placeholder handoff.
• Compliance matrix is approved for every launch market.
• No unsupported backend capability is claimed by the GDD.

#21. Open decisions

This section must be empty before integration handoff.

#22. References

• Math Spec: <path/link>
• PAR sheet: <generated artifact path/link>
• Test vectors: <path/link>
• Art bible: <path/link>
• Audio specification: <path/link>
• Market requirements: <authoritative links>