We started building games. We accidentally started building a game platform. The interesting part is not that games need infrastructure; it is deciding which parts deserve to become shared, and which should stay with the game that needs them.
The repeated work becomes visible
A strategy game needs much more than a board and a set of rules once people start playing together. Players need an identity. Matches need an authoritative state. Progress needs to survive a disconnect. If a turn can wait for days, the match also needs a dependable way to bring someone back.
Those needs are central to the experience, even though they are not the mechanics that make one game different from another. Building alongside Battle for Velune makes the distinction tangible. The tactics belong to the game. Accounts, stored matches and communication are the surrounding work that another game is likely to need too.
Build against a game, not an imaginary checklist
It is easy to write a long list of features a platform could have. It is harder to know which ones help a game ship and which ones merely make the platform look complete. Our own games give that work a practical constraint: a capability should answer a problem we can describe in terms of a player or a match.
For Velune, correspondence play is one of those constraints. A match has to wait between turns and resume without losing its place. That connects identity, authoritative state, asynchronous play and persistence in a way a feature checklist cannot explain on its own. The player does not experience those as separate modules. They experience a game that is ready when they return.
Working from a real game does not mean every feature we build belongs in the shared platform. Sometimes a solution is specific to the rules, presentation or pacing of that one game. Keeping it local is a useful outcome. Reuse has to earn its place by making another game simpler, not by making the platform larger.
Leave room for a different second game
The risk of building infrastructure around one game is that the game quietly becomes the definition of the platform. Its assumptions get built into every interface. Later, a different project is asked to fit those assumptions even when they have little to do with its design.
We want to keep that risk visible. Live play and asynchronous play put different demands on a system. Thinking about both helps us distinguish a general responsibility, such as storing match state, from a particular policy, such as how quickly a player must act. The platform should offer useful building blocks without deciding every game's architecture.
Make the work useful beyond ourselves
Nerdino Platform is in active development. Building our own games gives us a starting point, not a complete view of what other studios need. Working with design partners is a way to expose different constraints while the boundaries are still being shaped.
The conversation we want starts with the game: how people play, what needs to persist and where multiplayer becomes difficult. From there, we can work out which pieces of infrastructure are worth sharing. The aim is to help a team spend more of its attention on the game without asking it to surrender the decisions that make that game its own.
That is why we are building the two together. The games keep the platform grounded, and the platform gives recurring work a place to live. Neither is finished, and neither should dictate every choice the other makes. The useful measure is whether the next game gets more room to be itself.
