# Torqestra World League — Founding Specification v0.1.2

Prepared for Boon · 31 October 2026

Status: original proposed game design for a virtual prototype. All numerical values are provisional tuning parameters, not validated balance or real engineering specifications. The former working name “Forge League” (including “ForgeLeague”) was retired by the project owner on 31 October 2026 following a preliminary IP/name-conflict screen. Do not use it for public branding, domains, logos or new project materials. The project owner selected “Torqestra World League” on 31 October 2026. The sport/game is called “Torqestra”; the league is “Torqestra World League” (TWL). Pronunciation: tork-ESS-truh. Preliminary web screening found no obvious exact-name commercial or gaming use for Torqestra; formal trademark clearance, domain availability and social-handle availability remain unconfirmed. Selection of the name is not legal clearance. This document defines the sport and the first prototype scope; it does not claim a working simulator exists.

## 1. The sport in one minute

Two teams each field three engineered robots. They fight for three control zones while trying to disable opposing machines. Teams choose how to distribute a shared construction allowance among speed, armour, energy, cooling and weapons. The winner must build well and use the arena well.

The distinctive proposed feature is the **shared engineering allowance**: a team can field three balanced machines or spend heavily on one machine and support it with two inexpensive specialists. A powerful machine cannot be everywhere at once.

This is initially a virtual management sport. Owners assemble legal robots and choose tactics; the simulator resolves matches. AI writers turn verified events into commentary and league news. Real robot manufacture, real weapon design and live human driving are outside the first release.

## 2. Match format and results

| Rule | Prototype value |
|---|---|
| Active robots | Exactly 3 per side |
| Registered roster | 5 robot identities per team; select 3 before a match |
| Rounds | Exactly 3 regulation rounds |
| Round length | 180 simulated seconds |
| Match winner | Higher cumulative regulation score |
| Arena | 30 × 20 metres, enclosed, flat |
| Control zones | 3 circles, each 2 metres in radius |
| Zone scoring | 1 point per full second of uncontested occupation |
| Disable award | 20 points once per opposing robot per round |
| Respawns | None within a round |
| Team elimination | Round ends after scoring the elimination tick; no remaining-time bonus |
| Side allocation | A starts west in rounds 1 and 3; B starts west in round 2; reverse allocation in return fixture |

Scores reset to zero for each round but are added to the match total. Winning two rounds does not automatically win the match. This avoids an ambiguous mixture of round wins and cumulative points.

A robot occupies a zone when its centre is inside or on the circle, it is not disabled and its movement system is functional. Multiple friendly robots do not multiply scoring. If both sides qualify, neither scores. Empty zones score nothing: ownership does not persist after departure. Each zone maintains a continuous occupation timer; a change in qualifying side, a contest or vacancy resets the partial second. The same side must qualify for a full second to earn a point.

An immobilised robot cannot hold a zone even if its weapon remains operational. Deliberately draining a battery therefore cannot create a permanent scoring obstacle.

Regulation ties are draws in the regular season. Playoff ties use one 60-second overtime with fully restored locked builds and only the central zone active. Higher overtime score wins. If still tied, repeat with sides exchanged, for at most four overtime rounds. A remaining tie uses a precommitted seeded draw, recorded as an administrative tiebreak, never disguised as a combat victory. This fallback needs review before a public competition.

## 3. Arena specification

Coordinates run from x = 0 to 30 and y = 0 to 20. West spawns are (3,5), (3,10), (3,15); east spawns are (27,5), (27,10), (27,15). Zones are centred at (15,4), (15,10), (15,16).

Four indestructible rectangular covers occupy x = 9–11 and 19–21, each at y = 6–8 and 12–14. Covers block movement and projectiles. Walls block both. There are no pits, elevated surfaces, destructible terrain, airborne movement or random hazards in v0.1.

The map is mirrored across both centre axes. Each fixture must retain map version and starting side. Distances and reach use robot collision circles, not decorative artwork. Legal chassis have a common 0.6 m collision radius in the prototype. Disabled robots remain solid obstacles until the round ends; they cannot score, be targeted for points or be moved by pushing.

## 4. Robot construction standard

Each robot consists of one chassis, one drive, one battery, one cooling package, one primary weapon, four armour panels and one optional utility module. Every slot must resolve to a catalogue item; no free-text component can affect a match.

| Constraint | Proposed limit |
|---|---|
| Total fitted mass | At most 120 kg per robot and 300 kg per active team |
| Component cost | At most 110 construction credits per robot and 270 per team |
| Main weapon | Exactly one per robot |
| Utility | Zero or one per robot |
| Power | Instantaneous draw cannot exceed battery output |
| Stored energy | Finite; all active systems consume it |
| Armour | Front, rear, left and right panels selected separately |
| Build changes | Locked after lineup submission until match ends |

Mass includes all installed parts. Credits are sporting balance units, not money or a claim about manufacturing prices. There is no separate selectable attack, defence or overall rating. UI ratings may summarise derived performance but never feed back into the engine.

Validation rejects missing slots, incompatible mounts, negative values, over-budget teams, duplicate robot identities and configurations whose idle systems alone exceed output capacity. A failed validation gives a specific explanation such as “team mass 312 kg exceeds 300 kg.”

## 5. Initial component catalogue

These are game parameters. Damage units (DU), armour points (AP), integrity points (IP) and heat units (HU) are explicitly fictional. Metres, seconds, kilograms, kilowatts and kilowatt-hours provide consistent simulation bookkeeping without claiming a physically accurate robot model.

### Chassis: six starting foundations

All chassis have one weapon mount and one utility slot; their names imply tendencies, not forced roles.

| Chassis | Mass kg | Credits | Core IP | Suggested use |
|---|---:|---:|---:|---|
| Swift | 20 | 12 | 70 | Zone runner |
| Scout | 24 | 14 | 85 | Mobile ranged unit |
| Striker | 28 | 16 | 100 | General combat |
| Anchor | 34 | 19 | 125 | Defender |
| Bastion | 40 | 23 | 150 | Durable frontline |
| Utility | 27 | 15 | 95 | Support platform |

### Drive packages

Acceleration is base acceleration × (80 / fitted mass), capped at 5 m/s². Maximum speed is listed speed × min(1.2, sqrt(80 / fitted mass)); absolute cap 7 m/s. Turning rate uses the same square-root factor, capped at 240 degrees/s. These are transparent game approximations.

| Drive | kg | Credits | Base acceleration m/s² | Listed speed m/s | Turn °/s | Peak kW | IP |
|---|---:|---:|---:|---:|---:|---:|---:|
| Wheels | 14 | 12 | 3.5 | 6.0 | 180 | 8 | 55 |
| Tracks | 22 | 16 | 2.5 | 4.0 | 120 | 10 | 85 |

Drive draw is peak × max(throttle fraction, absolute turn fraction), with both fractions clamped to [0,1]. Passive braking consumes no power. No free rolling persists when movement is disabled.

### Batteries and cooling

| Battery | kg | Credits | Capacity kWh | Maximum output kW |
|---|---:|---:|---:|---:|
| Compact | 10 | 8 | 0.6 | 16 |
| Standard | 16 | 12 | 1.0 | 24 |
| Endurance | 24 | 18 | 1.6 | 30 |

Core and sensors consume 0.5 kW while active. Energy consumed in a tick is total kW × tick seconds / 3600. Starting charge equals catalogue capacity. Empty battery causes a permanent disable for the round. Batteries have no separate damage location in v0.1; core damage represents protected internals.

| Cooling | kg | Credits | Removal HU/s | Active kW |
|---|---:|---:|---:|---:|
| Passive | 4 | 4 | 3 | 0 |
| Fan | 8 | 7 | 7 | 1 |

Heat starts at zero. Drive generates 0.4 HU per kJ drawn; the core/sensors generate 0.2 HU/s. Weapons add the listed heat on firing. Cooling applies each tick, bounded at zero. At 100 HU the weapon shuts off and movement speed is halved; normal operation resumes only below 70 HU. Overheating does not inflict additional damage in v0.1.

### Weapons

All are abstract arena equipment, with no physical construction instructions. All have 60 IP. Their fixed forward mount requires turning the robot to aim. A fire command must lie within 5 degrees of the forward heading. Ready weapons draw no power; a shot consumes firing power for one 0.05 s tick. Cooldown begins only after a successful fire event.

| Weapon | kg | Credits | Range m | DU/hit | Cooldown s | Firing kW | HU/shot |
|---|---:|---:|---:|---:|---:|---:|---:|
| Ram actuator | 14 | 10 | 0.3 surface gap | 18 | 1.0 | 6 | 7 |
| Impact hammer | 23 | 18 | 0.8 surface gap | 30 | 2.0 | 12 | 14 |
| Pulse launcher | 18 | 20 | 10 centre distance | 14 | 1.2 | 14 | 10 |

Melee uses the nearest valid target surface along the aiming direction, subject to reach and cover. The launcher fires a straight projectile at 20 m/s and expires after 10 m of travel. First collision absorbs it; friendly robots can intercept and receive damage. A projectile can hit only once. No splash damage, critical-hit rolls, penetration or homing exist initially. Visual muzzle position must not change collision origin or effective range.

### Armour and utilities

| Armour, per panel | kg | Credits | Starting AP |
|---|---:|---:|---:|
| Light | 2 | 2 | 12 |
| Medium | 4 | 3 | 24 |
| Heavy | 6 | 5 | 36 |

| Utility | kg | Credits | Effect |
|---|---:|---:|---|
| None | 0 | 0 | No additional effect |
| Reserve armour | 6 | 6 | +10 starting AP to each panel |
| Capture beacon | 6 | 8 | Maintains zone eligibility at up to 0.5 m beyond normal radius; no extra scoring rate |

Beacon eligibility is measured against the robot centre. An enemy qualifying by either normal range or beacon range contests the zone. The beacon effect is passive and lasts until disable. Utility-specific damage is outside this version. Support initially means protecting teammates, intercepting attacks and contesting zones; there is no healing beam or in-match repair.

## 6. Example legal team

| Build | Parts | Mass | Credits |
|---|---|---:|---:|
| Runner | Swift, wheels, compact, passive, ram, 4 light panels, beacon | 76 kg | 62 |
| Duelist | Striker, wheels, standard, fan, launcher, 4 medium panels, no utility | 100 kg | 79 |
| Guardian | Bastion, tracks, standard, fan, hammer, 4 light panels, reserve armour | 123 kg | 90 |

The Guardian above intentionally illustrates a rejected build: 123 kg exceeds the individual limit. Replacing its fan with passive cooling yields **119 kg and 87 credits**. The corrected active team totals **295 kg and 228 credits**, satisfying both team limits. It sacrifices cooling to fit the heavier chassis and drive. Unspent credits cannot buy an exception to the mass cap.

These are starting test builds, not recommended dominant strategies. The catalogue may make some options too efficient; that is a balance question requiring experiments.

## 7. Damage and disable rules

1. Resolve the hit against the target's position and heading at impact.
2. Select the armour sector from the incoming direction relative to the target: front [-45°,45°), right [45°,135°), rear [135°,180°] or [-180°,-135°), left [-135°,-45°). Positive angles are clockwise in this definition.
3. Armour absorbs min(current AP, incoming DU), losing the same AP. Excess becomes internal damage.
4. Excess hits core for front/rear impacts and drive for left/right impacts, unless the attacker explicitly selected the weapon aim mode before firing.
5. Weapon aim mode sends excess to weapon integrity and reduces the shot's initial DU to 75%. The initial prototype uses this explicit targeting abstraction rather than invisible random component selection.
6. Integrity and AP never fall below zero. Overflow after a component reaches zero is discarded for that hit. Subsequent ordinary hits to a destroyed drive location route internal damage to the core. Weapon-aim hits against an already destroyed weapon are rejected before firing.

A core at zero or an empty battery disables immediately. Drive at zero immobilises immediately; if continuously immobilised for 10 seconds, the robot is disabled, even if it can still fire. Weapon at zero prevents firing but permits movement and scoring. Nonzero component integrity has no gradual performance penalty in this version, keeping feedback understandable.

A disable awards 20 points to the opposing team regardless of cause, including self-exhaustion or friendly fire. Each robot can generate this award only once per round. Individual knockout credit is assigned to the last enemy robot to cause internal damage within 10 seconds; otherwise the result is recorded as an unassisted team disable. There are no separate ram-collision damage events: collision itself causes no damage, preventing unlimited contact damage exploits.

## 8. Round reset, repairs and tactical control

Every round starts with all locked robots fully restored: integrity, armour, battery and heat. This intentionally revises the initial idea of limited between-round repairs. Carrying damage forward would obscure early balance tests and amplify first-round advantages. Persistent repair economics belong in a later experimental format.

Owners submit a lineup and a tactics sheet before the match. Between rounds they may change tactics but not components or active robot identities. Each sheet chooses per robot: preferred zone, target priority (nearest, lowest core fraction, highest opposing score contribution), engagement distance and retreat threshold as a core-integrity fraction.

Policies evaluate at 5 Hz from the same observation format. All robots can observe positions and headings of all robots and public health/heat values; cover blocks attacks but not information in v0.1. This avoids hidden-information inconsistencies while validating the sport. There is no LLM call inside movement or combat resolution.

Target ties resolve by distance, then stable robot ID. A retreating robot moves toward its original spawn while avoiding obstacles; it may shoot if a target remains valid. Controllers must include stuck detection and path replanning. Before competitive launch, mirrored robot IDs must be tested to detect ordering bias.

## 9. Simulation and reproducibility contract

Use a 20 Hz fixed simulation step (0.05 s); render independently. Store positions in integer millimetres and energy/heat in documented fixed-point units. Specify rounding to nearest with ties away from zero for non-negative magnitudes; signs are restored afterward. Never use wall-clock time to resolve gameplay.

Each tick: accept scheduled commands; reserve power; integrate movement; resolve collisions; create and move projectiles; collect hits; apply damage simultaneously; update energy and heat; apply disable rules; score zones; check round termination; record state checksum.

Allocate output power to core/sensors first, cooling second, commanded drive third and weapon fourth. Scale drive if only partial draw can be supplied; reject a shot if its remaining power or stored energy requirement cannot be met. The deterministic reservation algorithm must prevent total energy from going negative. A zero-energy end-of-tick state disables before zone scoring.

Resolve movement from the common tick-start snapshot, with symmetric collision handling. All attacks already legally created this tick still resolve if their firing robot is disabled later in the tick. Therefore simultaneous eliminations are possible and both disable awards count. Projectiles use swept segment collisions to prevent tunnelling. Equal-time collisions require a documented stable tie rule and a corresponding side-bias test.

Replay identity includes engine version, ruleset version, catalogue hash, map hash, robot build hashes, tactics, initial side, seed and complete command stream. Seeds control declared administrative draws only in this first model; normal combat uses no hidden randomness. Identical inputs must produce identical events and final checksum on supported runtimes.

Implementation gate: collision solver, fixed-point scale/overflow policy and pathfinding algorithm must be selected and documented before coding ranked matches. This founding specification is not a substitute for that engineering detail.

## 10. Founding league

Start with eight fictional teams, five registered robots per team and three active per fixture. Use a double round robin: 14 fixtures per team, 56 league fixtures total. Play one fixture per team per matchweek for 14 matchweeks. A match is nine simulated minutes at most in regulation, excluding presentation intervals.

Standings award 3 points for a win, 1 for a draw and 0 for a loss. Tie order: standings points, match score difference, total score, head-to-head mini-table using the same three measures; unresolved playoff-qualification ties use an extra playoff. Remaining non-qualification ties share rank. The top four enter semifinals (1 vs 4, 2 vs 3), then a final, each a single match with the specified overtime rules.

All teams have the same construction caps and catalogue access. No purchasable combat advantage. New parts and balance changes take effect only between declared competition phases. A season stores the exact ruleset it used. Do not retrospectively rewrite results after a patch.

Permanent development, sponsor money, staff progression, transfers, wear, salvage and limited repairs are deferred until the core game is balanced. Initially, personality comes from team identities, builds and tactics, not undisclosed statistical bonuses.

## 11. Records, commentary and news

Minimum records: Team, RobotIdentity, BuildVersion, ComponentVersion, TacticsVersion, Match, Round, Event and StandingSnapshot. A robot identity can acquire new build versions across fixtures without losing its career record. Published results reference immutable build versions.

Every event stores match ID, round, tick, event type, actor, target, before/after values and cause. Required events include fire, hit, armour depleted, component destroyed, overheat started/ended, zone contested, zone point, disable, round end and match end.

Public statistics include wins, points, zone-seconds scored, contested time, armour damage, internal damage, disables, energy use, shots, hits and overheating duration. Separate armour and internal damage so their meanings remain clear. Scoring-zone seconds credited to individuals are divided equally among qualifying friendly occupants; team totals remain authoritative.

Narrative flow: finalise result → derive fact sheet → select supported storyline → generate article → validate names, numbers and event references → publish. Generated speech by fictional coaches is labelled fictional. Do not invent a component failure, injury, feud or ownership transaction to explain an outcome.

Example template, not an actual result: “The runner scored [verified zone points] while its teammate held the central lane. The losing side spent [verified seconds] overheated.” Every numeric claim must trace to the event log. Failed validation uses a deterministic match-summary template.

## 12. Validation and balance plan

No simulated matches have been run for this document. Passing these gates is required before claiming the sport is balanced.

| Test | Acceptance condition |
|---|---|
| Build arithmetic | Every starter build matches component sums; illegal limits rejected |
| Scoring | Contest, boundary, partial-second reset, immobilisation and elimination cases match the rulebook |
| Energy and heat | No negative energy; exact power allocation; correct 100/70 hysteresis |
| Combat | Friendly fire, cover interception, armour sectors, overflow and simultaneous disable verified |
| Determinism | At least 100 repeated matches produce identical checksums for identical inputs |
| Symmetry | Mirrored builds/tactics give mirrored outcomes, except explicitly documented tie cases |
| Controller robustness | No crash or permanently stuck navigation across the test map suite |
| Narrative accuracy | Every numeric claim supported; deliberate false claims rejected |
| Replay | Event reconstruction and stored result agree |

For balance, create 12 legal team compositions spanning fast, heavy, ranged, melee and mixed builds, and 5 fixed tactical policies. Test all 66 unordered composition pairs, all 25 policy pairs and both side assignments: **3,300 matches**. Also test self-matches to expose side and ID bias. Report outcomes by composition and policy, rather than pooling away a strong counterstrategy.

Investigate compositions above 65% or below 35% aggregate win-equivalent rate, draws above 20%, average first disables before 15 seconds, and non-contested scoring dominating most matches. Win-equivalent rate counts a draw as half a win. These are diagnostic thresholds, not proof of fairness. A deterministic fixed suite is not an independent random sample; do not report misleading statistical confidence intervals.

Change one parameter family at a time, keep a change log, rerun the suite and test unseen tactics as a holdout. Explicit exploit tests include spawn camping, immortal wreck blockades, beacon edge camping, endless retreat, friendly-fire denial, same-tick mutual elimination and cheap chassis spam.

## 13. Implementation sequence and release gates

**Milestone A — rules executable:** machine-readable catalogue, validator and derived build calculator. Deliver legal examples and clear invalid-build messages. Resolve the remaining engine conventions.

**Milestone B — one complete match:** headless fixed-step engine, six robots, zones, collision, damage, logs and deterministic replay. Pass rule contract tests before visual work expands.

**Milestone C — watchable sport:** top-down 2D arena with robot silhouettes, team colours, visible weapons, armour arcs, battery/heat indicators, score and event timeline. Replays must show why a hit occurred and why a robot stopped.

**Milestone D — competitive sandbox:** run the matchup suite, publish balance findings, revise parameters and freeze a preseason ruleset. Generate eight fictional teams only after viable strategies exist.

**Milestone E — league world:** scheduler, standings, team/robot histories, verified commentary and match reports. Public ranked competition waits for simulation, replay and balance gates.

3D spectacle can follow a reliable 2D match. It must consume the same authoritative events; animations must never independently decide hits or results.

## 14. Decisions made and limits remaining

Chosen baseline: virtual autonomous robots; three per team; objective-plus-disable scoring; common collision size; modular construction; equal budgets; deterministic combat; fresh machines each round; event-grounded storytelling.

Still to validate: whether zone scoring overwhelms combat, whether the lighter chassis dominate, whether limited armour makes melee too fragile, whether power limits punish ranged builds too heavily, and whether static wrecks produce stalemates. The first playable prototype exists to answer these questions, not to conceal them behind elaborate graphics.

The immediate next development task is Milestone A: encode this catalogue and validate builds, then implement a single reproducible match before expanding the fictional league.


## Revision record

v0.1.1 — 31 October 2026: retired the Forge League / ForgeLeague name and adopted Robot Combat League solely as a temporary descriptive project label. Game rules and component specifications are unchanged.


v0.1.2 — 31 October 2026: adopted Torqestra World League (TWL) as the chosen league name and Torqestra as the sport/game name. Forge League / ForgeLeague remain retired. No game rules or component specifications changed.