Autopilot · write-up

Xenon 2 Level 3 strategy

xenondoc/LEVEL3_STRATEGY.MD · 12 KB · updated 2026-09-17

This is a deliberately small mission policy. It separates facts which are known before play from facts which still require one bounded observation. It must not be implemented by adding more global autoplay scoring terms.

Geometry and mission route

The complete Atari resident tile map is the source of truth. The interactive Level 3 route and runtime controller now use the same four-pixel navigation raster and the same $387C shifted wall mask. That game hull is already a conservative 29×24 pixels, so Level 3 adds no second dilation; an extra four pixels disconnects authored narrow passages.

The map distinguishes immutable terrain from nine statically authored large wall-shooter gates. The backward-spawn table at $604E8 provides each type-5 controller's exact world centre and dispatches through $4F8D0 to Level3LargeWallShooter_Init ($503A6). The first destruction stage at $50C1A clears fourteen body cells. The final hit path at $50F54 clears the remaining eight cap cells. Runtime map observations require two complete canonical frames of absence before changing a tagged solid cell to free; ordinary terrain remains monotonic.

The mission order is G1 through G9 as displayed in the HTML report. For each gate:

1. Keep all later gates closed in configuration space.
2. Run four-pixel A* from the current ship anchor to the current gate's firing station.
3. Hold the station at (origin X+32, origin Y+104) and fire forward.
4. Keep immediate survival authoritative while the gate is attacked.
5. Advance only after live tile observations prove all 22 cells of that gate are free.
6. Replan to the next gate against the newly opened topology.

The firing station is derived from game collision rectangles, not artwork: $50A7A..$50AA2 installs the body damage rectangle at X+16..47, Y+64..90, and $50CF8..$50D2E installs the cap rectangle at X+16..47, Y+4..27. Both stages therefore cross the same forward-cannon lane.

This replaces the former hard-coded initial polyline. It also fixes the earlier offline model which opened every gate before planning and consequently drew routes that could bypass a still-live controller.

Policy reduction

The first-volley fixed-X staging rule, deliberate wall-collision “brace”, paired-swarm staging latch, and camera-window route owner were exploratory policies, not validated game models. They have been removed. The retained Level 3 mechanisms are:

• semantic object fields and exact update-procedure predictors;
• world-coordinate motion, projectile, formation, and pending-spawn forecasts;
• the resident/live destructible map and ordered gate mission;
• generic pressure relief, targeting, and the common space-time survival planner;
• the independently validated articulated-carrier intercept.

Survival compares every physically legal candidate. If a tactic's preferred action has a finite predicted collision and another action survives longer, the safer action wins even outside the old eight-frame emergency gate. Equal-survival choices may still prefer route progress or reaction room. A complete space-time escape queues at most eight actions; the remaining prefix is revalidated every canonical frame before another action is used.

Deterministic pre-volley acceptance

The checkpoint regression has one result: the ship must complete the bounded interval without shield damage or a lost life. record_run.py owns this as a general acceptance condition, so it still closes the event stream, saves the final snapshot, and releases input before returning a failing exit code:

python xenon_tools\record_run.py level3-prevolley-acceptance.x2events --mode autopilot --snapshot xenon_tools\run_logs\level3-stage2-periodicshot-prevolley-0826-222.sav --fresh-controller --frames 120 --require-no-damage

This assertion evaluates observed shield/life telemetry only. It does not encode a desired X coordinate, tactic name, target, or action sequence.

Encounter annotations

The external walkthrough is used only for encounter intent because it describes the Master System port, not authoritative Atari geometry:

• Expect important health carriers at the start.
• Expect attacks from behind and from lower corners; Rear and Side Shot coverage matters.
• In the long narrow passage, stage near the corridor centre and clear wall extenders instead of hugging their walls.
• Preserve a Z/Zapper pickup for the later dense swarm rather than spending it immediately.
• The Level 3 boss weak point is the tongue/base. Avoid ramming it; the upper corners provide more room while waiting for the weak point.

The first bounded Atari run identified two previously unclassified overlay families without adding new strategy machinery:

• $4F244/$4F24E are scripted-sine swarms and use the existing exact script predictor.
• $50996 calls the existing $4180 16-direction projectile update before changing its Level-3 sprite/state, so it uses the existing directional-projectile predictor.

The run lost one life because these entries had been classified as generic enemy/unknown; they never entered survival prediction. This is a capture/classification defect, not evidence that the route or global arbitration should be retuned.

The next bounded runs exposed one arbitration-order defect. The retained route was selected before the already-existing pending-spawn pacing and pressure-relief phases. Consequently the controller calculated the correct delay, ignored it, advanced the camera, and allocated the next formation only a few frames before contact. Level 3 now treats the route as branch ownership rather than continuous permission to advance: immediate survival wins first, pending-spawn pacing and bounded pressure relief may pause progress inside the route tube, and the exact same retained route then resumes. No new planner or encounter state machine is involved.

The accepted Level-3 handoff initially carried Side Shot, Laser, and an upgraded primary weapon. The first exploration accidentally crossed a Rear pickup at frame 37980. Rear and Side share the wing mount, so the game silently replaced the guide-recommended Side Shot; later runs therefore used the wrong loadout. Attachment capability now comes from the captured semantic shop-item type, not from guessed projectile velocity, and Level 3 treats a Rear pickup as non-collectible while Side is installed.

The correctly equipped run reached scroll 3685 with one life and shield 27, then exposed the next route invariant. Immediate avoidance had displaced the ship from the X160 backbone into a right-hand bottom pocket around X240..258. Spawn pacing continued there instead of reconnecting to the retained route. By the time the threat cleared, the opening required more backward camera motion than the game's 16-pixel allowance, and LEFT/UP each triggered $42E wall replay. Therefore Level-3 pacing is also constrained by the retained route tube. Immediate survival may leave it, but non-imminent pacing must reconnect before it advances the camera.

The first implementation of that constraint exposed two controller errors in short checkpoint branches instead of another full run. A redundant path to the bottom pacing row created a stable Y171/Y176 camera loop at scroll 4112. After removing that Level-3-only sub-route, one-frame endpoint ranking fought the real horizontal steering accumulator and created an X191/X200 loop. Re-entry now commits the joystick toward the fixed route while the exact movement model continues to predict the delayed displacement for collision safety.

Run level3-steering-commit-0825-15.x2events validates the navigation correction: it crossed the former scroll-3685 pocket and continued to scroll 3539 without a route stall. It is not a Level-3 acceptance run. The ship accumulated seven hits (51 shield damage, with one 20-point recovery) and lost its last life. Recorded associations were two generic $4180 destruction/projectile-family contacts, one $107C destruction contact, two $0E1E swarm contacts, one $4F244 scripted-sine contact, and one $50996 Level-3 reflecting-directional-projectile contact. This is now the separate combat gate; the validated route must not be changed to tune it.

The same run began with the wrong wing weapon despite semantic inventory. The initial analysis mistook the Rear attachment allocated under the ship at frame 38052 for the released pickup. Raw lifecycle review corrected this: released pickup identity 290885 was visible from frame 38011 and followed the deterministic $4EA0 compass-orbit-then-drop path. Its payload/status $44 was known before contact. Level 3 now retains Side Shot by protecting one side of the predicted drop lane, including the ship's exact $661C braking coast; it does not create another movement goal or replace the offline route.

Run level3-rear-avoidance-0825-16.x2events validates that bounded rule. The Rear Shot reached its fixed X=166 fall, passed to screen Y=193, and despawned; Side Shot remained installed in every one of 800 captured frames. Ordinary pickups were still collected, the route advanced from scroll 4557 to 4118 without a route reset, and no life was lost. One later $5073C formation contact cost eight shield, which belongs to the separate Level-3 combat gate and must not be used to retune this pickup or navigation policy.

Articulated carrier intercept

The $4FADE carrier is not a target to chase. Its vulnerable $4FD38 core follows an exact scripted world-space trajectory: it enters on the right, reverses, and crosses a stable forward firing lane while two $4FE52 emitters can release damaging chains. Re-aiming at the core every frame moved the ship from X201 to X169 and into the chain tail. Treating the instantaneous space between the emitters as configuration space was also wrong because the emitters become moving chain heads after launch.

At encounter entry, predict the selected live core 24 canonical frames through its update table. Convert that future core collision centre to a ship-anchor coordinate and latch a six-pixel-wide world-X attack lane. Hold screen Y 152..156; the independently searched no-hit branch remains at Y154, and Y159 intersects the tail's inclusive interaction rectangle. Forward Shot and Laser share this useful upward lane. Rear Shot cannot hit a target above the ship, while installed Side Shot is still fired automatically whenever the core crosses its horizontal lane. Survival may temporarily leave the attack lane only for a concrete predicted collision; target animation or motion alone may not move it.

Run level3-composite-intercept-lane-0826-145.x2events validates the model from the pre-encounter checkpoint: zero shield loss, zero lives lost, the carrier/core family was removed, score increased by 1000, three released drops were collected, and the game entered the shop transition. Run level3-post-composite-0826-146.x2events then completed the shop and entered the next Level-3 area without damage.

Sources: Lemon Amiga shop sequence, GameFAQs walkthrough.

Shop policy

The Atari/Amiga sequence is encoded semantically, not by grid position:

• First Level 3 shop: replace Rear with Side when the replacement is funded, buy two Power Ups, reach Side grade two, then grade three if cash permits.
• Second Level 3 shop: prioritize Drone; buy Cannon and another Power Up only from surplus cash.
• Never buy Autofire, Advice, or temporary Nashwan Power in an ordinary post-level shop.

Low-cost exploration protocol

1. Start from the accepted playable-Level-3 checkpoint, not Level 1.
2. Run only to the first unclassified route break, death, or route stall; save a checkpoint there.
3. Inspect the short .x2events interval and both AVIs. Record the object's update procedure and lifecycle before proposing an encounter tactic.
4. Add one Level-3 policy fact and one synthetic invariant. Do not change shared arbitration unless the same model defect is reproduced by an existing Level-1 or Level-2 fixture.
5. Re-run from the nearest checkpoint. A full recorded run is an acceptance test, not discovery.