Phase 1: Identify Balance Domain

If no argument, ask the user which system to check

Phase 1:

Identify Balance Domain

What Is This?

The "Phase 1: Identify Balance Domain" skill on the Happycapy Skills platform is the initial step in the automated game balance analysis workflow. This phase is responsible for determining which system or aspect of the game should be analyzed for balance-related issues. It leverages user input or file path arguments to infer the relevant balance domain, such as combat, economy, progression, or loot systems. If no specific argument is provided, the skill interacts with the user to clarify which system requires a balance check.

This skill is implemented as part of the balance-check module, which is designed to analyze game balance data, formulas, and configuration files to identify outliers, broken progressions, degenerate strategies, and economy imbalances. By accurately identifying the balance domain, this phase ensures that subsequent analysis is contextually appropriate and targets the correct data sets and design documents.

Why Use It?

Identifying the correct balance domain is critical for effective and efficient balance analysis in game development. Games are complex systems with multiple interdependent subsystems-combat, economy, progression, and loot each have distinct data structures, metrics, and design goals. Running a generic or misdirected balance check can lead to irrelevant results, wasted computational resources, or overlooked issues.

By using this skill, design teams can:

  • Streamline the balance analysis process: Automatically focus on the relevant data and design intent for the specified domain.
  • Reduce manual errors: Prevent accidental analysis of unrelated systems or data files.
  • Improve report accuracy: Ensure that subsequent balance checks (such as DPS calculations or economy faucet/sink analysis) are grounded in the correct context.
  • Facilitate iterative design: Quickly re-analyze targeted systems after any data or balance modification.

How to Use It

The balance-check skill can be invoked directly by the user, either with or without arguments. The main mechanisms are as follows:

1. With Argument:

  • If the user supplies an argument (e.g., system name or path to a data file), the skill analyzes the argument to infer the balance domain.
  • If a file path is provided, the skill loads the file and uses its content to determine the domain.
  • If a domain name is specified (e.g., "combat", "economy"), it selects the corresponding balance checks.

2. Without Argument:

  • If the skill is triggered without any arguments, it prompts the user to specify which system to analyze, ensuring clarity and intentionality.

Here is a simplified pseudocode example illustrating this logic:

def identify_balance_domain(arguments):
    domain_map = {
        "combat": ["weapon", "dps", "ability", "damage"],
        "economy": ["currency", "resource", "shop", "price"],
        "progression": ["xp", "level", "powercurve"],
        "loot": ["drop", "rarity", "inventory", "pity"]
    }

    if arguments:
        arg = arguments[0]
        if os.path.isfile(arg):
            content = open(arg).read()
            for domain, keywords in domain_map.items():
                if any(keyword in content for keyword in keywords):
                    return domain
            return "unknown"
        else:
            for domain in domain_map:
                if domain in arg.lower():
                    return domain
    else:
        user_input = input("Which system would you like to check? (combat, economy, progression, loot): ")
        return user_input.strip().lower()

Example Usage:

  • User inputs: balance-check combat → Domain is set to "combat"
  • User inputs: balance-check assets/data/weapons.json → File is loaded, content scanned for combat-related keywords
  • User inputs: balance-check → System prompts: "Which system would you like to check?"

When to Use It

This skill should be used whenever a balance analysis or report is required, especially after making changes to any balance-related data or game design. Specific triggers include:

  • After modifying balance data in configuration files or databases (e.g., updating weapon stats, changing in-game economy values).
  • When prompted by a designer or developer with commands like "balance report," "check game balance," or "run a balance check."
  • During pre-release QA cycles to ensure that no unintended imbalances have been introduced.
  • When diagnosing player feedback related to perceived unfairness or progression issues.

Important Notes

  • Domain Accuracy: The accuracy of subsequent analysis phases depends on correct domain identification. Ambiguous or incorrectly specified arguments may result in incomplete or irrelevant balance checks.
  • Argument Flexibility: The skill accepts both system names and file paths as arguments, increasing its versatility in different workflows.
  • User Interaction: If no argument is provided, the skill must actively prompt the user. This ensures intentionality and prevents analysis of the wrong system.
  • Extensibility: The identification logic can be extended to support new domains or more granular subsystems as game complexity increases.
  • Integration: This phase is designed to work in conjunction with later phases (file reading, design document parsing, and analysis) in the balance-check workflow.

Correct use of Phase 1 ensures that all subsequent steps in the balance analysis pipeline are contextually grounded, leading to more actionable and accurate balance reports for design teams.