Rule System Design: From Game Mechanics to Workflow Boundaries

Rule systems are ubiquitous: difficulty curves in games, incentive models in learning products, and employment status determination processes in enterprises. Fundamentally, they are all constrained decision logic systems. They collectively address three core questions: how to layer constraints, how to provide instant feedback, and how to ensure boundaries are decidable. Using four typical scenarios as entry points, this article abstracts reusable design patterns for developers to reference when designing product mechanisms and workflow systems.

1. Difficulty Curves: Early Thresholds and Layered “Skippable” Constraints

Many action games receive feedback that they are “too difficult in the early stages.” However, a closer look reveals that the difficulty is often concentrated in a few specific nodes, and most of these nodes can be bypassed. This reflects a classic layered constraint design:

• Mandatory levels serve teaching and pacing functions with moderate difficulty;
• Optional challenges provide high-difficulty content to satisfy core users without blocking the main progression;
• Skip paths (detours, alternative routes, low-skill-requirement alternatives) act as pressure relief valves.

The technical value of this structure lies in transforming “difficulty” from a monotonically increasing curve into a directed graph, where multiple paths can reach the endpoint. For players struggling with action mechanics, obtaining a high-damage weapon early via a detour—capable of depleting enemy resource bars—significantly reduces subsequent progression costs. In system design terms, this is equivalent to trading a one-time resource investment for a lowered threshold in subsequent decision logic.

It is worth noting that these “low-operation-cost solutions” are often criticized by core users as “impure.” Yet, from a system perspective, this is precisely a method for user segmentation: hardcore players take the challenge path, while casual players take the alternative path. Both share the same underlying rule engine; only the entry points differ.

Design Takeaway: Any system with a progression concept should provide equivalent but differently-costed paths for users of varying skill levels. One-way transitions between paths should be allowed (moving from hard to easy is viable; moving from easy to hard should not be penalized).

2. Automated Assistance: Folding High-Frequency Operations into Default Behaviors

Some players utilize an “unconventional” setup: binding the block action to the attack key, merging normal attacks with auto-blocking. Pressing the button attacks normally, while incoming attacks are automatically blocked. This approach is highly effective in the early game but quickly fails in the mid-to-late stages.

This case reveals a universal principle: automation based on folding high-frequency operations is only effective when the decision pattern is singular.

• In the early game, enemy attack patterns are limited and wind-ups are obvious, so a singular block decision covers most threats.
• In the mid-to-late game, enemies introduce multi-hit attacks, delayed attacks, and unblockable attacks. Players must switch strategies based on the opponent’s state (e.g., actively breaking guards when the enemy enters a buffed state, or passively dodging when they charge up).

In other words, the effectiveness of automation depends on the size of the state space. When the state space is small, folding is safe; when it expands, folding fails. This aligns with the “default configuration” concept in software engineering: defaults work for common paths, but once branching increases, explicit configuration becomes mandatory.

Design Takeaway: Automation capabilities must come with explicit boundary descriptions. As the state space expands, the system should actively degrade automation into “suggestions” rather than “executions,” preventing users from developing false dependencies in inapplicable scenarios.

3. Point-Based Incentives: Converting “Learning Time” into “Redeemable Resources”

A common approach for incentivizing children’s learning is converting completed exercises into consumable time quotas: solving a specific number of questions earns points, which can be redeemed for entertainment time. This separates focused learning from free play. Compared to the negative constraint of “limiting entertainment time,” this positive point-based model offers several structural advantages:

1. Instant Feedback: Points are settled immediately upon completing a unit, ensuring a short feedback cycle and a strong association between behavior and outcome.
2. Resource Pooling: Points enter a unified account where they can be accumulated and planned, giving users a sense of control.
3. Efficiency Sensitivity: Higher output per unit time yields better exchange ratios, naturally encouraging focus over dawdling.

From a system implementation perspective, this model requires attention to three aspects:

• Settlement Atomicity: Each answer session and point crediting transaction should be an atomic unit to avoid disputes over “completed work without credited points.”
• Exchange Rate Stability: Once set, the ratio should not be frequently adjusted, or it will undermine user trust in the rules.
• Caps and Decay: Daily point caps or redemption decay rates must be established to prevent extreme behaviors (e.g., question grinding) from distorting the incentive objectives.

A phenomenon worth noting is the behavior of completing homework in a concentrated burst before a holiday to reduce the holiday burden. This is essentially resource prepayment on a temporal dimension, isomorphic to the point model. If a system allows “early completion, delayed consumption,” it can convert concentrated effort into long-term benefits, improving overall efficiency.

Design Takeaway: The key to a positive point-based model lies not in the rate ratio, but in reliable settlement, stable rules, and clear boundaries. Missing any of the three will degrade the incentive into a game of exploitation.

4. Workplace Injury Determination: Why Boundary Decisions Cause Disputes

Whether slipping in a company cafeteria constitutes a workplace injury is a classic boundary determination problem. The root of the dispute lies not in the conclusion, but in the ambiguous definition of determining factors.

Standard determination logic examines several dimensions:

• Location: Whether it belongs to the workplace or its reasonable extension;
• Time: Whether it falls within a reasonable range of working hours;
• Behavior: Whether it is related to work (e.g., necessary physiological needs);
• Causality: Whether the injury was directly caused by the behavior.

The problem is that “reasonable extension,” “reasonable range,” and “necessary needs” are fuzzy predicates. Different decision-makers may reach different conclusions based on the same facts. For instance, being injured while eating in a residential downstairs before commuting differs significantly in location and behavioral relevance from being injured in a company cafeteria. If the determination criteria do not explicitly classify “cafeteria,” execution-level discrepancies will occur.

From a system design perspective, this is a classic case of rules lacking enumeration. Decidable rules should replace fuzzy predicates with enumerable condition sets, for example:

Determination Conditions (Illustrative):
1. Incident location ∈ {Workplace, Areas within the Workplace Affiliated Facilities List}
2. Incident time ∈ Working hours ∪ Necessary physiological need periods
3. Behavior purpose ∈ {Fulfilling work duties, Satisfying necessary physiological needs}
4. Direct causality exists between the injury and the above behavior
If 1-4 are satisfied, the determination is valid

By explicitly defining the “affiliated facilities list” and clarifying “necessary physiological need periods,” the room for dispute shrinks significantly. Conversely, if rules rely on the subjective understanding of the executor, disputes will persist regardless of the conclusion’s correctness.

Design Takeaway: Any process requiring manual discretion should transform fuzzy conditions into enumerable conditions or checklists. Parts that cannot be enumerated should be explicitly marked as “requires manual judgment” with clear criteria, rather than being hidden in vague wording.

5. Commonalities: Four Reusable Rule Design Principles

Synthesizing the above scenarios, we can extract four universal principles:

1. Constraint Layering: Separate hard constraints from soft constraints. Hard constraints ensure process reachability, while soft constraints accommodate user segmentation. Allow equivalent alternative paths.
2. Instant Feedback: Any incentive or penalty should be temporally adjacent to the triggering behavior. Settle units atomically to avoid delayed attribution.
3. Decidable Boundaries: Replace fuzzy predicates with enumerable conditions or checklists. Explicitly mark intervals requiring manual judgment to reduce execution discrepancies.
4. Bounded Automation: Automation capabilities must include applicable conditions and actively degrade as the state space expands, preventing false dependencies.

These four principles are not limited to gaming or institutional scenarios; they are equally applicable to approval workflows, risk control rules, task systems, point economies, and various other product mechanisms. The challenge of rule design is never writing the clauses, but ensuring they remain executable, explainable, and reproducible at the boundaries. Mastering this naturally reduces disputes and ensures a consistent user experience.