[Chichimokers]

AoE2:DE 1v1 Automatch2 (simple implementation)

Summary

This adds a minimal, self-contained 1v1 Automatch2 implementation for Age of Empires II: Definitive Edition. It lets two clients queue through the game's ranked/scored matchmaking UI and get matched against a local ageLANServer instance, with the relay/BattleServer doing the actual game connection.

The implementation is intentionally small: it is a first working pass that proves the protocol path end-to-end and leaves rating, map pools, team games, and policy refinements as follow-up work.

What is implemented

• GET /game/automatch2/getAutomatchMap support for the AoE2:DE 1v1 queue.
• POST /game/automatch2/polling queueing/pairing for AoE2:DE.
• POST /game/automatch2/stoppolling cancellation.
• POST /game/automatch2/updateStatus match status updates.
• New internal/models/automatch2.go with queue, pending match, host reservation, notifications, expiry and cleanup.
• 1v1 aliases accepted (20, 6, 1) and exposed as canonical queue/leaderboard 6, 2 players, team size 1, map Arabia.rms.
• Earliest queued player becomes host. The match ID is reserved as the future advertisement ID.
• Host receives a matched polling response before the advertisement exists and creates the advertisement through POST /game/advertisement/update (AoE2:DE does not call /advertisement/host for this flow).
• Joiner receives the matched polling response once the advertisement exists and is notified over WSS with Automatch2GameMessage.
• Automatch2GameMessage uses the object form with named fields and object members, matching what the client expects.
• Per-client relay IP resolution: the BattleServer address is resolved from the local IP that client used to reach the server, not from the synthetic advertisement IP. This avoids the client trying to DNS-resolve values such as /10.0.11.x.
• Platform session ID is stored on the pending match before the advertisement exists and copied into the advertisement when it is created/updated.
• Automatch advertisements are explicitly flagged. Automatch joins bypass the random advertisement password and take teams from the polling response.
• Existing custom games, advertisements, sessions, WSS and BattleServer behaviour are kept intact.

Protocol findings worth highlighting

• The AoE2:DE advertisement array accepted by the tested client has 27 fields, not the 24-field layout in some public samples. A 24-field response made the client log WorldwideUpdateAdvertisementAsync - response was not formatted correctly and AdvertisementByIDCache - response was not formatted correctly for both automatch and ordinary advertisements. The 27-field layout was accepted.
• Polling response field 1 is elapsed wait seconds, not a state enum.
• Polling response field 4 is the host profile ID.
• SESSION_MATCH_KEY + matchtype=1 + maxplayers=4 + empty map is an ordinary session/party host; only matchtype=19 (or a positive automatchPoll_id) identifies an automatch advertisement.
• getProfileName?profile_ids=[-1] can appear during joins and is not by itself evidence of a wrong host ID.

Testing

• Tested with two AoE2:DE clients in the Ranked/Scored Multiplayer 1v1 Automatch flow against a local server, with battle-server-manager started manually.
• Verified queueing, pairing, host reservation, server-managed advertisement creation, Automatch2GameMessage, platform session ID propagation, and per-client relay IPs in the server/client logs.
• Rebuilt only the changed binary (server.exe) for testing; no build artifacts are included in this PR.

Current limitations / follow-up work

• 1v1 only, one fixed map/queue.
• No MMR/skill-based matching and no real leaderboard updates.
• Simple earliest-host pairing; no host migration.
• Minimal cancellation/retry policy; current code requeues on host failure.
• No NAT/relay fallback beyond the existing BattleServer setup.
• The advertisement/GameMessage formats should be validated against future client versions.

These are explicit follow-ups rather than blockers for this first functional implementation.

Related documentation

I also documented the empirical findings for the community in a Libre:Match wiki PR:
librematch/wiki#1