Kit builder and melee — prototype brief

Recorded from the owner interview on 2026-09-08.

This is the current design direction for the next prototype. It supersedes conflicting earlier design decisions for assembly and melee. The interview below records the design decisions. The first implementation now follows this brief; implementation notes distinguish selected defaults from owner decisions. Recommendations and tentative tuning values are identified below. The prototype inventory and site concept describes the reviewed implementation and the unified site proposal. Work tracking stays in .liste/.

Kit builder

Kit builder: start with a boxed kit. Choose the core, which identifies the box set. Core selection presents named box sets with their own silhouettes and stats, including multiple choices within a weight class; the owner explicitly likes the box presentation. Subsequent choices should work as upgrade sprues, with options for parts on a runner. Sprues are a visual presentation, not a committed package of parts. Assembly is at the level of major components such as legs, arms, and head; it should be more abstract than assembling a real model box. Left and right arms are independent choices. The player clicks a component area and can build in any order. This supersedes the assumption that the primary flow is to select a completed preset and edit seven dropdowns.

After core selection, show the core with empty component outlines to fill. Choose the pilot alongside the parts. The pilot can later be changed while arranging the roster. Do not introduce physical inventory accounting from the sprue metaphor.

For each component, the player can browse different manufacturers and their part options. The owner explicitly includes weapons in this browsing pattern. Manufacturer selection belongs within component browsing; sprues remain a visual organization rather than a required package purchase.

Arms and weapons are separate choices. This is an explicit change in direction from current rule B2 and the combined arm/weapon catalog. Left and right arms remain independently selected structural components; weapons need their own equipment choices. Do not represent this as only a visual reskin of the current arm selector.

Weapons are held in hands. Some weapons are two-handed and occupy both arms' weapon slots. A two-handed weapon is one equipped item reserving both slots, not two copies of an item. Arms have their own stats and associated weights to balance equipment choices. Exact arm stats and compatibility formulas have not been selected. The builder should make occupied hands and resulting equipment restrictions legible; the exact visual treatment remains a proposal.

All assembly and equipment limits are hard. No overload. This supersedes B4's current allowance of ten excess Weight with Speed/Evasion penalties. A completed build must satisfy its applicable weight, capacity, and equipment requirements. Exact requirements and any arm strength formulas remain to be designed. This answer concerns assembly/equipment limits; it does not establish a change to combat heat and stress rules.

A two-handed weapon remains usable when one arm is disabled, with penalties. This is an explicit combat damage exception, not permission to equip an illegal build. The penalty's form and magnitude are undecided. Do not automatically remove the weapon when either arm is disabled.

Weapons are not targetable; arms are. Weapons do not add independent hit locations to the part table. Separate weapon selection in the builder does not imply a separate damage target in combat. Arm condition governs weapon use, including the stated two-handed penalty after one arm is disabled. Do not add weapon hit bands or a separately targetable weapon-durability system.

Still to establish: which baseline properties the chosen core fixes; the arm stats and equipment requirements, including how two arms contribute to a two-handed weapon; the penalty for operating a two-handed weapon with one disabled arm; how the finished mech is saved into the roster. Do not infer a new integrated-arm weapon system from the previous catalog: the stated direction is hand-held weapons. The first prototype can reuse existing data where compatible, but splitting arms and weapons requires an explicit data mapping before it can drive the current combat engine.

Current kit presets and named cores are not interchangeable data concepts: Foreman, Reaver, and Lantern currently share the Medium chassis, so distinct box identities must not silently imply that distinct core stats have already been authored.

The agreed interaction structure is: choose a named core box, see empty component outlines, click any component area, browse manufacturers and their visual runners, and select a component; repeat or revisit areas in any order. Arms and weapons have separate choices. Choose a pilot in the same builder and allow reassignment in the roster. Central preview, hover comparison, and an attach animation remain presentation proposals rather than confirmed requirements.

Melee

Melee: an interactive back-and-forth process, with Kill Team melee as the owner's reference. Mech stats must affect the exchange. A heavy mech should be disadvantaged relative to a lighter mech specialized for melee. Light specialists are intended to have more attack/parry opportunities and be harder to hit. The initial preference for light specialists also acting first was refined to pilot-skill-only order, as recorded below. Heavy attacks should remain dangerous. Attacks and parries probably spend the same pool of opportunities; this preference remains tentative. A powerful heavy strike may require two opportunities to parry for balance. Treat that cost as a candidate to test, not a universal heavy-class rule or a settled value.

Roll both melee pools upfront, with the results visible, then choose how to spend them. The owner selected this over rolling anew as each attack happens. This settles the timing and visibility of opportunity generation, not the die type, success thresholds, or timing of penetration and damage rolls. Melee location is selected under the decision below.

First strike is determined by Piloting, with no roll-off. Ties go to the initiator. The owner explicitly selected the existing Piloting stat and accepted the initiating mech winning a skill tie. The higher-Piloting pilot acts first; mech class, weight, or agility must not independently override that ordering. A skilled heavy pilot can therefore act before a less-skilled light pilot. This changes melee exchange order, not the separate round-initiative rule. No separate Melee skill is introduced by this decision.

Choose the body part when declaring a melee strike, before the defender chooses whether to parry. Ordinary melee strikes select a body location without the current size-weighted location roll or rerolls. No extra-opportunity targeting surcharge is established. Weapons remain untargetable. This direction applies to melee; no change to ranged hit locations has been established.

Every body location, including the Core, is available for a melee strike. The owner adopted the initial approach of using part armor, durability, and the value of disabling limbs to make target selection meaningful. No opening prerequisite or additional Core-access restriction is established. Test whether limb disabling competes with direct Core attacks before proposing such restrictions.

Parry in response to a declared strike. The owner chose reactive defense after the attacker declares a strike and its target, rather than spending one's turn to remove an opponent's unspent attack opportunity. The defender knows which part is threatened before choosing whether to spend from the shared pool. The exact turn sequence must support this response window and charge defense to the same finite resource used for attacks.

Defending in a melee exchange does not consume the attacked mech's normal activation. The owner explicitly rejected counting participation as taking that mech's turn. Preserve its normal activation availability.

Initiating melee costs a Full action. The owner accepted committing the initiator's action budget to the exchange while retaining its normal movement allowance. The exchange can include both equipped melee weapons. Do not implement the new exchange as a Quick Fire or allow two exchanges by spending two Quick actions. Charge's relationship to the new exchange and the status of the old improvised Strike action remain to be defined.

Every new melee action starts a fresh exchange with fresh pools for both mechs. The owner selected fresh pools even when multiple enemies attack the same defender in separate exchanges during one round. Spent opportunities do not carry over between exchanges; no pool-depletion or fatigue rule is established. Fresh pools must use the mech's current state, including damaged arms and available equipment. Defender participation in multiple exchanges per round must be supported; the existing one-Reaction-per-round rule must not silently block the second melee exchange. This does not redefine the game's other reaction types.

Continue spending attacks after the opposing pool is exhausted. The owner accepted that a mech with remaining opportunities can keep striking while its exhausted opponent cannot parry. One pool reaching zero does not end the exchange. This makes defensive spending and conserving opportunities consequential. An exchange can finish when both pools are exhausted; destruction and other interruption rules must also be respected when the final resolution sequence is specified.

Dual-wielding melee should be a legitimate style. In response to the question about using two melee weapons within one exchange versus committing to one, the owner selected legitimate dual-wielding. Support both weapons in the exchange and judge the style's viability against two-handed weapons, rather than merely allowing two items to be equipped. Exact pool contributions and attack sequencing remain undecided.

Shields are held equipment occupying one hand's weapon slot. The owner accepted weapon-and-shield as a third style, giving up a second weapon for stronger defense. This replaces the current combined Shield arm as the intended assembly model. The specific benefit—such as parry efficiency, defensive opportunities, or passive protection—is not yet selected. Do not treat any proposed numerical shield effect as approved.

Mechs without dedicated melee weapons use improvised strikes; guns do not fire within the melee exchange. The owner accepted the cannon-and-shield example using shield parries and improvised attacks such as punches, kicks, or weapon bashes. Dedicated melee equipment should provide an advantage over improvised attacks. The mech retains its normal activation for shooting. Exact improvised profiles and their equipment/limb requirements remain to be specified; this decision does not preserve the old standalone Quick Strike action automatically.

Proposed representation, not yet approved: associate attack opportunities with the weapon that generated them. A shared spending resource should not automatically let a fast weapon generate extra strikes for a second, harder-hitting weapon. This also makes the effect of losing a particular arm easier to explain. Defense spending, shields, and mid-exchange damage still need explicit rules.

Still to establish: which stats control opportunity count and evasion; how pilot skill and weapon choice contribute to the pool; the dice and thresholds that generate opportunities; how both equipped weapons contribute to the pool; improvised attack profiles; the complete turn sequence and effects of damage during an exchange; how Charge and the old Quick Strike fit the Full-action exchange; how parries interact with attack strength; the shield's defensive effects; what the heavy receives in durability or impact; interruptions other than pool exhaustion. Test light specialists' resource and evasion advantages together, alongside pilot ordering, so a heavy has useful defensive or counterattack decisions even when disfavored. The prior concern about a light preemptively cancelling every heavy opportunity must be reassessed under the now-selected response timing; resource advantage can still make defense too reliable, but that is a different sequence. The old TASK-031 proposal is not adopted automatically. This review does not verify the external game's rules or propose copying them verbatim.

First prototype review

The builder should let a reviewer choose a named core box, fill empty body outlines in any order, browse manufacturers for each component, equip independent arms and held weapons, and choose a pilot. Two-handed equipment reserves both hand slots. A shield reserves one. Invalid or incomplete equipment must be visible, and only a build satisfying all hard requirements can be completed. Pilot reassignment remains available in roster arrangement.

A melee demonstration should show both upfront pools, the Piloting order and tie-break, the declared target part, the defender’s parry decision, and the remaining opportunities. It should allow review of dual-wielding, a two-handed weapon, and weapon-and-shield. It should demonstrate a depleted defender taking remaining attacks, fresh pools in a subsequent exchange, and a two-handed weapon continuing with a penalty after one arm is disabled.

Use explicit example values until pool generation, arm requirements, shield benefits, and impairment penalties have been specified. Distinguish a demonstration of the interaction from evidence of balance. Measure whether direct Core attacks crowd out limb targeting and whether light specialists remain vulnerable enough for heavy attacks to matter.