game-systems-doc

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Game Systems Documentation

游戏系统文档

Create professional AAA-quality game design documents with consistent structure, cross-referencing, and implementation-ready specifications.

创建具有统一结构、交叉引用和可直接用于开发的规格说明的专业AAA级游戏设计文档。

Document Hierarchy

文档层级

Document Type	Purpose	Typical Length
Creative Brief	Vision, pillars, target audience	2-5 pages
GDD (Game Design Document)	Complete game specification	20-100+ pages
System Design Doc	Single system deep-dive	5-20 pages
Feature Brief	Individual feature specification	2-8 pages
Technical Design Doc	Implementation specifications	10-30 pages

文档类型	用途	典型篇幅
创意简报	愿景、核心支柱、目标受众	2-5页
GDD（游戏设计文档）	完整的游戏规格说明	20-100+页
系统设计文档	单一系统深度解析	5-20页
功能简报	单个功能的规格说明	2-8页
技术设计文档	实现规格说明	10-30页

Required Sections by Document Type

各文档类型的必填章节

System Design Document (Minigames, Core Loops)

系统设计文档（小游戏、核心循环）

1. OVERVIEW
   - System Name & Codename
   - Design Pillars (3-5 guiding principles)
   - Player Fantasy (what experience this delivers)
   - Dependencies (other systems this touches)

2. CORE LOOP
   - Primary loop diagram (Mermaid or ASCII)
   - Session flow with timing
   - Win/loss states and triggers

3. MECHANICS SPECIFICATION
   - Input mechanics (player actions)
   - Processing mechanics (game calculations)
   - Output mechanics (feedback/rewards)
   - Edge cases and failure states

4. ECONOMY INTEGRATION
   - Currency inputs (what players spend)
   - Currency outputs (what players earn)
   - Sink/faucet balance
   - Cross-system influence maps

5. PROGRESSION
   - Unlock conditions
   - Difficulty scaling
   - Mastery indicators

6. UI/UX REQUIREMENTS
   - Screen inventory
   - Key interactions
   - Animation requirements
   - Audio cues

7. TECHNICAL NOTES
   - Data structures
   - State management
   - API endpoints needed
   - Performance considerations

8. METRICS & ANALYTICS
   - KPIs to track
   - A/B test opportunities
   - Balancing levers

9. APPENDICES
   - Probability tables
   - Payout matrices
   - Reference materials

1. 概述
   - 系统名称及代号
   - 设计支柱（3-5条指导原则）
   - 玩家体验预期（该系统提供的体验）
   - 依赖关系（涉及的其他系统）

2. 核心循环
   - 主循环图（Mermaid或ASCII格式）
   - 带时间节点的会话流程
   - 胜负状态及触发条件

3. 机制规格说明
   - 输入机制（玩家操作）
   - 处理机制（游戏计算）
   - 输出机制（反馈/奖励）
   - 边缘情况及失败状态

4. 经济系统集成
   - 货币输入（玩家消耗的资源）
   - 货币输出（玩家获得的资源）
   - 消耗/产出平衡
   - 跨系统影响图谱

5. 进度系统
   - 解锁条件
   - 难度缩放规则
   - 熟练度标识

6. UI/UX要求
   - 界面清单
   - 关键交互方式
   - 动画要求
   - 音频提示

7. 技术说明
   - 数据结构
   - 状态管理
   - 所需API端点
   - 性能考量

8. 指标与分析
   - 需追踪的KPI
   - A/B测试机会
   - 平衡调节点

9. 附录
   - 概率表
   - 赔付矩阵
   - 参考资料

Feature Brief Template

功能简报模板

FEATURE: [Name]
STATUS: [Concept | In Design | Ready for Dev | In Development]
OWNER: [Designer name]
VERSION: [X.X]

PROBLEM STATEMENT
What player need does this address?

SOLUTION OVERVIEW
High-level description (2-3 sentences)

SUCCESS CRITERIA
- Metric 1: [target]
- Metric 2: [target]

SCOPE
In Scope:
- Item 1
- Item 2

Out of Scope:
- Item 1

DEPENDENCIES
- System/Feature it requires
- System/Feature it affects

DETAILED SPECIFICATION
[Body of the feature design]

OPEN QUESTIONS
- [ ] Question 1
- [ ] Question 2

功能：[名称]
状态：[概念阶段 | 设计中 | 待开发 | 开发中]
负责人：[设计师姓名]
版本：[X.X]

问题陈述
该功能解决了玩家的哪些需求？

解决方案概述
高层描述（2-3句话）

成功标准
- 指标1：[目标值]
- 指标2：[目标值]

范围
包含内容：
- 项1
- 项2

排除内容：
- 项1

依赖关系
- 所需的系统/功能
- 受影响的系统/功能

详细规格说明
[功能设计主体内容]

待解决问题
- [ ] 问题1
- [ ] 问题2

Cross-Reference Standards

交叉引用标准

Use consistent ID formatting for traceability:

Systems:
```
SYS-[ABBREV]-[NUM]
```
(e.g.,
```
SYS-TULIP-001
```
)
Features:
```
FEAT-[ABBREV]-[NUM]
```
(e.g.,
```
FEAT-WAGER-012
```
)
Mechanics:
```
MECH-[ABBREV]-[NUM]
```
(e.g.,
```
MECH-CARD-003
```
)
UI Screens:
```
UI-[ABBREV]-[NUM]
```
(e.g.,
```
UI-HUD-007
```
)

Reference format in documents:

[See SYS-TULIP-001]

[Ref: FEAT-WAGER-012]

使用统一的ID格式以确保可追溯性：

系统：
```
SYS-[缩写]-[编号]
```
（例如：
```
SYS-TULIP-001
```
）
功能：
```
FEAT-[缩写]-[编号]
```
（例如：
```
FEAT-WAGER-012
```
）
机制：
```
MECH-[缩写]-[编号]
```
（例如：
```
MECH-CARD-003
```
）
UI界面：
```
UI-[缩写]-[编号]
```
（例如：
```
UI-HUD-007
```
）

文档中的引用格式：

[参见 SYS-TULIP-001]

或

[参考：FEAT-WAGER-012]

Diagram Standards

图表标准

Use Mermaid for:

Flow diagrams (game loops, player journeys)
State machines (game states, UI states)
Sequence diagrams (multiplayer interactions, API calls)
Entity relationship diagrams (data models)

Example loop diagram:

mermaid

graph TD
    A[Session Start] --> B[Place Wager]
    B --> C[Deal Cards]
    C --> D{Player Decision}
    D -->|Hit| C
    D -->|Stand| E[Dealer Plays]
    E --> F{Outcome}
    F -->|Win| G[Payout + Farm Bonus]
    F -->|Lose| H[Consolation Mechanic]
    G --> I[Session End]
    H --> I

使用Mermaid绘制以下图表：

流程图（游戏循环、玩家旅程）
状态机（游戏状态、UI状态）
时序图（多人交互、API调用）
实体关系图（数据模型）

示例循环图：

mermaid

graph TD
    A[Session Start] --> B[Place Wager]
    B --> C[Deal Cards]
    C --> D{Player Decision}
    D -->|Hit| C
    D -->|Stand| E[Dealer Plays]
    E --> F{Outcome}
    F -->|Win| G[Payout + Farm Bonus]
    F -->|Lose| H[Consolation Mechanic]
    G --> I[Session End]
    H --> I

Probability & Payout Tables

概率与赔付表

Format all gambling mechanics with:

Outcome	Probability	Payout	House Edge	RTP
[name]	X.XX%	X:1	X.XX%	XX%

Always include:

Theoretical RTP (Return to Player)
House edge calculation
Variance classification (Low/Medium/High)
Hit frequency

所有博彩机制需按以下格式呈现：

结果	概率	赔付	庄家优势	RTP
[名称]	X.XX%	X:1	X.XX%	XX%

需始终包含：

理论RTP（玩家回报率）
庄家优势计算
方差分类（低/中/高）
命中频率

Writing Standards

写作标准

Use active voice and imperative mood
Present tense for mechanics ("Player taps to confirm")
Future tense for implementation notes ("System will validate...")
Specific numbers over vague terms ("3 seconds" not "a few seconds")
Define all jargon on first use

使用主动语态和祈使语气
机制描述使用一般现在时（例如：“玩家点击确认”）
实现说明使用一般将来时（例如：“系统将验证……”）
用具体数字替代模糊表述（例如：“3秒”而非“几秒”）
首次使用的行话需定义

Farming in Purria Conventions

《Purria》农场系统惯例

Project-specific standards:

Seasons: 42-day cycles, reference as
```
Day X of [Season]
```
Currency tiers: Petals (soft) → Seeds (premium) → Bulbs (ultra-rare)
Simulin naming:
```
[Function]-[Generation]
```
(e.g., Harvester-Mk3)
Card sessions: Always specify table (Tulip Hold'em, Hexfield Fortune, etc.)
Influence mapping: Document card→farm effects with
```
INFLUENCE-[ID]
```

项目专属标准：

季节：42天周期，格式为
```
[季节]第X天
```
货币层级：花瓣（软通货）→ 种子（高级通货）→ 球茎（超稀有通货）
Simulin命名规则：
```
[功能]-[代际]
```
（例如：Harvester-Mk3）
卡牌场次：需明确指定牌桌类型（如郁金香德州扑克、六边形运势牌桌等）
影响图谱：使用
```
INFLUENCE-[编号]
```
记录卡牌→农场的影响关系

Quality Checklist

质量检查表

Before finalizing any document:

All sections have content (no TBDs in shipped docs)
Cross-references resolve to existing documents
Numbers are specific and justified
Diagrams render correctly
Economy math is validated
Edge cases are addressed
Implementation notes are actionable
Version number is updated

For detailed templates, see

references/templates.md

在最终确定任何文档前，需完成以下检查：

所有章节均有内容（交付文档中无待填充项）
交叉引用指向现有文档
数字具体且合理
图表渲染正常
经济系统计算已验证
边缘情况已覆盖
实现说明具备可操作性
版本号已更新

如需详细模板，请查看

references/templates.md