g2048: empty_count stale during tile placement — trained model collapses under correct 2048 rules

[InFiNiTeemo]

Bug

In g2048.h c_step(), place_tile_at_random_cell() is called before update_stats(), so it uses a stale empty_count from the previous step. When a merge creates new empty cells, rand() % old_empty_count can never select them — cells that appear later in row-major scan order get 0% placement probability.

// c_step(), line 370-376
if (did_move) {
    game->moves_made++;
    place_tile_at_random_cell(game, get_new_tile());  // ← stale empty_count
    game->score += score_add;
    update_stats(game);  // ← updated too late
}

Why it matters

In standard 2048, new tiles are placed uniformly across all empty cells. This bug breaks that uniformity. The effect is worst in endgame (1–3 empty cells), where:

• 1 empty → merge → 2 empty: rand() % 1 = 0, placement becomes 100% deterministic
• 2 empty → merge → 4 empty: two cells get 0% probability

The agent learns to exploit this predictable placement, not to play 2048.

Fix

if (did_move) {
    game->moves_made++;
    update_stats(game);                                // ← move here
    place_tile_at_random_cell(game, get_new_tile());
    game->score += score_add;
    update_stats(game);                                // ← update again after placement
}

Reproduction (100 episodes each, same checkpoint)

	Bug version	Fixed version
≥ 2048	100%	0%
≥ 32768	84%	0%
≥ 65536	33%	0%
Max tile	65536	1024
Avg moves	32,702	502

Both columns are from my own runs with 100 random seeds. The model doesn't degrade gracefully — it completely collapses, meaning the learned policy depends entirely on the biased tile distribution.

Impact

• PR Simplified 2048, but reliably reaches 65k #474 merged this into the 4.0 branch on Jan 24, 2026
• The 33.96% 65k rate (cited in the PR and blog posts) is for a modified variant of 2048, not standard rules
• Any model trained on this environment needs retraining after the fix

cc @jsuarez5341