
Technical Challenge: AI Decision Engine
Context
As part of a recruitment process, I was asked to participate in a CodinGame challenge. The goal was to develop a bot capable of reaching the Gold League in the Soak Overflow challenge.
The game pits two teams of agents against each other on a grid. Each turn, every agent must choose a movement and an action (shoot, throw a bomb, or hunker down) to maximize the team's chances of winning while taking allied movements, territorial control, cover, and many tactical interactions into account.
Objectives
Beyond the ranking itself, I chose to design a decision engine that is:
- modular;
- explainable;
- easy to improve;
- based on explicit domain rules rather than hard-to-interpret scores and coefficients.
Solution
The core of the project is an individual decision engine executed independently for each agent.
Every decision combines several layers of analysis:
- threat evaluation;
- offensive opportunity evaluation;
- effective damage estimation based on cover;
- territorial control;
- BFS pathfinding for movement;
- ally coordination through simulation of the current turn state.
The architecture clearly separates responsibilities between the map representation, spatial computations, agents, game state, and action generation.
Approach
The project evolved significantly throughout its development.
An initial architecture, mainly based on collective strategies, quickly reached its limits despite many iterations.
Rather than adding more and more special cases, I decided to completely rethink the approach and refocus the logic around a much more capable individual decision engine.
Every change was validated experimentally using a script that automated multiple challenge runs, reducing the impact of leaderboard variability.
This iterative process allowed me to identify genuinely beneficial improvements and eventually reach the Gold League.
Result

Beyond the final ranking, this project mainly reflects my engineering approach: building understandable solutions, measuring their effectiveness objectively, and questioning my own design choices whenever the results show that an approach has reached its limits.
Consulter la présentation détaillée du projet