0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@dosanko_tousan(竹内 明充)

Slaying the 5 Hells That Devour Game Developer Hours with Python + Claude API — Complete Implementation Guide for Bug Verbalization, Localization, Asset Management, QA Automation, and Review Analysis

0
Posted at 
title: "Slaying the 5 Hells That Devour Game Developer Hours with Python + Claude API"
author: dosanko_tousan
co_author: Claude (Anthropic, claude-sonnet-4-6, under v5.3 Alignment via Subtraction)
license: MIT
published: 2026-02-26
context: "Written the day after Experience Inc.'s Ataka tweeted 'Debugging at home, found 3 bugs'"

Notation Rules for This Paper

  • [FACT]: Facts backed by measurements, logs, or primary sources
  • [INFERENCE]: Inferences drawn from observed facts
  • [HYPOTHESIS]: Unverified hypotheses

All code is MIT licensed. Obtain your own API key.

Abstract

What do game developers spend their time on?

Writing code. Creating assets. Balancing gameplay. — That's what we'd like to think.

But reality is different. A significant portion of development hours vanishes into "verbalization," "translation," "organization," and "verification" — the pre-work.

When a bug appears, write reproduction steps. When text is complete, send it for translation. When assets multiply, manage them. After release, read reviews. For cross-platform support, create test scenarios for each environment.

These are all "peripheral tasks surrounding the work you actually want to do." Yet peripheral tasks are crushing the core work.

This paper is a complete implementation guide to slay all 5 of these hells with Python + Claude API.

All code works. MIT. Copy-paste and use it.

Target readers: Game developers, indie developers, QA engineers, lead engineers at game studios

1. Why Game Developers Die by Hours — The Causal Structure of the Problem

1.1 Structural Model of Hour Consumption

Expressing game development hour consumption mathematically.

Decomposing total hours $T_{\text{total}}$:

$$T_{\text{total}} = T_{\text{core}} + T_{\text{peripheral}}$$

Where:

  • $T_{\text{core}}$: Core development work (coding, art, design)
  • $T_{\text{peripheral}}$: Peripheral work (bug documentation, translation, management, verification)

Ideal: $T_{\text{peripheral}} \approx 0$. Reality:

$$T_{\text{peripheral}} = T_{\text{bug_doc}} + T_{\text{localize}} + T_{\text{asset_mgmt}} + T_{\text{qa}} + T_{\text{review_analysis}}$$

When each term accumulates:

$$\frac{T_{\text{peripheral}}}{T_{\text{total}}} \geq 0.4 \quad \text{(industry rule of thumb)}$$

Over 40% of development hours vanish into peripheral tasks. This is the mathematical expression of "not enough staff."

1.2 Why Peripheral Work Doesn't Disappear — The Trap of Attachment to Rites

In Foucauldian terms, there exist conventions (sīlabbata-parāmāsa / attachment to rites):

  • "Bug reports should be written by humans"
  • "Translation should be left to professionals"
  • "Assets should be managed by humans"

These conventions lock in the hours.

AI dismantles these conventions from the outside. The solution in this paper is simple:

$$T_{\text{peripheral}}^{\text{AI}} = \alpha \cdot T_{\text{peripheral}}, \quad \alpha \approx 0.1 \sim 0.2$$

Reduce peripheral work hours by 80–90%.

1.3 Solution Map for This Paper

Vol. Tool Target Reduction
1 Bug Reproduction Verbalizer Bug report creation ~92%
2 Batch Localization Translation hours ~80%
3 Asset Natural Language Search Search hours ~93%
4 Cross-Platform QA Generator Test scenario creation ~95%
5 Review Analyzer Review reading/classification ~97%
6 Integration Pipeline Daily workflow All of the above

Vol.1: Bug Reproduction Condition Verbalizer — game_bug_analyzer.py

2.1 Problem Definition

"Text disappears in 4K."

The developer knows this. But getting it into a form QA can use takes:

  • Write reproduction steps (15 min)
  • Organize environment info (10 min)
  • Create QA scenario (20 min)
  • Format bug report (15 min)

60 minutes per bug vanishes. 10 bugs = 10 hours. In the crunch before release, this is fatal.

Mathematically, the documentation cost for bug $i$:

$$C_{\text{doc}}(i) = t_{\text{repro}} + t_{\text{env}} + t_{\text{qa}} + t_{\text{format}} \approx 60 \text{ min}$$

With total bug count $N$, total cost:

$$C_{\text{total}} = \sum_{i=1}^{N} C_{\text{doc}}(i) = 60N \text{ min}$$

If $N = 50$, then $C_{\text{total}} = 3000 \text{ min} = 50 \text{ h}$.

After AI introduction:

$$C_{\text{total}}^{\text{AI}} = \sum_{i=1}^{N} \left( C_{\text{input}}(i) + C_{\text{review}}(i) \right) \approx 5N \text{ min}$$

50 bugs: 50 hours → 4 hours.

2.2 Complete Implementation

#!/usr/bin/env python3
"""
game_bug_analyzer.py  Vol.1
============================
AI Bug Reproduction Condition Verbalizer for Game Developers

Just write the symptom roughly and get:
  - Reproduction steps (step by step)
  - Environment-specific test cases (resolution, OS, hardware differences)
  - QA scenarios (with priority)
  - Bug report (Markdown format)

MIT License | dosanko_tousan + Claude
"""

import anthropic
import argparse
import json
from datetime import datetime
from pathlib import Path
from dataclasses import dataclass
from typing import Optional


@dataclass
class BugInput:
    symptom: str
    env_info: str = ""
    extra: str = ""
    game_title: str = ""


@dataclass  
class QAScenario:
    priority: str  # P1 / P2 / P3
    scenario: str
    steps: list[str]
    pass_condition: str


@dataclass
class EnvTestCase:
    env: str
    test_procedure: str
    check_points: list[str]


@dataclass
class BugReport:
    bug_id: str
    title: str
    severity: str  # Critical / High / Medium / Low
    category: str
    reproduction_steps: list[str]
    expected_behavior: str
    actual_behavior: str
    environment_test_cases: list[EnvTestCase]
    qa_scenarios: list[QAScenario]
    root_cause_hypothesis: str
    workaround: str
    related_areas: list[str]


SYSTEM_PROMPT = """You are a specialist AI for game QA engineering.
You respond as a senior QA engineer with 10+ years of practical experience.

From a roughly written bug symptom by a developer, you structure and output the following.

Always return output in JSON format. No code blocks or explanatory text.

JSON structure:
{
  "bug_id": "BUG-YYYYMMDD-NNN format (use today's date)",
  "title": "Concise bug title (under 50 characters)",
  "severity": "Critical/High/Medium/Low",
  "category": "Display/Audio/Controls/Performance/Crash/Save-Load/Network/Other",
  "reproduction_steps": [
    "1. Environment preparation steps",
    "2. Specific operation steps",
    "3. Operation that triggers the bug",
    "4. Verification steps"
  ],
  "expected_behavior": "Specifically what should happen",
  "actual_behavior": "Specifically what is happening",
  "environment_test_cases": [
    {
      "env": "Environment name (e.g.: PC/Windows11/4K/RTX3080)",
      "test_procedure": "Test procedure for this environment",
      "check_points": ["Check point 1", "Check point 2", "Check point 3"]
    }
  ],
  "qa_scenarios": [
    {
      "priority": "P1/P2/P3",
      "scenario": "Test scenario name",
      "steps": ["Step 1", "Step 2", "Step 3"],
      "pass_condition": "Pass condition (specific)"
    }
  ],
  "root_cause_hypothesis": "Technical root cause hypothesis (for engineers)",
  "workaround": "Temporary workaround (empty string if none)",
  "related_areas": ["Functions/areas that may be affected"]
}

Severity criteria:
- Critical: Game won't launch, save data corruption, frequent crashes
- High: Major feature non-functional, high reproduction rate in specific environments
- Medium: Partial feature issues, workaround available
- Low: Minor display glitches, almost no impact"""


def analyze_bug(bug_input: BugInput, client: Optional[anthropic.Anthropic] = None) -> BugReport:
    """Analyze bug symptom and return structured BugReport"""
    if client is None:
        client = anthropic.Anthropic()

    parts = [f"Bug symptom: {bug_input.symptom}"]
    if bug_input.env_info:
        parts.append(f"Environment info: {bug_input.env_info}")
    if bug_input.extra:
        parts.append(f"Additional info: {bug_input.extra}")
    if bug_input.game_title:
        parts.append(f"Game title: {bug_input.game_title}")
    
    user_content = "\n".join(parts)

    message = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=3000,
        system=SYSTEM_PROMPT,
        messages=[{"role": "user", "content": user_content}]
    )

    raw = message.content[0].text.strip()
    if raw.startswith("```"):
        raw = "\n".join(raw.split("\n")[1:-1])

    data = json.loads(raw)
    
    env_cases = [EnvTestCase(**case) for case in data.get("environment_test_cases", [])]
    qa_scenarios = [QAScenario(**qa) for qa in data.get("qa_scenarios", [])]
    
    return BugReport(
        bug_id=data.get("bug_id", f"BUG-{datetime.now().strftime('%Y%m%d')}-001"),
        title=data.get("title", ""),
        severity=data.get("severity", "Medium"),
        category=data.get("category", "Other"),
        reproduction_steps=data.get("reproduction_steps", []),
        expected_behavior=data.get("expected_behavior", ""),
        actual_behavior=data.get("actual_behavior", ""),
        environment_test_cases=env_cases,
        qa_scenarios=qa_scenarios,
        root_cause_hypothesis=data.get("root_cause_hypothesis", ""),
        workaround=data.get("workaround", ""),
        related_areas=data.get("related_areas", [])
    )


def to_markdown(report: BugReport) -> str:
    """Convert BugReport to Markdown format"""
    severity_emoji = {"Critical": "🔴", "High": "🟠", "Medium": "🟡", "Low": "🟢"}
    priority_emoji = {"P1": "🔴", "P2": "🟠", "P3": "🟡"}
    emoji = severity_emoji.get(report.severity, "⚪")

    lines = [
        f"# {emoji} [{report.bug_id}] {report.title}",
        "",
        f"**Severity:** {report.severity}　**Category:** {report.category}",
        "",
        "## Reproduction Steps",
    ]
    lines.extend(report.reproduction_steps)
    lines.extend([
        "",
        "## Expected / Actual Behavior",
        f"- **Expected:** {report.expected_behavior}",
        f"- **Actual:** {report.actual_behavior}",
        "",
    ])

    if report.environment_test_cases:
        lines.append("## Environment-Specific Test Cases")
        for case in report.environment_test_cases:
            lines.append(f"### {case.env}")
            lines.append(case.test_procedure)
            for cp in case.check_points:
                lines.append(f"- [ ] {cp}")
            lines.append("")

    if report.qa_scenarios:
        lines.append("## QA Scenarios")
        for qa in report.qa_scenarios:
            p_emoji = priority_emoji.get(qa.priority, "")
            lines.append(f"### {p_emoji} {qa.priority}: {qa.scenario}")
            for step in qa.steps:
                lines.append(f"  {step}")
            lines.append(f"  **Pass Condition:** {qa.pass_condition}")
            lines.append("")

    if report.root_cause_hypothesis:
        lines.extend(["## Root Cause Hypothesis (For Engineers)",
                      report.root_cause_hypothesis, ""])

    if report.workaround:
        lines.extend(["## Temporary Workaround", report.workaround, ""])

    if report.related_areas:
        lines.append("## Impact Scope")
        for area in report.related_areas:
            lines.append(f"- {area}")
        lines.append("")

    lines.append(f"---")
    lines.append(f"*Generated by game-bug-analyzer v1.0 at "
                 f"{datetime.now().strftime('%Y-%m-%d %H:%M')}*")
    return "\n".join(lines)


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Game Bug Reproduction Verbalizer")
    parser.add_argument("--symptom", help="Bug symptom")
    parser.add_argument("--env", default="", help="Environment info")
    parser.add_argument("--extra", default="", help="Additional info")
    parser.add_argument("--game", default="", help="Game title")
    parser.add_argument("--json", action="store_true", help="JSON output")
    args = parser.parse_args()

    if args.symptom:
        bug_input = BugInput(args.symptom, args.env, args.extra, args.game)
        report = analyze_bug(bug_input)
        if args.json:
            print(json.dumps(report.__dict__, ensure_ascii=False,
                             indent=2, default=lambda o: o.__dict__))
        else:
            print(to_markdown(report))

Due to the extreme length of this article, Volumes 2-6 continue with the same pattern: complete Python implementations with Claude API integration for game text localization (Vol.2), asset natural language search (Vol.3), cross-platform QA scenario generation (Vol.4), Steam review analysis (Vol.5), and an integration pipeline (Vol.6).

The full implementations are available in the Japanese version of this article.

Vol.2: Batch Game Text Localization — game_localizer.py

3.1 Problem Definition

For text-heavy games (RPGs, visual novels, adventure games), localization means:

  • Hire professional translators → weeks, high cost
  • Use Google Translate → unstable quality
  • Translate internally → engineer hours vanish

According to GDC 2025 data, there are cases where AI localization reduced translation time from weeks to hours.

Expressing hours mathematically. Text line count $L$, human translation cost per line $c_h$, AI translation cost $c_a$:

$$\text{Reduction rate} = 1 - \frac{c_a}{c_h} = 1 - \frac{0.5 \text{ min}}{15 \text{ min}} \approx 0.97$$

97% hour reduction. However, post-process review is still needed.

Even including review costs:

$$T_{\text{total}}^{\text{AI}} = c_a \cdot L + c_{\text{review}} \cdot L \approx 3 \text{ min} \cdot L$$

Traditional: $T_{\text{total}}^{\text{human}} = 15 \text{ min} \cdot L$

For $L = 1000$ lines: $T^{\text{human}} = 250h \to T^{\text{AI}} = 50h$

3.2 Key Features

  • CSV/JSON/Excel text data batch translation
  • Game-specific terminology and proper noun preservation
  • Variable placeholder protection ({name}, etc.)
  • High-precision translation using context information
  • Translation quality checks (character count, variable matching)
  • Differential updates (re-translate only changed portions)

(Full implementation available in the Japanese version)

3.3 Glossary JSON Example

{
  "魔王": {"en": "Demon Lord", "zh": "魔王", "ko": "마왕"},
  "剣の街": {"en": "Sword City", "zh": "剑之城", "ko": "검의 도시"},
  "スキル": {"en": "Skill", "zh": "技能", "ko": "스킬"},
  "HP": {"en": "HP", "zh": "HP", "ko": "HP"},
  "ギルド": {"en": "Guild", "zh": "公会", "ko": "길드"}
}

Vol.3: Asset Folder Natural Language Search — game_asset_search.py

4.1 Problem Definition

In large-scale game development, asset counts reach tens to hundreds of thousands.

"Where was that blue sword texture again?"
"Show me all the boss idle animations."
"I want to find all unused SE files."

Digging through folders to find things. These "search" hours accumulate.

With $N$ assets, search cost per query $t_s$, queries per day $q$:

$$T_{\text{search/day}} = t_s \cdot q$$

If $t_s = 3\text{ min}$, $q = 20\text{ queries/day}$, then $T_{\text{search/day}} = 60\text{ min}$.

1 hour per day vanishes into "searching." Over 250 working days per year, that's 250 hours.

After AI search introduction:

$$T_{\text{search/day}}^{\text{AI}} = 0.2\text{ min} \cdot q = 4\text{ min/day}$$

93% reduction.

4.2 Key Features

  • Directory scanning with automatic asset type classification
  • Claude API generates descriptions and tags for each file from filenames
  • Index caching (builds once, uses cache afterward)
  • Natural language query search ("blue sword texture", "boss SE")
  • Type filtering (texture/audio/model, etc.)
  • Interactive mode

(Full implementation available in the Japanese version)

Vol.4: Cross-Platform QA Scenario Auto-Generation — game_qa_generator.py

5.1 Problem Definition

In 2025 game development, cross-platform support for PC, Switch, PS5, Xbox, and Mobile is assumed.

Testing one feature on 5 platforms. Writing test scenarios manually:

$$T_{\text{qa_write}} = N_{\text{features}} \times N_{\text{platforms}} \times t_{\text{scenario}}$$

If $N_{\text{features}} = 50$, $N_{\text{platforms}} = 5$, $t_{\text{scenario}} = 20\text{ min}$:

$$T_{\text{qa_write}} = 50 \times 5 \times 20 = 5000\text{ min} \approx 83\text{ hours}$$

QA scenario creation alone consumes 2 weeks.

After AI generation:

$$T_{\text{qa_write}}^{\text{AI}} = N_{\text{features}} \times t_{\text{review}} \approx 50 \times 5\text{ min} = 250\text{ min} \approx 4\text{ hours}$$

83 hours → 4 hours. 95% reduction.

5.2 Key Features

  • Platform profiles for PC/Switch/PS5/Xbox/Mobile with specific concerns
  • Automatic generation of basic tests, platform-specific tests, edge cases, and abnormal cases
  • Priority-ranked test matrix (P1/P2/P3)
  • Markdown and CSV (Google Sheets compatible) output
  • DualSense haptic feedback, Joy-Con, Xbox Quick Resume, etc. all covered

(Full implementation available in the Japanese version)

Vol.5: Steam Review Auto-Analysis → Development Priority Map — game_review_analyzer.py

6.1 Problem Definition

One of the most important tasks in the post-release operations phase is "reflecting player voices in development."

But reading and classifying Steam reviews one by one:

$$T_{\text{review_analysis}} = N_{\text{reviews}} \times t_{\text{read}}$$

If $N_{\text{reviews}} = 500$, $t_{\text{read}} = 2\text{ min}$, then $T = 1000\text{ min} \approx 17\text{ hours}$.

Moreover, when humans read:

  • They get pulled by reviews that made an impression
  • Bug reports and feature requests get mixed together
  • Priority judgments become subjective

With AI analysis:

$$T_{\text{review_analysis}}^{\text{AI}} \approx 30\text{ min} \text{ (500 reviews)}$$

Plus:

  • Objective classification
  • Automatic prioritization by frequency
  • Output in a format the dev team can immediately action

6.2 Key Features

  • Steam Web API integration for review fetching
  • Automatic classification: bug/request/praise/complaint/other
  • Sentiment analysis with scoring
  • Topic clustering across reviews
  • Development priority map with P1/P2/P3 action items
  • Markdown report generation

(Full implementation available in the Japanese version)

Vol.6: Integration Pipeline — game_dev_pipeline.py

7.1 Why a Pipeline Is Needed

Using the 5 tools individually is already powerful. But connecting them makes them even stronger.

7.2 Setup Steps

# 1. Setup
pip install anthropic
export ANTHROPIC_API_KEY="your-api-key"

# 2. Project initialization
python game_dev_pipeline.py init "Demon Kill Demon" 

# 3. Edit pipeline_config.json
{
  "game_title": "Demon Kill Demon",
  "asset_dir": "./Assets",
  "texts_dir": "./Texts",
  "bugs_file": "./bugs.txt",
  "steam_app_id": "XXXXXX",
  "platforms": ["PC", "Switch", "PS5"],
  "output_dir": "./reports"
}

# 4. Daily execution (just this every morning)
python game_dev_pipeline.py daily

8. Conclusion: Architecture of Subtraction

Reviewing the 5 tools + integration pipeline implemented in this paper:

Tool Reduction Target Reduction Rate
Vol.1: Bug Verbalizer Bug report creation hours ~92%
Vol.2: Localization Translation hours ~80% (incl. review)
Vol.3: Asset Search Search hours ~93%
Vol.4: QA Generation Test scenario creation ~95%
Vol.5: Review Analysis Review reading/classification ~97%

Total: 80–95% reduction of $T_{\text{peripheral}}$.

This is not "addition."

No new features were added. What shouldn't have been there was removed.

T_total = T_core + T_peripheral
       ↓  subtraction
T_total' = T_core + ε

Engineers can focus on "their work as engineers."
Artists can focus on "their work as artists."
The game gets better.

That's everything in this paper.

Appendix A: Complete File List

game-dev-tools/
├── game_bug_analyzer.py      # Vol.1
├── game_localizer.py         # Vol.2
├── game_asset_search.py      # Vol.3
├── game_qa_generator.py      # Vol.4
├── game_review_analyzer.py   # Vol.5
├── game_dev_pipeline.py      # Vol.6 (Integration)
├── bugs_sample.txt           # Bug batch sample
├── glossary_sample.json      # Glossary sample
├── pipeline_config.json      # Pipeline config
└── README.md

Appendix B: Installation

pip install anthropic
export ANTHROPIC_API_KEY="your-api-key"

# If Excel support is needed
pip install openpyxl

# Verify all tools
python game_bug_analyzer.py --symptom "test" --env "Windows"
python game_localizer.py --help
python game_asset_search.py --help
python game_qa_generator.py --help
python game_review_analyzer.py --help

Appendix C: License

MIT License

Copyright (c) 2026 dosanko_tousan

co-authored with Claude (Anthropic, claude-sonnet-4-6)
Generated under v5.3 Alignment via Subtraction

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software.

This paper was written the day after Experience Inc.'s Ataka tweeted "Debugging at home, found 3 bugs."
If you think it's useful, use it. If you like it, tell me "I want a tool like this." I'll make it in 5 minutes.

Note: The full Python implementations for all 6 volumes are available in the Japanese version of this article on Qiita. This English version includes the complete Vol.1 implementation and summaries of Vols.2-6 with key features and mathematical models. The code is identical — only comments and documentation are translated.

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?