Building Diamond Legend for Mobile and Console Without Splitting the Game
How a single cloud-backed account and a platform-agnostic core let the same franchise continue on the web, on a phone, and later on a console.
The usual way a sports management game reaches multiple platforms is to build several games. There is a web version, a separate mobile version with fewer features, and eventually a console version with different saves. Players end up with three franchises and no way to move between them.
We decided early that Diamond Legend would not do that. There is one game, one account, and one save, and the platform you happen to be holding is a presentation layer on top of it.
Where the game actually lives
Everything that constitutes your franchise lives in the cloud: identity, save state, league standings, transaction history, achievements, and progression. None of it is stored solely on a device.
That has an immediate consequence for how the client is written. A client is not allowed to be the authority on anything that matters. It renders state and it sends intents. It does not decide the outcome of a game, it does not decide whether a roster is legal, and it does not own your save.
This is more work than the alternative. It is also the only architecture where you can start a season on a laptop, advance three games on a phone during a lunch break, and pick up the same franchise on a television later without anything being reconciled or lost.
One account everywhere
A single identity backs every platform. Sign in on a new device and your franchise is there — not a copy of it, the same one. There is no per-platform account, no linking flow, no export and import.
This also means entitlements travel. If you have Pro, you have Pro everywhere, because the entitlement is attached to the account rather than to a store purchase on a particular device.
What each platform actually changes
If the core is shared, what is left to build per platform? Presentation and input.
Web is the widest surface, with dense tables and multi-panel layouts that a mouse handles well.
Mobile has less screen and different input, so the same information gets progressively disclosed rather than removed. The distinction matters: the mobile version is not a reduced game, it is the same game arranged for a thumb. Every decision available on the web is available on a phone.
Console adds controller navigation and a viewing distance measured in feet rather than inches, which mostly means larger type, focus-driven navigation, and different information density.
None of those are forks. They are layouts and input handlers over one shared core.
Why offline is a hard problem, honestly
The obvious objection to a cloud-authoritative design is offline play, and it is a real cost. Our position is that a franchise which silently diverges between a device and the cloud is worse than one that requires connectivity for advancement, because divergence eventually means losing progress and nobody can tell you which copy was right.
So advancement is server-authoritative. Reading your roster, browsing your farm system, and planning are all things we want to work with a poor connection. Advancing the season is not.
What this bought us
Ordering. Because the core was built platform-agnostic from the start, adding a platform is a client project rather than a game project. The web version and the mobile builds already share the same engine, the same league state, and the same account. When a console target becomes viable, it inherits all of it.
The version of this we were trying to avoid is the one where a player asks whether their phone franchise can move to their computer and the answer is no. That answer is a product failure, and it is almost always an architecture decision made years earlier.