The Brief
A football management game, played with a squad of ants.
Management sims are a strange genre to build, because the player never touches the ball. There’s no aiming, no timing, no reflex. Everything the player does is a decision made before the match and a result they read afterwards which means every ounce of engagement has to come from three places: were my decisions good, did the outcome feel fair, and where do I sit against everyone else.
Get any of those three wrong and you don’t have a hard game. You have a spreadsheet nobody opens twice.
The Match Engine
Matches resolve through a stat-based simulation rather than a physics engine. No ball, no pitch, no animation deciding anything; squad attributes, tactics and matchups go in, a result comes out.
This is harder than it sounds, and the difficulty is entirely in the balance. Simulate too honestly and the better squad wins every time, which makes the league predictable and the table static by week three. Add too much variance and player decisions stop mattering, which is the faster way to lose an audience – nobody keeps playing a game where their choices don’t move the needle.
The target is upsets that feel earned. A weaker squad should beat a stronger one often enough to be worth watching, rarely enough that the standings still reward good management. That ratio gets tuned against real match data over many simulated seasons, not guessed at.
Leagues, Seasons and the Table
This is the actual retention engine, and on a management game it deserves more attention than the match itself.
Leagues put every player in a bounded competitive group where their position is legible at a glance. Seasons give the game a beginning and an end, which means a player who’s had a bad run gets a reset instead of a permanent reason to quit. Leaderboards turn a private decision into a public one.
The design principle underneath all of it: someone playing a management sim isn’t primarily playing against the simulation. They’re playing against the other managers, asynchronously, through a table. So the table has to be the most prominent object in the game, updated in a rhythm people can build a habit around, and structured so there’s always a position within reach.
Social features follow the same logic. Comparison, rivalry, and the ability to see what a better manager did differently are what bring people back on day thirty not the match engine, however good it is.
An Economy That Has to Stay Balanced
Teams earn from match results, ticket sales and jersey sales. Squad members can be traded and upgraded.
That’s a closed economy with real inflows and outflows, and it needs modelling as one. Every source of currency is inflation; every upgrade, transfer fee and entry cost is a sink. Get the ratio wrong and within a few weeks the top of the table is unreachable, new players arrive into a game that’s already been won, and acquisition stops converting.
We build these to be retunable from configuration rather than from a build, because you will get some of it wrong at launch and you’ll want to fix it the same week rather than the next release cycle.
The Backend Decides Everything
The match engine runs on our own Node.js backend. So does the economy.
The reason is straightforward: squad assets have transferable value, which means every player has a direct financial incentive to influence a result, and a meaningful number of them will try. Anything decided on the client is decided by whoever is willing to open a debugger.
So the client submits decisions and displays outcomes. It doesn’t compute them. Match simulation, economic transactions, upgrades and transfers are all validated server-side with a full record of what happened and why – which matters twice over when an asset with market value changes hands, because disputes are inevitable and “we have the log” is the only useful answer.
It’s the same architectural discipline behind our iGaming work and the netcode in our multiplayer titles, applied to a slower game where the stakes per transaction are higher.
The Ownership Layer
Squad members are ERC-721 assets, teams are held through DAO wallets, and the in-game currency is a token on BNB Chain, with smart contract and wallet integration built into the Unity client.
We’ll be matter-of-fact about this: the ownership layer is a feature of Ant Soccer, not the reason it works. What keeps a management game alive is the table, the season and the economy and those would need to be just as well built if there were no chain involved at all. Where on-chain ownership genuinely adds something is transferability and provable scarcity in the squad market. Where it adds friction is at the front door, which is why we build these so the wallet never blocks a first session.
What We’d Bring to Your Project
- In a management sim, the table is the product. Build the competitive structure before you polish the match.
- Tune the simulation for earned upsets, not for accuracy. Accuracy makes leagues boring.
- Model the economy as an economy; sources and sinks, retunable from config, before launch rather than after inflation.
- Put every consequential calculation on the server. Especially when assets have resale value.
Work With Us
If you’re building a sports title, a management or strategy sim, or anything where a league table and a persistent economy carry the retention — the difficult parts are the simulation balance and the backend that has to be right the first time. Both are ours.
More on how a full project runs with us, from scoping through handover.
Tell us the sport, the season structure and how the economy is meant to work. Scope, team and a fixed quote come back within two business days.
Got a Game That Needs to Ship?
Send a design doc, a build, or three sentences and a reference game. We’ll come back with scope, team and a number.
