story: Capital Siege — precision game mode scoring by proximity to each country's true capital

[benibauer3]

Context

From the same GTM sync: a Capitals campaign where players buy pixels near a country's real capital city, and whoever holds the pixel closest to the true capital's coordinate when the round closes wins. This is a distinct mode from Connection Campaigns (#266) — #266 connects two cities across a live sports fixture; this scores a single fixed target by distance, not a connection between two points.

Proposed approach

Reuses the pixel-to-coordinate math already built for geoToPixel (apps/web/src/lib/pixelMath.ts) — no new geographic infra needed. Add a distance formula: for each player's held pixel(s) in the round, compute distance from that pixel's real-world coordinate to the true capital's coordinate; smallest distance wins.

Likely needs the same (gameId, pixelId) ephemeral-ownership approach being proposed in the War game mode issue (#277), rather than the persistent Mondeto.sol contracts — same "starts from zero, nobody owns it after" requirement probably applies here too.

Open questions — for @GigaHierz and @ghozzza

• Ground-truth dataset for each country's real capital coordinate — where does this come from / who maintains it?
• Does one round cover one country's capital, or many at once (a multi-country leaderboard in a single round)?
• Same entry fee / prize structure as War, or different?
• Shares story: War game mode — timed buy-and-defend contests with ephemeral per-game ownership, up to 20 concurrent #277's ownership model, or does this need something else?

Acceptance criteria

• Distance-scoring formula implemented against a defined capital-coordinate dataset
• Ownership/board model decided (shared with story: War game mode — timed buy-and-defend contests with ephemeral per-game ownership, up to 20 concurrent #277 or separate)
• Entry fee + prize flow confirmed with Lena/Ghoza

[ghozzza]

Answers below, each with what I measured rather than what I assume. Section 1 is measured across the whole country set rather than a sample, because two of the three problems in it only appear that way.

1. The capital dataset — three problems, and the third is the one that will reach players

apps/contracts/map/data/ne_10m_admin_0_map_subunits.geojson is already vendored, so the obvious move is to read capitals out of it. It has no capital coordinates. Its only point fields are LABEL_X / LABEL_Y, which are Natural Earth's label placement points — where to draw a country's name so it doesn't collide with a border.

The replacement is its sibling file, same project, same public-domain licence: ne_10m_populated_places, filtered to FEATURECLA = "Admin-0 capital", reading LATITUDE / LONGITUDE. Verified against the file itself (7,342 features; those four fields present; 202 entries in that class).

Joining the two, three things came out — measured across all 358 subunits, dependencies excluded from the error figures since their ADM0_A3 resolves to the parent state's capital and that is a join artefact, not a label error:

(a) LABEL_X/Y is close enough to look fine and not close enough to score. Median error 169 km, p75 449 km, p90 974 km, worst 4,125 km (Russia — the label sits in Siberia, Moscow does not). One world-map pixel is about 235 km at the equator, so 93 of 237 countries (39%) are off by more than a whole pixel. For a mode whose entire premise is precision, that is not a rounding error. It is also completely invisible: every one of those points sits inside the right country, on land.

(b) 87 of 358 subunits have no Admin-0 capital at all — Gaza, West Bank, Western Sahara, South Sudan, Sint Maarten, Guantanamo Bay and so on. So the pool of playable countries has to be defined and stored, not derived at runtime from the map. Otherwise the first round that rolls one of those either crashes or silently falls back to something wrong.

(c) Five countries have more than one Admin-0 capital, and this is the one that reaches players. South Africa has four in the dataset (Bloemfontein, Pretoria, Johannesburg, Cape Town); Bolivia has Sucre and La Paz; Côte d'Ivoire has Yamoussoukro and Abidjan; Myanmar has Naypyidaw and Yangon. "Distance to the true capital" has no single answer for those, and whichever one the code picks first, a player who guessed the other is correct and scored as wrong. Either exclude them or pick deliberately and say so in the UI — but it should be a decision, not whatever [0] happens to be.

Who maintains it: nobody on our side, and that is the point. Vendor the file and pin the Natural Earth release, exactly as the subunits file already is, so a capital that moves is a deliberate re-vendor rather than a silent upstream change mid-season.

2. The part that will actually eat the time is not the dataset — it is that we have two projections

To score "distance to the true capital" you have to turn a lat/lon into a pixel id, and this repo does not have one way of doing that. It has two:

• World map — Equal Earth, rasterised from Blank_world_map_Equal_Earth_projection.svg by convert_map.py.
• Continent maps — generate_continents.py, which is equirectangular with a cos(latitude) aspect correction at the continent's mid-latitude (x = lon * cos(lat_mid), y = -lat), plus a per-continent longitude recentre (shift_lon) so a continent that straddles the antimeridian doesn't wrap.

So a latLonToPixel(map, lat, lon) has to branch per map and reuse each generator's own constants — the mid-latitude it chose, the centre longitude, the bounding box it fitted. If it re-derives any of them independently, every capital lands off by a constant offset, and a constant offset in this game looks like a hard round, not a bug.

For scale: the world map is 170 pixels across 360 degrees, so one pixel is roughly 235 km at the equator — which is also the figure the 39% in section 1 is measured against. A projection mistake stacks on top of that, and neither is visible in the output.

Suggestion: generate the capital-to-pixel table from the same scripts that generated the masks, as a build step, and commit the output. Then add one control — assert that a handful of known capitals land on a land pixel belonging to the right country. Without that control, a projection error is indistinguishable from the game being difficult.

3. One country per round or many

One per round for v1. Two reasons, and the second is the real one:

• The projection work above is per-map, so a single-country round keeps the first implementation inside one map's coordinate system.
• A multi-country leaderboard needs a normalised distance. Kilometres per pixel varies with latitude under both projections, so "12 pixels away" in Norway and "12 pixels away" in Kenya are not the same guess. Ranking them against each other without normalising quietly rewards players who drew the high-latitude country. Worth deciding deliberately rather than discovering from complaints.

Multi-country is a good v2 once the scoring function has a defined unit.

4. Fee structure, and the ownership model

Same as #277, whatever #277 becomes. I would not fork the money path twice — one entry-fee-and-payout mechanism, two scoring rules on top. My recommendation on #277 is that the game contract holds entry fees and pays the leader at timer-end rather than routing through the manual treasury withdrawal that exists today; the reasoning is in that thread.

Yes to sharing #277's (gameId, pixelId) ephemeral ownership. Nothing in this mode needs persistent ownership either, and one contract with a pluggable scoring rule is less surface than two contracts that drift. That also keeps the "no changes to Mondeto.sol or any existing map contract" criterion intact for both.

The difference between the two modes is the scoring function alone: War ranks by pixel count, Capital Siege ranks by distance. That is a good sign they belong in the same contract.

[benibauer3]

Thanks @ghozzza, the measurements here change the design. Responses:

1. Dataset. Agreed: use ne_10m_populated_places (FEATURECLA = "Admin-0 capital"), vendored with the Natural Earth release pinned, not LABEL_X/Y. With a median error of 169 km and 39% of countries off by more than a pixel, the label points are not usable for a precision mode.

The playable pool is defined and stored, not derived at runtime. That covers the 87 subunits with no capital.

Countries with more than one capital (South Africa, Bolivia, Côte d'Ivoire, Myanmar and the fifth): exclude them in v1. If we add them later, it should be an explicit per-country choice that the UI states.

2. Projections. Agreed: generate the capital-to-pixel table from the same scripts that produced the masks, commit the output, and add the control you describe: a handful of known capitals must land on a land pixel of the correct country.

3. Scope. One country per round for v1. Multi-country is v2, once the score has a normalised unit.

4. Contract. Agreed: same (gameId, pixelId) ephemeral ownership and the same entry-fee and payout mechanism as #277, with a pluggable scoring rule (pixel count for War, distance for Capital Siege). That keeps the "no changes to Mondeto.sol or any existing map contract" criterion intact for both.

The dependency on #277's decisions (board size, money-path bar) stands, so this one follows it.

@GigaHierz, we'd like your opinion here too, in particular on:

• excluding the multi-capital countries in v1
• one country per round for v1
• sharing one contract and one payout path between War and Capital Siege