oecs-sharp/docs/testing-games.md

Testing games

1. Games are DLLs. Use a standalone test project to test a game.
2. Create baseline game snapshots in textual format. Save to files.
3. Create baseline logs via the R3 observable API. Save to files.
4. Read the snapshot/logs manually to identify issues.
5. Make sure serialization roundtrip works.

Play tests

The goal of playtests is to execute a game with AI players and potentially random seeds. Then the log/snapshots are read by the LLM agent to spot issues.

There is no failure in play tests; all tests pass but the agent should read the log for reference.

AI players are not LLMs here; they are typically common game AI implementations.

Create static functions that analyze the game state and return a command. Each such function is an agent. Each AI player routes its decisions to a random agent in a pool of weighted agents.

Agents to consider:

• Random: evenly chooses every move randomly.
• Greedy: uses a specific way to score actions. Always chooses the one with highest score. There can be multiple Greedy agents with different scoring.

For each playtest attempt, generate a full game log, analyze and report what you find from the log.

Round Runner

Playtests should run multiple rounds, not just one. The recommended pattern:

while chips >= minimum_bet AND chips < 2× starting_chips:
    place bet → deal → agent decides hit/stand → resolve → new round

This exercises the full game lifecycle including deck reshuffling, round transitions, and chip management. Safety cap at ~200 rounds to prevent infinite loops.

Play Log Format

Each play log should contain:

• Header: agent name, seed, result summary, win/loss/push counts.
• Round Summaries: per-round result, chip delta, hit count.
• Decisions: per-decision hand total and choice (Hit/Stand).
• Reactivity: raw R3 observable log of component/entity changes.
• Final State: snapshot of the world after all rounds.

Logs are saved as .playlog files alongside test output for manual review.