A platform should know how to run a match without deciding what makes a good move. That is the boundary we are drawing at Nerdino: games own their rules; the platform owns the infrastructure that gives those rules a reliable place to run.
Start with the decisions only the game can make
Whether a knight can move to a tile, whether a card can be played and whose turn follows are questions about a particular game. They are not general-purpose networking concerns. Moving those decisions into infrastructure would make every new game negotiate with assumptions inherited from the previous one.
The game therefore supplies the meaning of an action. Its rules decide whether the action is valid, how it changes the state and what can happen next. The platform runs those rules on the server. Keeping this boundary clear lets a game change its design without needing to disguise a new mechanic as something the backend already understands.
One place owns the truth
An authoritative server gives the participants a shared answer about the match. Clients can present the board, explain choices and send player actions, but the server checks those actions against the game's rules. A local screen should not be able to make an invalid action become part of the real game.
This does not require every game to have the same board, the same actions or the same turn structure. Authority describes where a decision is accepted, not what that decision must be. The platform can provide a common place to validate and apply actions while leaving their meaning with the game.
The distinction also helps when something goes wrong. Questions about an illegal move belong with the rules that evaluated it. Questions about getting a client connected or recovering stored progress belong with the surrounding infrastructure. A useful boundary gives us a clearer place to look, rather than a promise that failures will never happen.
The plumbing should earn its reuse
Identity, persistence and client connections are necessary work, but they are rarely the reason someone chooses to play a particular strategy game. Repeating that work for each project takes time away from the decisions that make the games different. Shared infrastructure is valuable when it removes that repetition without taking over the design.
Deployment and client SDKs belong on the same side of this boundary. A game needs a way to run its server and a way for its clients to communicate with it. Those are platform concerns. Which actions the client offers, what the player sees and how a turn feels remain decisions for the game.
A boundary, not a universal blueprint
There is a temptation to describe a platform as the complete architecture for every game. We are aiming for something more selective. Different games put pressure on different systems. A live co-op session and an asynchronous tactics match may share identity and persistence while needing different approaches to session timing and communication.
That is why the platform is organised into building blocks. The goal is to reuse the pieces that solve recurring problems and let each game keep control of the rest. A common interface is useful only when it preserves a meaningful choice for the game using it.
Battle for Velune gives this boundary a concrete place to be tested. Its rules describe its tactical game; the platform supplies the infrastructure around those rules. As we build, the question is whether the separation makes the next change easier to understand. If a platform abstraction makes the game harder to express, the boundary deserves another look.
