Game Engine Rules (AI Training)

[Kindwind]

I decided to try some Claude code. Trying to make sure I have all the rules for the map Triplea revised. I am trying to get a better ai for the community on the map revised. I have like 1000 games trained but the rules were wrong. I just need another pair of eyes on my rules to make sure they are 100% right. # Colossus Rules Implementation Audit. If you have coded before would you mind looking at this to map sure this is right?

Updated: # Colossus Rules Implementation Audit

This document provides a comprehensive audit of all game rules implemented in the Colossus Axis & Allies engine.

Legend:

• Verified - Rule implemented correctly with test coverage
• ️ Untested - Rule implemented but lacks dedicated tests
• Bug - Known issue with implementation

---

1. Unit Properties

File: unit.rs

Unit	Cost	Attack	Defense	Movement	Notes	Status
Infantry	3	1	2	1	Transport cost: 2	Verified
Artillery	4	2	2	1	Transport cost: 3, supports infantry	Verified
Armour	5	3	3	2	Transport cost: 3, can blitz	Verified
AA Gun	5	0	0	1	Transport cost: 3, special AA fire	Verified
Fighter	10	3	4	4	Carrier cost: 1, +2 with Long Range	Verified
Bomber	15	4	1	6	SBR capable, +2 with Long Range	Verified
Submarine	8	2	2	2	First strike, submerge	Verified
Destroyer	12	3	3	2	Negates sub abilities	Verified
Transport	8	0	1*	2	Capacity: 5 points	Verified
Carrier	16	1	3	2	Holds 2 fighters	Verified
Battleship	24	4	4	2	2 hit points, shore bombard	Verified
Factory	15	0	0	0	Production building	Verified

*Transport defense is configurable (0 or 1 via config.transport_defense)

Transport Capacity (Point-Based)

Files: unit.rs:98-99, generation_fixed.rs

Unit	Transport Cost
Infantry	2 points
Artillery	3 points
Armour	3 points
AA Gun	3 points

Total transport capacity: 5 points

Valid loadouts:

• 2 Infantry (4 points)
• 1 Infantry + 1 Artillery/Armour/AA (5 points)
• 1 Artillery/Armour/AA only (3 points)

Test Coverage: unit.rs:182-198 Verified

---

2. Turn Sequence

File: phase.rs

Turn Order

Phase	Description	Status
1. Tech	Purchase technology dice (5 IPCs each)	Verified
2. TechActivation	Roll tech dice, gain technology	Verified
3. Purchase	Buy units (placed at end of turn)	Verified
4. CombatMove	Move units to attack	Verified
5. Battle	Resolve all combat	Verified
6. NonCombatMove	Move remaining units	Verified
7. Place	Place purchased units	Verified
8. EndTurn	Collect income, repair units	Verified

Player Order

1. Russians → 2. Germans → 3. British → 4. Japanese → 5. Americans

File: phase.rs:15-28 Verified

Bid Phases (Pre-Game)

Phase	Description
RussiansBid	Place Russian bid units
GermansBid	Place German bid units
BritishBid	Place British bid units
JapaneseBid	Place Japanese bid units
AmericansBid	Place American bid units

File: phase.rs, game_options.rs:184-204 Verified

---

3. Movement Rules

3.1 Combat Move Phase

File: generation_fixed.rs

Rule	Implementation	Status
Land units can attack adjacent territories	gen_combat_moves	Verified
Ships can attack adjacent sea zones	gen_combat_moves	Verified
Aircraft can attack within movement range	gen_combat_moves	Verified
AA guns CANNOT move during combat	if unit_type == UnitType::AaGun { continue; }	Verified
AA guns CANNOT load on transports during combat	gen_transport_loads_combat_dedup	Verified
Transports can load infantry/artillery/armour	gen_transport_loads_combat_dedup	Verified
Amphibious assaults from transports	gen_amphibious_assaults	Verified
Bombers CAN attack sea zones	Must have valid landing spot for return	Verified

Test Coverage: generation_fixed.rs:745-923 Verified

3.2 Non-Combat Move Phase

File: generation_fixed.rs

Rule	Implementation	Status
Units move to friendly territories	gen_noncombat_moves	Verified
AA guns CAN move during NCM	gen_noncombat_moves	Verified
AA guns CAN load on transports	gen_transport_loads_dedup	Verified
Aircraft must land with valid capacity	validation/aircraft.rs	Verified
Transports can unload cargo	gen_transport_unloads	Verified
Bombers CANNOT land in sea zones	if unit_type == UnitType::Bomber && to_terr.is_water { continue; }	Verified

Test Coverage: generation_fixed.rs:871-923 Verified

3.3 Blitzing

File: validation/movement.rs:130-153

Rule	Description	Status
Only armour can blitz	Movement 2 required	Verified
Must pass through EMPTY enemy territory	No enemy units present	Verified
Cannot blitz through defended territory	can_blitz function	Verified
Territory captured during blitz	Ownership changes	Verified
AA guns block blitzing	can_blitz check	Verified

Test Coverage: movement.rs:295-433 Verified

3.4 Canal Restrictions

File: generation_fixed.rs:611-634

Canal	Required Territories	Status
Suez Canal	Egypt	Verified
Panama Canal	Panama, Central America	Verified

Ships cannot pass through canals unless controlling player owns required territories.

Implementation: can_pass_canal function Verified

3.5 Aircraft Landing

File: validation/aircraft.rs

Rule	Description	Status
Fighters land on friendly territory	can_land function	Verified
Fighters land on carriers	has_carrier_capacity	Verified
Carrier capacity: 2 fighters	Per carrier	Verified
Bombers land on friendly territory only	Cannot use carriers	Verified
Must have movement remaining	remaining_movement	Verified
Long Range Air: +2 movement	Technology bonus	Verified

Test Coverage: aircraft.rs:163-217 Verified

3.6 Movement Tracking

Files: fixed.rs, apply.rs, undo.rs, generation_fixed.rs

Rule	Description	Status
Units move once per phase	units_moved_count tracking array	Verified
Walk-then-load blocked (Combat Move)	Load tracks unit at source territory	Verified
Unload-then-walk blocked (both phases)	Unload tracks unit at destination	Verified
NCM bridging allowed	Load NOT tracked in Non-Combat Move	Verified
MCTS apply/unapply works	unrecord_units_moved() restores state	Verified
Phase transition clears tracking	clear_movement_tracking() on phase change	Verified

Implementation:

• units_moved_count[player][territory][unit_type] - Tracks how many units moved FROM each territory
• remaining_movement[player][territory][unit_type] - For multi-space movers (future use)
• record_units_moved() - Called in apply_unit_move(), apply_load() (CM only), apply_unload()
• unrecord_units_moved() - Called in unapply_move() for MCTS backtracking
• units_available_to_move() - Returns present count minus already moved count
• clear_movement_tracking() - Called when leaving CombatMove or NonCombatMove phase

Movement Tracking Matrix:

Function	Combat Move	Non-Combat Move	Track Location	Reason
apply_unit_move()	Track	Track	DESTINATION	Unit can't move again after arriving
apply_load()	Track	No track	SOURCE	CM: prevents walk-then-load; NCM: allows bridging
apply_unload()	Track	Track	DESTINATION	Unit can't move after unloading

Note: Tracking at destination for apply_unit_move() is correct because the unit is physically removed from the source territory. Tracking the arriving unit at its destination prevents it from moving further.

State Size Impact: Increased from 16KB to 32KB to accommodate tracking arrays.

Test Coverage: battle_test.rs Verified

---

4. Combat Rules

4.1 Battle Resolution

File: combat/resolve.rs

Phase	Description	Status
1. AA Fire	AA guns fire at attacking aircraft	Verified
2. Submarine First Strike	Subs attack before regular combat	Verified
3. Regular Combat	Alternating fire rounds	Verified
4. Retreat	Attacker may retreat	Verified

4.1.1 Territory Capture

File: combat/resolve.rs

Rule	Description	Status
Territory ownership transfers	Winner takes control	Verified
AA guns are CAPTURED, not destroyed	capture_aa_guns() transfers ownership	Verified
AA guns do not participate in combat	Non-combatant, defense = 0	Verified
AA guns not selected as casualties	Excluded from casualty selection	Verified
Allied AA guns NOT captured	Only enemy AA guns transfer	Verified

Implementation:

• capture_aa_guns() called when attacker wins battle
• Iterates through all enemy players (skips self and allies)
• Transfers AA gun ownership from old owner to new owner
• Updates unit counts and territory masks
• Called after bombardment victory AND after regular combat victory

Test Coverage: test_aa_gun_captured_when_territory_falls, test_aa_gun_not_in_casualty_list, test_multiple_aa_guns_all_captured Verified

4.1.2 Shore Bombardment

Files: battle.rs, resolve.rs, bombardment.rs

Rule	Description	Status
Battleships bombard in amphibious assaults	Fire BEFORE AA fire	Verified
One shot per battleship	Attack value 4	Verified
Only from adjacent sea zones	Must have transport AND battleship	Verified
Casualties applied before combat	Hits remove defenders immediately	Verified
Not in land-only attacks	Only amphibious assaults	Verified
Low Luck bombardment	4/6 = 0.66 guaranteed hits per battleship	Verified

Implementation:

• get_amphibious_info() - Detects amphibious assault by checking for transports in adjacent sea zones
• resolve_bombardment_multi() - Fires all battleships from identified sea zones
• Called at start of resolve_battle() before AA fire
• Can end battle early if bombardment kills all defenders

Test Coverage: battle_test.rs Verified

4.2 AA Fire

File: combat/resolve.rs, combat/dice.rs:29-37

Rule	Description	Status
Hits on 1	1/6 chance per aircraft	Verified
One shot per aircraft	Max hits = aircraft count	Verified
Low Luck AA	Guaranteed hits for 6+ aircraft	Verified
Choose casualties (optional)	config.choose_aa_casualties	Verified
Always-on AA (flyover)	config.always_on_aa	Verified

Test Coverage: resolve.rs:665-681, apply.rs:822-980 Verified

4.3 Submarine Combat

File: combat/resolve.rs

Rule	Description	Status
First strike	Submarines fire first	Verified
Casualties don't return fire	Unless destroyer present	Verified
Destroyer negates first strike	has_destroyer check	Verified
Submerge option	config.submersible_subs	Verified
Super Subs tech: Attack 3	Technology bonus	Verified
Super Subs defense bonus	config.super_sub_defense_bonus	Verified
Defending subs fire back	config.defending_subs_fire_back	Verified
Air cannot hit subs without destroyer	air_can_hit_subs() check	Verified
Subs cannot hit aircraft	get_sub_targetable_units() excludes aircraft	Verified
Air vs Sub stalemate	Battle ends if only air vs only subs	Verified

Implementation (Fixed 2026-01):

• air_can_hit_subs() - Returns true only if attacker has destroyer in territory
• get_air_targetable_units() - Filters subs from targets when no destroyer present
• get_sub_targetable_units() - Excludes fighters and bombers from sub targets
• is_air_sub_stalemate() - Detects deadlock when only air vs only subs
• Stalemate check runs BEFORE each combat round
• If stalemate detected, battle ends with no winner

Test Coverage: test_air_cannot_hit_subs_without_destroyer, test_air_can_hit_subs_with_destroyer, test_sub_hits_cannot_kill_aircraft, test_is_air_sub_stalemate_detection Verified

4.4 Artillery Support

File: combat/resolve.rs

Rule	Description	Status
1:1 support ratio	Each artillery supports 1 infantry	Verified
Supported infantry attack at 2	Instead of 1	Verified

Test Coverage: resolve.rs:613-621 Verified

4.5 Two-Hit Battleships

File: combat/resolve.rs

Rule	Description	Status
Battleships take 2 hits	config.two_hit_battleship	Verified
Damaged state tracked	state.damaged_battleships	Verified
Repair at end of turn	config.units_repair_hits_end_turn	Verified
Repair at start of turn	config.units_repair_hits_start_turn	Verified

Test Coverage: resolve.rs:684-709 Verified

4.6 Transport Defense

File: combat/resolve.rs

Setting	Behavior	Status
transport_defense = 0	Defenseless transports	Verified
transport_defense = 1	Transports defend at 1	Verified
Combat unit check	Transports count as combat when defending	Verified

Test Coverage: resolve.rs:711-784 Verified

---

5. Strategic Bombing

File: combat/bombing.rs

Rule	Description	Status
Bombers attack factories	resolve_bombing_raid	Verified
AA fires at bombers	Before damage	Verified
Damage = 1d6 per bomber	Standard	Verified
Heavy Bombers: 2d6	With technology	Verified
LHTR Heavy: Best of 2d6	config.lhtr_heavy_bombers	Verified
Low Luck: 4 IPC per bomber	config.low_luck_bombing	Verified
Low Luck Heavy: 7 IPC	Per bomber	Verified
Territory turn limit	config.territory_turn_limit	Verified
Factory damage tracked	state.factory_damage	Verified
Repair costs 1 IPC per point	repair_factory	Verified

Test Coverage: bombing.rs:152-260 Verified

---

6. Economic Rules

6.1 Income Collection

File: game/income.rs

Rule	Description	Status
Income = sum of controlled territory production	calculate_income	Verified
No income if capital captured	state.capital_captured check	Verified
Income collected at end of turn	collect_income	Verified

Test Coverage: income.rs:54-77 Verified

6.2 Capital Capture

File: game/capital.rs

Rule	Description	Status
Captor steals all IPCs	handle_capital_capture	Verified
Victim loses income ability	capital_captured flag	Verified
Liberation restores income	check_capital_liberation	Verified
IPCs not returned on liberation	Intended behavior	Verified

Test Coverage: capital.rs:101-144 Verified

6.3 Unit Purchase

Files: generation_fixed.rs, action_space.rs

Rule	Description	Status
Purchase during Purchase phase	Phase check	Verified
Units placed during Place phase	Deferred placement	Verified
Factory required for placement	Factory presence check	Verified
Cannot use enemy factory	Ownership check	Verified
Sea units placed in adjacent sea zone	Naval placement	Verified
Factory damage reduces production	effective_production	Verified

Test Coverage: generation_fixed.rs:996-1124 Verified

---

7. Victory Conditions

File: game/victory.rs

Victory Type	Cities Needed	Status
Projection of Power	9 VCs	Verified
Honorable Surrender	10 VCs	Verified
Total Victory	12 VCs	Verified

Implementation:

• check_victory - Main victory check
• count_victory_cities - Count per alliance
• check_capitals - Alternative capital-based victory

Test Coverage: victory.rs:106-126 Verified

---

8. Technology System

File: types/phase.rs, combat/dice.rs

Available Technologies

Technology	Effect	Status
Jet Power	Fighters attack/defend +1	Verified
Rockets	AA guns can SBR	Verified
Super Subs	Submarines attack at 3	Verified
Long Range Air	Aircraft +2 movement	Verified
Industrial Tech	Units cost 1 less	Verified
Heavy Bombers	2d6 bombing damage	Verified

Test Coverage: resolve.rs:814-1056 Verified (All technologies)

Tech Research

Rule	Description	Status
Cost: 5 IPCs per die	config.tech_cost_per_die	Verified
Success on 6	roll_tech	Verified
Low Luck: N dice = N/6 chance	Guaranteed at 6 dice	Verified

Test Coverage: dice.rs:129-140 Verified

---

9. Low Luck System

File: combat/dice.rs

Type	Formula	Status
Combat	hits = floor(power/6) + roll for remainder	Verified
AA Fire	hits = floor(aircraft/6) + roll	Verified
Tech	6 dice = guaranteed, else roll ≤ N	Verified
Bombing	4 IPC per normal, 7 per heavy	Verified

Configuration:

• config.low_luck - Combat
• config.low_luck_aa - AA fire
• config.low_luck_tech - Technology
• config.low_luck_bombing - Strategic bombing

Test Coverage: dice.rs:91-162 Verified

---

10. Configuration Options

File: config/game_options.rs

Combat Options

Option	Default (TRAINING)	Status
low_luck	true	Verified
low_luck_aa	true	Verified
low_luck_tech	true	Verified
low_luck_bombing	true	Verified
always_on_aa	true	Verified
roll_aa_individually	true	Verified
choose_aa_casualties	true	Verified
kamikaze_airplanes	false	Verified
territory_turn_limit	true	Verified

Technology Options

Option	Default (TRAINING)	Status
technology_enabled	false	Verified
tech_cost_per_die	5	Verified
lhtr_heavy_bombers	true	Verified
heavy_bomber_dice_rolls	2	Verified
super_sub_defense_bonus	0	Verified

Unit Options

Option	Default (TRAINING)	Status
two_hit_battleship	true	Verified
units_repair_hits_end_turn	true	Verified
units_repair_hits_start_turn	false	Verified
submersible_subs	true	Verified
defending_subs_fire_back	true	Verified
transport_defense	1	Verified
produce_fighters_on_carriers	true	Verified
move_existing_fighters_to_new_carriers	true	Verified
lhtr_carrier_production	false	Verified
allied_air_dependents	true	Verified

Movement Options

Option	Default (TRAINING)	Status
neutrals_are_impassable	true	Verified
neutrals_are_blitzable	false	Verified
sub_control_sea_zone_restricted	false	Verified

Victory Options

Option	Default (TRAINING)	Status
victory_type	TotalVictory (12 VCs)	Verified

Test Coverage: game_options.rs:544-848 Verified

---

11. Presets

File: config/game_options.rs

Preset	Description	Key Differences
TRAINING	Your preferred settings	Low Luck ON, 12 VCs, German bid 9
TOURNAMENT	Competitive play	Low Luck ON, 9 VCs, no bids
CASUAL	Standard dice	Low Luck OFF, 9 VCs
TRIPLEA_DEFAULT	Matches TripleA	Low Luck OFF, no LHTR

---

Summary Statistics

Category	Verified	Untested	Bugs	Total
Unit Properties	12	0	0	12
Turn Sequence	8	0	0	8
Movement Rules	21	0	0	21
Combat Rules	27	0	0	27
Economic Rules	9	0	0	9
Victory	3	0	0	3
Technology	7	0	0	7
Configuration	29	0	0	29
TOTAL	116	0	0	116

Coverage: 100% verified, 0% untested, 0% bugs

---

Known Fixed Issues

AA Gun Transport Rules (Fixed 2024-12)

Files Modified: generation_fixed.rs

Bug	Fix
AA guns could load during Combat Move	Created gen_transport_loads_combat_dedup excluding AA guns
Transport loading not generated during NCM	Added gen_transport_loads_dedup to gen_noncombat_moves

Test Cases Added:

1. test_aa_gun_cannot_load_during_combat_move
2. test_aa_gun_can_load_during_noncombat_move
3. test_infantry_can_load_during_combat_move
4. test_artillery_can_load_during_combat_move
5. test_aa_gun_can_unload_during_noncombat_move
6. test_aa_gun_can_amphibious_assault

Test Coverage Expansion (2026-01)

Added comprehensive tests for previously untested rules:

Combat Rules (submarines.rs, resolve.rs

• test_subs_can_submerge_no_destroyer
• test_subs_cannot_submerge_with_enemy_destroyer
• test_sub_attack_power_normal
• test_sub_attack_power_super_subs
• test_first_strike_checks_correct_enemy
• test_resolve_battle_with_defending_subs_fire_back
• test_resolve_battle_without_defending_subs_fire_back
• test_submersible_subs_first_strike_enabled

Technology Effects (resolve.rs

• test_jet_power_increases_fighter_attack
• test_jet_power_increases_fighter_defense
• test_jet_power_only_affects_fighters
• test_super_subs_increases_attack

Movement/Blitz (movement.rs

• test_blitz_through_empty_enemy_territory
• test_blitz_blocked_by_any_enemy_unit
• test_blitz_blocked_by_aa_gun
• test_blitz_tracker_records_correctly
• test_only_armour_can_blitz_movement_check
• test_blitz_path_length_validation

Factory Placement (generation_fixed.rs):

• test_placement_requires_factory
• test_placement_with_factory
• test_sea_unit_placement_requires_adjacent_sea_zone
• test_cannot_place_in_enemy_factory

Technologies - Rockets & Industrial Tech (resolve.rs

• test_rockets_tech_defined
• test_rockets_tech_can_be_granted
• test_rockets_allows_aa_sbr
• test_industrial_tech_defined
• test_industrial_tech_can_be_granted
• test_industrial_tech_reduces_unit_cost
• test_industrial_tech_all_unit_types

Config Options (game_options.rs):

• test_kamikaze_airplanes_default_training
• test_kamikaze_airplanes_default_tournament
• test_kamikaze_airplanes_can_be_enabled
• test_produce_fighters_on_carriers_enabled
• test_produce_fighters_on_carriers_all_presets
• test_move_existing_fighters_to_new_carriers_enabled
• test_move_existing_fighters_to_new_carriers_all_presets
• test_lhtr_carrier_production_disabled_by_default
• test_lhtr_carrier_production_all_presets
• test_lhtr_carrier_production_can_be_enabled
• test_allied_air_dependents_enabled
• test_allied_air_dependents_all_presets
• test_allied_air_dependents_can_be_disabled
• test_neutrals_are_blitzable_disabled_by_default
• test_neutrals_are_blitzable_all_presets
• test_neutrals_are_blitzable_can_be_enabled
• test_neutrals_impassable_takes_precedence
• test_sub_control_sea_zone_restricted_disabled_by_default
• test_sub_control_sea_zone_restricted_all_presets
• test_sub_control_sea_zone_restricted_can_be_enabled
• test_sub_control_affects_transport_passage

---

Last updated: 2026-01

Movement Rules Overhaul (Fixed 2026-01)

Files Modified:

• generation_fixed.rs
• fixed.rs
• apply.rs
• undo.rs
• resolve.rs

Bug	Description	Fix
AA guns could move in Combat Move	AA guns have movement=1, weren't excluded	Added if unit_type == UnitType::AaGun { continue; } in gen_combat_moves()
Bombers could land in sea zones (NCM)	No explicit check for bomber sea landing	Added if unit_type == UnitType::Bomber && to_terr.is_water { continue; } in gen_noncombat_moves()
AA guns destroyed on capture	AA guns vanished when territory fell	Added capture_aa_guns() to transfer ownership to attacker
Movement tracking not used	Units could move unlimited times	Added units_moved_count tracking - see Section 3.6

Note: Bombers CAN move to sea zones during Combat Move (to attack ships). The fix only prevents landing in sea zones during Non-Combat Move.

Test Cases Added:

• test_aa_gun_cannot_move_during_combat_move
• test_aa_gun_can_move_during_noncombat
• test_bomber_cannot_move_to_sea_zone_ncm
• test_aa_gun_captured_when_territory_falls
• test_aa_gun_not_in_casualty_list
• test_multiple_aa_guns_all_captured

Impact: These bugs meant the AI was learning invalid strategies during training. Training should be restarted from scratch after these fixes.

Shore Bombardment Implementation (Added 2026-01)

Files Modified:

• battle.rs - Added get_amphibious_info() helper
• resolve.rs - Added bombardment logic before AA fire
• bombardment.rs - resolve_bombardment_multi() function

Feature	Description
Detection	get_amphibious_info() checks for transports in adjacent sea zones
Firing	Battleships fire at attack value 4 (Low Luck: 4/6 = 0.66 hits each)
Timing	Fires BEFORE AA fire, casualties applied immediately
Multi-zone	Supports battleships from multiple adjacent sea zones
Early victory	Can end battle if bombardment kills all defenders

Rule Details:

• Only battleships can bombard (WW2v2 has no cruisers)
• One bombardment shot per battleship per battle
• Bombardment only happens in amphibious assaults (requires transport unloading)
• Defender selects casualties from bombardment hits

Test Cases (tests/battle_test.rs):

• test_bombardment_in_amphibious_assault - Bombardment fires during amphibious assault
• test_no_bombardment_without_amphibious - No bombardment for land-only attacks
• test_multiple_battleships_bombard - Multiple battleships all fire
• test_bombardment_before_aa_fire - Bombardment happens before AA fire in battle sequence

Movement Tracking Implementation (Added 2026-01)

Files Modified:

• fixed.rs - Added units_moved_count and remaining_movement arrays
• apply.rs - Track in apply functions, untrack in unapply
• undo.rs - Added movement tracking fields to UndoInfo
• generation_fixed.rs - Use units_available_to_move() for move generation

Issue	Description	Fix
Units could move multiple times	No tracking of which units moved	Added units_moved_count array
Walk-then-load exploit	Infantry walk to coast, then load same turn	Track load at source (Combat Move only)
Unload-then-walk exploit	Tank unload from transport, then walk inland	Track unload at destination (both phases)
MCTS state corruption	Movement not restored on unapply	Added unrecord_units_moved() in unapply
NCM bridging broken	Bridging requires load→sail→unload in one phase	Don't track load in Non-Combat Move

State Size Impact: Increased from 16KB to 32KB to accommodate tracking arrays.

MCTS Compatibility:

• apply_move() records movement in UndoInfo
• unapply_move() calls unrecord_units_moved() to restore state
• Phase transitions call clear_movement_tracking() to reset arrays

Test Cases (tests/battle_test.rs):

• test_movement_tracking_basic - Basic record_units_moved functionality
• test_unit_move_tracks_movement - Unit moves are tracked at destination
• test_mcts_apply_unapply_preserves_movement - MCTS cycle restores movement state
• test_phase_transition_clears_tracking - Tracking cleared on phase change
• test_clear_movement_tracking_directly - Direct clear function works
• test_moved_units_not_in_move_generation - Moved units excluded from legal moves
• test_unload_tracks_at_destination - Unloaded units tracked at destination
• test_full_combat_round_with_tracking - Full battle with tracking
• test_aa_gun_cannot_combat_move - AA guns excluded from Combat Move
• test_aa_gun_can_noncombat_move - AA guns can move in Non-Combat Move
• test_bomber_cannot_land_in_sea_zone_ncm - Bombers can't land in sea zones

Production Limit Implementation (Fixed 2026-01)

Files Modified:

• fixed.rs - Added units_placed_count array and helper methods
• apply.rs - Track placements in apply_place(), untrack in unapply_move()
• undo.rs - Added placement_territory and placement_count to UndoInfo
• generation_fixed.rs - Use remaining_production_capacity() in gen_placements()

Rule	Description	Status
Production = territory IPC	Max units placeable = territory production value	Verified
Factory damage reduces capacity	Effective limit = production - damage	Verified
Tracking per territory	units_placed_count[territory] tracks placements	Verified
Reset at end of turn	clear_placement_tracking() on phase transition	Verified

Implementation:

• remaining_production_capacity(territory, production) - Returns available capacity
• record_units_placed(territory, count) - Increments placement count
• unrecord_units_placed(territory, count) - Decrements for MCTS unapply
• clear_placement_tracking() - Resets all counts (called when leaving Place phase)

Bug Fixed:
Previously, gen_placements() retrieved let _production = map.territory(tid).production; but NEVER USED IT. This allowed unlimited unit placement at any factory, breaking game balance.

Test Cases:

• test_production_limited_by_territory_ipc - Placement capped at territory IPC
• test_production_reduced_by_factory_damage - Damage reduces capacity
• test_no_placement_at_capacity - No placements when at capacity
• test_remaining_production_capacity_helper - Helper function works correctly

Air vs Submarine Rules Implementation (Fixed 2026-01)

Files Modified:

• resolve.rs - Added stalemate detection and target filtering

Rule	Description	Status
Air cannot hit subs without destroyer	air_can_hit_subs() check in combat	Verified
Subs cannot hit aircraft	Sub hits filtered to exclude fighters/bombers	Verified
Stalemate detection	Battle ends if only air vs only subs (no destroyer)	Verified

Implementation:

• has_only_subs() - Checks if player only has submarines remaining
• has_only_air_no_destroyer() - Checks if player has only air and no destroyer
• is_air_sub_stalemate() - Detects when combat cannot continue
• get_air_targetable_units() - Filters subs from air targets when no destroyer
• get_sub_targetable_units() - Excludes aircraft from sub targets

Bug Fixed:
The air_can_hit_subs() function in submarines.rs existed but was NEVER CALLED in combat resolution. This meant aircraft could always hit submarines regardless of destroyer presence.

Test Cases:

• test_air_cannot_hit_subs_without_destroyer - Stalemate when only air vs subs
• test_air_can_hit_subs_with_destroyer - Normal combat with destroyer
• test_sub_hits_cannot_kill_aircraft - Sub hits go to non-aircraft
• test_has_only_subs_helper - Helper function works
• test_has_only_air_no_destroyer_helper - Helper function works
• test_is_air_sub_stalemate_detection - Stalemate detection works
• test_get_air_targetable_units_filters_subs - Target filtering works
• test_get_sub_targetable_units_excludes_aircraft - Aircraft excluded from sub targets

Canal Blocking Tests (Added 2026-01)

Files Modified:

• generation_fixed.rs - Added canal blocking test cases

Rule	Description	Status
Suez Canal blocking	Ships cannot pass Suez if enemy controls Anglo Egypt OR Trans-Jordan	Verified
Panama Canal blocking	Ships cannot pass Panama if enemy controls Panama	Verified
Both territories required	Suez requires control of BOTH Anglo Egypt AND Trans-Jordan	Verified
Allied canal access	Allied ships can use canals controlled by friendly powers	Verified

Implementation:

• can_pass_canal() in generation_fixed.rs already implemented correctly
• Tests added to verify canal blocking works as expected

Test Cases:

• test_suez_canal_blocked_without_control - British ships blocked when Germans control Suez
• test_suez_canal_open_with_control - British ships pass when British control Suez
• test_panama_canal_blocked_without_control - Japanese ships blocked when Allies control Panama
• test_panama_canal_open_with_control - American ships pass when Americans control Panama
• test_suez_requires_both_territories - Suez blocked if only one territory controlled
• test_allied_can_use_friendly_canal - British can use American-controlled Panama

Amphibious Retreat Rules Implementation (Fixed 2026-01)

Files Modified:

• fixed.rs - Added amphibious_assault_territories tracking mask
• apply.rs - Mark amphibious assaults, restrict retreat to aircraft
• undo.rs - Added amphibious_territory and amphibious_territory_marked fields
• generation_fixed.rs - Only generate retreat moves if aircraft present in amphibious battles

Rule	Description	Status
Ground units cannot retreat from amphibious	Infantry, artillery, armour stay and fight to death	Verified
Aircraft can retreat from amphibious	Fighters and bombers can retreat to friendly territory	Verified
Pure amphibious ground has no retreat	If only ground units in amphibious, no retreat moves generated	Verified
Non-amphibious full retreat	All units can retreat from non-amphibious battles	Verified

Implementation:

• amphibious_assault_territories: TerritoryMask - Tracks which territories have amphibious landings
• Set when apply_amphibious() is called during Combat Move phase
• Cleared when leaving Battle phase
• gen_battle_moves() - Only generates retreat if attacker has aircraft in amphibious battles
• apply_retreat() - Only moves aircraft in amphibious battles, ground units stay

Bug Fixed:
Previously, all units could retreat from any battle. In amphibious assaults, ground units that landed from transports are committed to the battle and cannot retreat. Only aircraft (which flew in separately) can retreat.

Test Cases:

• test_amphibious_assault_no_retreat_without_air - No retreat moves when only ground units
• test_amphibious_assault_air_can_retreat - Retreat available when aircraft present
• test_non_amphibious_all_units_can_retreat - All units can retreat in land battles
• test_amphibious_retreat_only_moves_aircraft - Only aircraft move when retreating from amphibious

Submarine Submerge Implementation (Fixed 2026-01)

Files Modified:

• mod.rs - Added MOVE_SUBMERGE constant and Move::submerge() constructor
• fixed.rs - Added submerged_subs tracking array and helper methods
• undo.rs - Added submerge_territory, submerge_player, submerge_count, submerge_occurred fields
• apply.rs - Added apply_submerge() and undo logic
• generation_fixed.rs - Generate submerge option in gen_battle_moves()
• battle.rs - Restore submerged subs after battle ends

Rule	Description	Status
Submerge option available	Subs can submerge if no enemy destroyer present	Verified
Destroyer blocks submerge	Enemy destroyer prevents submerge option	Verified
Submerged subs leave combat	Submerged subs don't participate in remaining rounds	Verified
Submerged subs survive	Submerged subs remain in territory after battle	Verified
Player choice	Player can choose to submerge OR continue (stalemate)	Verified

Implementation:

• submerged_subs: [[u8; MAX_TERRITORIES]; Player::COUNT] - Tracks submerged subs per player per territory
• submerge_subs() - Moves subs from active units to submerged tracking
• restore_submerged_subs() - Restores subs to active units after battle ends
• unsubmerge_subs() - For MCTS unapply
• gen_battle_moves() - Generates submerge option when subs present and no enemy destroyer
• After resolve_battle(), restore_submerged_subs() is called for all players

Bug Fixed:
The subs_can_submerge() function existed but was never used in the game. Submarines couldn't choose to submerge to escape combat. Now the player can choose between:

1. Submerge - Subs escape and remain in territory after battle
2. Pass (continue) - Battle continues (with stalemate detection if only air vs subs)

Test Cases:

• test_submerge_option_available_without_destroyer - Submerge move generated when no destroyer
• test_submerge_option_blocked_by_destroyer - No submerge option when enemy has destroyer
• test_submerge_removes_subs_from_combat - Subs move to submerged tracking
• test_submerged_subs_restored_after_battle - Subs restored to active units post-battle
• test_submerge_vs_stalemate_gives_choice - Player has choice: submerge or continue to stalemate

[TheDog]

@kindwind
Looks impressive!
Is the PU value of a territory taken into account?

The built-in AI targets Capital and Victory Cities (vc), it looks like you cater for those. It also targets factories does the above?

[Kindwind]

@thedog What the neural network CAN SEE (encoded in the 48-channel tensor):
Feature
Channel
How Encoded
Territory PU values
25
Production value normalized (0-1, max 10)
Victory Cities
26
Binary flag
Capitals
28
Binary flag
Factories
30
Binary "has factory" flag
Factory damage
29
Damage level normalized
So the network sees all this information, but here's the philosophical difference from TripleA's built-in AI:
TripleA's AI: Has explicit targeting heuristics ("prioritize capitals → VCs → factories → high-PU territories")
COLOSSUS: Has NO explicit targeting. It must discover through self-play that these things matter based on:
Win condition: Victory City count (9/10/12 VCs) or capital capture
Reward shaping: IPC advantage as a tie-breaker (which reflects total controlled PU)
The theory is that after enough training games, the network should learn:
"Capturing Moscow gives me all their IPCs" → value capitals
"Controlling more VCs wins games" → value VCs
"High-PU territories increase my IPC advantage" → value territory production
"Factories let me place units there" → value factories (implicitly)
The question is: Has training progressed far enough for this learning to emerge? Or does it need explicit reward shaping for intermediate strategic objectives?

So it's an alpha go style. Should work used low luck instead of pure dice.

It may not work out however!

[TheDog]

@kindwind said in Game Engine Rules (AI Training):

Or does it need explicit reward shaping for intermediate strategic objectives?

TripleAs AI needs help to be better, in 1941 Global Command Decision (GCD) there are 82 Capital territories/TT and Sea Zones/SZ. A few Capitals are in the middle of the Pacific. I have used these excess Capitals to tell the AI what is important to the player.

Also SZ have PU values, usually 1, but SZ that are part of a canal have 2PU, so the AI values these more.

So does your AI value what the player values?

[Kindwind]

@thedog For right now I am doing the revised map. I will take on other maps later. Hopefully from my current project I can upgrade to something like a universal game engine for triplea that handles all the maps. That's a lot of work. The project is much simpler. Get an AI like alpha go for revised. Make sure it's right. Then expand. The AI can figure out how I build this and then make me a script for the universal engine from all the tirplea game boards. Remember, I don't code. I am just guy who can think is all. This is all AI and some wits. LOL. This will take months to do.

[RogerCooper]

@kindwind Why don't you try the Minimap scenario? It uses a simplified version of the Revised rules with a small, simple map.

[Kindwind]

@rogercooper had no idea that was a thing. I just started to work with code using AI. I just build everything that I thought I would have needed. My AI uses an alpha go style MCST. That's all I know really.

[RogerCooper]

@kindwind If you want to try a neural net AI for TripleA, you would need to modify TripleA to support repeated self-play. For example of programs that support repeated self-play checkout Ludii & Chess Arena.

Supporting repeated self-play would be project of moderate difficulty in Java. (TripleA already supports self-play). You would need to learn Java (Vibe coding doesn't cut it).. Repeated self-play would also be useful for balancing mods.

I don't know how well a neural net would play TripleA. The number of possible moves in Go is a most 361, far fewer than the number of possible moves in a TripleA game. An effort to get a neural net to play a 2-player Risk variant did not go well.

One advantage is that TripleA already has heuristic AI's that could be used to train a neural net.

[RogerCooper]

@kindwind Any progess on this?

[Kindwind]

@rogercooper Yes, here is where it says I am at currently. I worked out all the engine bugs and things play clean finally. There were a lot of steps that I was not tracking. Here is the new report: Colossus: AI for Axis & Allies — Project Status
What we're building: A neural network + Monte Carlo Tree Search (MCTS) AI for the board game Axis & Allies (1942 2nd Edition), using the same approach as DeepMind's AlphaZero.

Architecture:

Rust game engine (fast simulation, ~50ms/game) with Python bindings
Graph Neural Network (GNN) that understands the map topology — 574K parameters
MCTS search that uses the neural network to evaluate positions (50 simulations/move)
143-territory map, 166K possible actions, 5 players (2 teams)
Phase 1 — Supervised Learning (Complete):

Trained on 5,000 games from a hand-coded "ProAI" opponent
17.97 million training samples, ~2 hours on a single RTX 5070 Ti
Network learned basic strategy: as Axis, wins 100% vs ProAI with search
Known weakness: plays Allies poorly (learned Axis-biased strategy from training data)
Phase 2 — Self-Play Reinforcement Learning (In Progress):

Network plays against itself to discover new strategies beyond the training data
First run (overnight, 4 generations): Collapsed into passive play — both sides learned that doing nothing leads to draws, which felt "safe." Pass rate climbed from 21% to 43%, games stalled at maximum length.
Diagnosed and fixed with 7 anti-stalling mechanisms:
Draws penalized as losses (value = -0.5 instead of 0.0)
Time decay: winning quickly is worth more than winning slowly
Pass action penalty: MCTS explores non-pass moves more aggressively
Resignation: if a side evaluates below -0.9 for 3 consecutive rounds, it resigns
Increased exploration noise and reduced max game length
Second run (5 generations completed before crash):
Stalling largely eliminated in early gens (pass rate stable at ~20%, avg game length dropped from 993 to 833 moves)
Gen 3-5 showed some stalling creeping back (37% pass rate, 7 draws) but dramatically better than the first run
Loss decreased from 13.72 → 5.43 (network is learning)
Training speed: 10 steps/second on GPU, ~233 seconds per game
Current bottleneck: Each game takes ~4 minutes at 50 MCTS simulations. At this rate, the 750-game run takes ~50 hours. Tournament-level play would require 500K-2M games (months on a single GPU, or weeks on a cloud cluster).

Key open problems:

Allies side still underperforms (Axis bias inherited from supervised data)
Amphibious assaults (critical naval strategy) barely used — network hasn't discovered this tactic yet
Need crash recovery so overnight runs don't lose progress
Scaling to enough games for strong play requires either cloud compute or significant optimization (batched MCTS, game parallelism)
Next steps:

Add crash recovery (resume from checkpoint)
Restart self-play from Gen 5 checkpoint
Monitor for stalling regression and amphibious assault emergence
Once pipeline is stable, scale up game count

[RogerCooper]

@kindwind Have you tried any tests against the TripleA AI?

Why do you expect that more runs will get your AI to make amphibious invasions?

[Kindwind]

@rogercooper no nothing against the triplea ai yet. have to do some different work for that to happen. had to ask what the 1st principals of axis and allies were. Here is where it stands right now this is posted at 9:09 pm EST: What ProAI Does (The Heuristic)
It's a plan-caching agent — computes a full phase plan on first call, then drains it move-by-move. Key logic:

Purchasing: Assesses threat vs defense around factories. Three stances: Panic (80% infantry), Stabilized (mixed), Dominating (30% naval). USA gets a hardcoded Kill Germany First (KGF) override with 25% transports.
Attack planning: 3-pass system — first grab overwhelming wins, then standard wins with "can we hold it?" simulation, then risky VC/capital grabs.
Defense: Priority heatmap centered on capitals (11x multiplier). Includes a "Moscow Fighter Sink" — if Russia is in trouble, UK/USA fly all aircraft toward Moscow.
Amphibious: Yes, it HAS a shuck pipeline (load → sail → unload), with massive score bonuses for territories near Berlin (+25). But it's greedy — one route at a time.
Funny/Quirky Things It Does
Capital hoarding — Places ALL purchased units at the capital factory (5x multiplier). Russia stacks 15 infantry in Moscow while Leningrad falls.

Moscow Fighter Sink — UK and USA will abandon their own theaters to fly every fighter to Moscow if Russia is in trouble. Imagine Britain pulling fighters from North Africa while Germany walks into London.

Transport eagerness — Loads ALL ground units onto transports immediately, leaving ports completely undefended. "Everyone on the boat! ...who's guarding the harbor?"

Casualty order is context-blind — Always sacrifices cheapest unit first. Will throw away its last artillery (the unit that boosts infantry) even when keeping it would win the battle.

Zero tech research — Never invests in technology. Heavy bombers, jet fighters? Never heard of 'em.

No threat prediction — Reacts purely to current board state. Germany could stack 30 tanks on the Russian border and ProAI won't notice until they attack.

Estimating Amphibious Landings in Current Games
Based on what we know:

ProAI data had amphibious assaults (the shuck pipeline exists), but our diagnostic last session showed the GNN learned almost none of it — only 6 sea→land moves in a 7-round game, with 41 UK naval moves that went nowhere.
The network inherited ProAI's knowledge via supervised learning, but amphibious is a multi-step credit assignment problem (load → sail → land → fight → capture VC = 3-5 actions). The sparse reward signal makes it one of the hardest things to learn.
My estimate for Gen 6:

Game Moves Rounds Estimated Amphibious
Game 1 1500 R18 3-8 (long game, lots of time, but stalling)
Game 2 434 R5 0-1 (quick Axis land win, no time for naval)
Game 3 1500 R19 2-6 (draw = passive, minimal aggression)
Game 4 740 R8 1-3 (medium game)
Game 5 1500 R19 2-6 (draw, passive)
Game 6 217 R3 0 (too fast)
Game 7 1500 R18 3-8 (long game)
Gen 6 total estimate: ~15-40 amphibious assaults across all 15 games, heavily concentrated in the long stalling games. That's roughly 1-3 per game — far below the ~6-8 per game that competent human play would show.

We'll know for sure in about 20-30 minutes when Gen 6 finishes and prints the Naval: line. Could be wrong and I will have to look at what to do next if it is wrong.

We did get a signal from some proai play correct?
Yes — the supervised training on 5,000 ProAI-vs-ProAI games definitely contained amphibious assaults. ProAI has an explicit shuck pipeline, and USA especially has a hardcoded KGF strategy that buys 25% transports and targets territories near Berlin.

So the signal is in the supervised checkpoint (gnn_small_final.pt). The problem is how diluted it is:

A typical ProAI game runs ~8-10 rounds, maybe ~500-1000 total actions
Of those, maybe 20-40 are naval/amphibious related (load + sail + unload)
That's roughly 3-5% of all actions being amphibious
The other 95% is land combat, purchasing, passes, placement
The network saw 17.97 million training samples. Even at 3-5%, that's potentially 500K-900K amphibious action examples. That's not nothing — the network should have learned something.

The diagnostic from last session showed it did learn to move ships around (UK=41, Japan=31, USA=29 naval moves) but almost never the critical last step — actually unloading troops onto land. It learned "move ships" but not "land troops."

That's the credit assignment gap: the reward comes from capturing the territory (many steps later), not from the unload itself. Self-play with enough games should eventually close that gap since the network will see that games where troops land tend to end in wins. Have to fix the game buffer 1st fixing that. Will let you know more in about a week or two.

[RogerCooper]

@kindwind I will reiterate my suggestion to use the Minimap scenario to train the AI.There is no naval component to that game.

Good play will require an AI to do some sort of threat prediction.

[Kindwind]

@rogercooper Got it the 1st signal! There it is — amphibious tracking is live:

Game 1: 1500 moves, R18 — 1 amphib, 4 loads (troops loaded onto ships 4 times, landed once)
Game 2: 434 moves, R5 — 1 amphib, 2 loads (quick game but still had a landing!)
That's the signal we were looking for. Even in a short 5-round game, there's an amphibious assault happening. The golden data anchor is keeping the naval knowledge alive in the training mix.

The numbers are still low (human-level play would be 6-8 amphibs per game), but the fact that they're non-zero even in these early games is promising. As training continues and the golden data keeps reinforcing "ships can land troops," we should see this number climb.

Everything is running with all the new features:

Golden lock (30% buffer = 15K ProAI samples)
Buffer persistence (saves every gen)
Crash recovery (auto-save + --resume)
Per-game amphibious display
Anti-stalling fixes from before
If it crashes overnight, just run:

python -m colossus.selfplay --resume --golden-data data/proai_golden.pkl --generations 50 --sims 50 --games-per-gen 15 --train-batches 200 --eval-every 5 --eval-games 4 --batch-size 256 --lr 1e-4 --buffer-size 50000 --checkpoint-every 5 --temp-rounds 3
Game 1: 1500 moves, R18 — 1 amphib, 4 loads (troops loaded onto ships 4 times, landed once)
Game 2: 434 moves, R5 — 1 amphib, 2 loads (quick game but still had a landing!) so it was an attack or just a load?
Good catch — let me be precise about what those numbers mean.

amphib=1 means 1 move where a unit went from a sea zone → land territory. That's an actual landing (unload onto enemy/neutral coast).

loads=2 or 4 means units went from land → sea zone. That's loading troops onto transports.

So in Game 2: troops loaded onto ships twice, and one of those transported groups actually landed on a coast. That's a real amphibious operation — load, sail, unload.

But — there's a nuance I should flag. Our detection logic counts any sea→land move as "amphibious," even if it's just unloading at a friendly port during non-combat movement. A true amphibious assault is specifically unloading into a hostile territory during the combat move phase. We're not distinguishing between:

Amphibious assault (landing on enemy territory to fight)
Amphibious transfer (unloading at your own coast)
Right now the code just checks from_territory in sea_zones and to_territory not in sea_zones. It doesn't know if the destination is enemy-held or if it's combat vs non-combat phase.

So that amphib=1 might be an actual D-Day style assault, or it might just be UK moving troops from a transport to a friendly coast. Still a sign of naval power projection either way, but worth knowing the signal is noisy.

Want me to refine the detection to distinguish hostile landings from friendly transfers, or is the rough signal good enough for now?

what do we need just the rought signal right now?
Yeah, the rough signal is fine for now. What we care about at this stage is: are ships moving troops at all?

Before the golden data, the answer was basically no — ships sailed around aimlessly. Now we're seeing loads and landings. Whether it's a hostile assault or friendly transfer, both require the network to understand "put troops on ship → move ship → take troops off ship." That's the multi-step reasoning we needed.

We can refine hostile vs friendly detection later once the numbers are high enough to be worth splitting. Right now 1-2 per game is so low that subdividing it would just be noise.

Let's let this run overnight and check the generation summaries tomorrow. The key metrics to watch:

amphib/game trending up (golden data reinforcing naval play)
draw rate trending down (anti-stalling penalties propagating)
loss decreasing (network actually learning from the mixed buffer) 9:42 2/28/2026! will have other problems though this pretty hard stuff to crack for a non coder person.

[ubernaut]

@kindwind interesting possibly relevant edit post today:

https://www.reddit.com/r/AxisAllies/comments/1rhzj4m/can_llms_play_this_game/

[Kindwind]

@ubernaut that's the plan. I am going to do an LLM native ai. My final deliverable is a person takes their revised .tsvg game save of where they are at gets advice and then tells the lmm to play the other side. I think it's neat. Others not so much. I was thinking that people might like a Markov chain battle calculator too in the final deliverable too.

This is pretty hard for a guy who doesn't really code. I am sure my code is a mess but it works so there is that.

Trying to just have Claude play Claude calling my engine and a database seemed like a good idea to which I think he was doing too but the cost was like 1.20 a game and for 100,000 games the math didn't math. I tried using Qwen but it's not smart enough. Then there was another problem about distillation from Claude

I am stuck with ML for now and training it that way until I get an ok player and then a good player and then a super human player. It might not even work either no one has done this before made one work. I think I can get there just a wish right now.

Pretty sure I can get a really good heuristic model if this fails.

[beelee]

@kindwind said in Game Engine Rules (AI Training):

This is pretty hard for a guy who doesn't really code. I am sure my code is a mess but it works so there is that.

[ubernaut]

@kindwind interested to see your progress