OrOgins: getting a game and its AI to work together

OrOgins is a two-player elemental strategy game whose digital version was created in 2015. The brief, in my Year 2 project and again in the rebuild, was to modernise its interface and let people play it against an AI opponent.

Each side has two royals and eight element pieces: earth, water, fire and air, each beating the next in a cycle. Elements move like chess queens and paint the squares they cross. Royals can only travel forward or sideways along painted, empty squares, so the elements have to build their roads. A player wins by getting both royals to the rank in front of the opponent's home row. An element that crosses a square painted in the colour it beats wipes it and knocks off a royal standing there, and a player who loses a royal can no longer win.

I managed our three-person team and built the game in Unity; a teammate encoded the rules in a Python Gym environment and trained a PPO agent on it. The plan was to export the trained policy and run it inside Unity. The export was never written, nothing in Unity called the model wrapper, and when the module ended the game and the AI still could not talk to each other.

Year 2 in detail: what the agent learned from, what the tests showed, and how we ran it

Reading the environment code shows how narrow the agent's choice really was. It picks a square; the environment then moves that piece to the first legal destination it finds. Rewards say “legal move” or “illegal move” and ±100 at the end, so good play was never directly rewarded.

Explanatory diagramDerived from OriginsEnv.step() and reset() in env.py and the PPO settings in train.py

One step of the observation–action–reward loop, as coded

• Implemented
• Decision
• Incomplete, or a gap found in testing

View full size

One step of the observation–action–reward loop, as coded

−100%+FitClose

Text version of this diagram

Parts

• PPO policy (MlpPolicy) — one policy plays both sides; teammate
• Action: a square, 0–79 — the policy never picks a destination
• Own piece on that square?
• Reward −1 — same player tries again
• Any legal move?
• Reward −1 — turn passes
• Take the first legal destination — fixed direction order
• Move, convert path squares, capture — reward +1
• Game over? — both arrived, a man or woman lost, or no moves
• Reward ±100 and reset — sign follows the mover, not the winner; incomplete or failed in testing
• Switch turn
• Observation: 100 integers — 80 squares, turn, 4 arrival flags, padding; bounds declared ±3 but pieces use ±6; incomplete or failed in testing

Connections

• PPO policy (MlpPolicy) → Action: a square, 0–79
• Action: a square, 0–79 → Own piece on that square?
• Own piece on that square? → Reward −1: no
• Own piece on that square? → Any legal move?: yes
• Any legal move? → Reward −1: no
• Any legal move? → Take the first legal destination: yes
• Take the first legal destination → Move, convert path squares, capture
• Move, convert path squares, capture → Game over?
• Game over? → Reward ±100 and reset: yes
• Game over? → Switch turn: no
• Switch turn → Observation: 100 integers
• Reward −1 → Observation: 100 integers
• Reward −1 → Observation: 100 integers
• Observation: 100 integers → PPO policy (MlpPolicy): next step

Without capture and victory rules in place, a win rate could not measure anything, so I tested what could be checked deterministically. The failures were the useful part: they pointed at missing rules rather than at the learning code.

Test and validation results recorded in the final reflection

• Board dimensions Passed10 columns × 8 rows
• Board initialisation MixedPieces and starting positionsTests passed; the stricter validator failed 1 of 4 checks.
• Observation encoding PassedLength and piece codes of the 100-value observation
• Element interactions MixedThe strength cycle, including fire against airTests passed; the air-against-earth validation crashed with an index error.
• Movement FailedPieces move in their allowed directions“Evolutionist man should move up”.
• Turn switching FailedThe turn passes after a move
• Destination timing MixedThe goal rows are recognisedStalemate after a maximum number of turns failed.
• AI decision checks MixedCapture and protective moves are availableChecks the rules, never the trained policy; strategic progress failed.
• Whole-game validation Mixed26 rule checks across the environment15 of 26 passed.

Several copies of the environment existed, so these results describe the build tested at the time, not a single final version.

We worked in Agile sprints with a Trello backlog, stand-ups and reviews; SDLC structured the game track and CRISP-DM the learning track. Sprint 1 ran long because Unity and the rules took far more time than planned, so by the time the environment and PPO arrived there was little room left to connect them.

Explanatory diagramDerived from the sprint plan and contribution tables in the final reflection

Three sprints, two tracks, one unfinished connection

Sprint goals and my part in each

Sprint	Team goal (sprint plan)	My part
Sprint 125 Nov – 16 Mar	Initialise the project, set up Unity, build the board and pieces.	Scrum Master. Requirements, project, risk and quality plans; Unity setup, board, pieces and C# scripts.
Sprint 217 Mar – 3 Apr	Custom Gym environment, PPO training and integration.	Model testing and debugging with the teammate who built the environment.
Sprint 34 Apr – 6 Apr	Completion, evaluation, validation and the presentation.	Scrum Master. Ran and documented the test and validation scripts; sprint review.

1. Sprint 125 Nov – 16 MarScrum Master: me

   Initialise the project, set up Unity, build the board and pieces.

   My part Requirements, project, risk and quality plans; Unity setup, board, pieces and C# scripts.

   • Game track (SDLC) Requirements, plans, Unity board and pieces

2. Sprint 217 Mar – 3 Apr

   Custom Gym environment, PPO training and integration.

   My part Model testing and debugging with the teammate who built the environment.

   • Learning track (CRISP-DM) Gym environment + PPO (teammate)
   • Integration Trained policy inside Unity: not reached

3. Sprint 34 Apr – 6 AprScrum Master: me

   Completion, evaluation, validation and the presentation.

   My part Ran and documented the test and validation scripts; sprint review.

   • Integration Trained policy inside Unity: not reached
   • Testing Tests + validation

• Sprint or work
• Mine
• Planned, not reached

View full size

Three sprints, two tracks, one unfinished connection

−100%+FitClose

Text version of this diagram

• Sprint 1 (25 Nov – 16 Mar): Initialise the project, set up Unity, build the board and pieces. I was Scrum Master. My part: Requirements, project, risk and quality plans; Unity setup, board, pieces and C# scripts.
• Sprint 2 (17 Mar – 3 Apr): Custom Gym environment, PPO training and integration. My part: Model testing and debugging with the teammate who built the environment.
• Sprint 3 (4 Apr – 6 Apr): Completion, evaluation, validation and the presentation. I was Scrum Master. My part: Ran and documented the test and validation scripts; sprint review.
• Game track (SDLC): Requirements, plans, Unity board and pieces (25 Nov – 16 Mar)
• Learning track (CRISP-DM): Gym environment + PPO (teammate) (17 Mar – 3 Apr)
• Integration: Trained policy inside Unity: not reached (17 Mar – 6 Apr)
• Testing: Tests + validation (4 Apr – 6 Apr)

Explanatory diagramDerived from the CRISP-DM figure and text in the final reflection

CRISP-DM for the learning track

1. 01Business understandingAn AI opponent for a two-player strategy game
2. 02Data understandingRules, board state, actions and observations
3. 03Data preparationRules coded into OriginsEnv; only legal moves allowed
4. 04ModellingPPO with Stable-Baselines3 (teammate)
5. 05EvaluationMy test and validation scripts; rule checks, not a win rate
6. 06DeploymentPolicy inside the Unity game: not reached

↺ back to 01

• Stage
• My contribution
• Incomplete, or a gap found in testing
• Not reached

View full size

CRISP-DM for the learning track

−100%+FitClose

Text version of this diagram

1. Business understanding: An AI opponent for a two-player strategy game
2. Data understanding: Rules, board state, actions and observations
3. Data preparation: Rules coded into OriginsEnv; only legal moves allowed
4. Modelling: PPO with Stable-Baselines3 (teammate)
5. Evaluation: My test and validation scripts; rule checks, not a win rate (my contribution)
6. Deployment: Policy inside the Unity game: not reached (not done)

Situation

An unfamiliar engine, complex rules and two technologies developed side by side.

Task

Plan the work, build the Unity foundation and keep the team heading for a working game with an AI opponent.

Action

I set up the plans, built the board and scripts, and turned testing into a record of which rules worked and which did not.

Result

A Unity prototype and a separate trained-agent pipeline, but no working connection between them.

Learning

Plan smaller end-to-end milestones, agree one environment specification, and test the integration boundary first. It is exactly where the rebuild started.

In June 2026 I came back to OrOgins as project manager and technical lead of a rebuild, with a supervisor, weekly progress meetings and reviews with the client. The goal was the one Year 2 missed: a game you can actually play against the AI.

The starting point was an earlier 8 × 8 student version of the Python engine. The original game is played on 10 columns by 8 rows, so I reworked the engine to implement the original rules on the correct board: royals riding painted trails, captures by wiping tiles, and the win and can't-win conditions. Every rule became an automated test.

My Year 2 Unity game became the interface. It now holds no rules and no AI: it draws whatever state the Python engine sends back, and passes on the player's clicks. Players choose PvP or PvAI and Easy, Normal or Hard, and for the first time the game, in its proper interface, plays against a trained AI.

The earlier version came with a deep-learning agent, but it could not be reused. It was sized for an 8 × 8 board and never saw painted squares, which decide who can move. Only 7 of its 4,032 outputs even meant the same move on the 10 × 8 board.

So I trained a different kind of AI. The Hard level tries every legal move on a copy of the game, measures the result with 12 features and scores it with 12 learned weights. The weights were fitted in seconds by ridge regression over positions from about 500 self-play games. It is not a neural network, and it does not learn while you play.

80 automated tests cover the rules, checks against the original game's behaviour, the three AI levels and the server. The Hard AI was benchmarked over 40 games against each easier level, alternating colours: 85% against Easy (34 wins, 0 losses, 6 draws) and 57.5% against Normal (23–7–10).

Watching it play showed a problem the win rates hid: it kept moving the same piece back and forth. Many moves scored exactly the same, and the first-listed one kept flipping. Where a reversal did win, it won by a sliver, because going back over its own trail painted nothing new. Two rules fixed it: when scores tie exactly, prefer a move that does not undo the last one; and rather than make a second reversal in a row, take a non-reversing move scoring within 0.0007 of it.

The game still needs a Python server running on the player's machine. That rules out the plan to sell OrOgins on Steam and itch.io and to publish a self-contained browser demo. I compared six ways of removing it, scored them against eleven weighted criteria, and stress-tested the result.

The key finding was that Flask serves the rules, not just the AI: four of its five endpoints are rule operations. A model runtime such as Unity's Sentis cannot generate a legal move or paint a tile, so every option that removes Flask needs the rules in C#.

The hybrid was accepted on 2 September 2026. The rules and all three AI levels move into C# inside Unity, with the 12 weights embedded as plain numbers. Python stops shipping but stays the authority: it records reference games, the C# version must match them at every step, and it remains the training environment and a possible future online server.

Today the game is playable through the Python server. The shared codebase has moved to the 10 × 8 board and the C# port is under way. Progress is reviewed weekly with our supervisor, and an experienced reviewer will play the first version before wider testing.

1. Freeze the data contract, the order legal moves are listed in, and the Hard AI's move rules.
2. Record reference games from the Python engine.
3. Port the rules, then the game flow, then the three AI levels to C#.
4. Check the C# version against Python, move for move, automatically.
5. Build offline PC and browser versions; mobile after that.