After you publish

How players find you

Discovery on Galatrix is a browser of published games with search and categories, plus four sorts that reward four different things.

• Most active rewards concurrency: who is being played right now. It is the sort where a small game with ten people in it can outrank a bigger one that is empty.
• Most popular rewards accumulated plays. It moves slowly and it favours age.
• Newest rewards nothing but arriving. It is the one window where a game with no history is on equal footing, which makes the first days after publishing worth planning for.
• Top rated rewards the ratings players leave.

Featured placement takes active players, total plays and recency together, so it leans towards things that are both proven and current.

Read those together and one thing follows: concurrency compounds. A game with people in it is easier to find, which puts more people in it. So the first handful of players counts for more than their number suggests, and the invite and copy-link buttons are not an afterthought. Getting five friends in at the same time moves where you sit in the lobby.

Players can also like a game. Every card in the browser carries its likes and its play count, so those two numbers are public: yours, and everyone else’s.

Reading the numbers you have

Play count answers one question well and one badly.

It answers did anyone arrive — and whether that changed when you posted a link somewhere. It does not answer did anyone stay, which is the question that decides whether a game grows. A hundred plays and no returning players is not a discovery problem; it is a first-thirty-seconds problem.

It also cannot tell you where people gave up. If you need that, there are two ways to get it. Instrument it yourself with your game’s own data calls, or watch someone play and stay quiet while they do. The second is faster and usually tells you more.

Iterating without breaking things

Publishing again updates the map players already know, so shipping a change is cheap. Making a good change is the hard part.

• Change one thing at a time. If you adjust the difficulty curve and the reward rate together, nothing afterwards can tell you which one moved.
• Give it a few days. Daily numbers are noisy, and a dip because you shipped on a Tuesday is not a signal.
• Write down what you expected. “A shorter first wave should keep more people past the opening.” When you are wrong, that sentence is the useful part.
• Remember the player who already played. Someone with saved progress meets your change mid-stream. Consider what the update does to a save made before it.

Player data and saves

Your game gets its own player data, meaning per-player saved state, without you running a database. Two things about how that behaves in the wild:

Guests are real players with fragile progress. A player who has not signed up can still play, and their progress lives in their own browser. It syncs upward if they make an account. Design as if some fraction of your players will lose their save by clearing a browser, because some fraction will.

Saves are per-game unless you said otherwise. That is the default and usually the right one. If you deliberately grouped several of your games onto one save bucket, remember that a change to what you store in one of them now touches the others.

Your game’s own economy

There is an in-game currency, and it is shared across the platform: players carry it between worlds and spend it on cosmetics for their avatar as well as on whatever your game offers them.

Treat it as game design rather than business. A currency that arrives too easily kills the loop it was meant to power, and an upgrade that gates the fun instead of extending it reads as a wall. The tools are there; restraint is the part you supply.

Performance is a retention problem

The one place analytics and craft meet directly. A player on a mid-range laptop or a phone who gets a stuttering first thirty seconds leaves and never appears in any signal except low playtime.

If playtime is short and you cannot see a design reason, suspect the frame rate before you suspect the design. Profile it, check what you are asking the browser to draw, and be willing to lower a draw distance rather than defend it. A game that looks slightly worse and runs smoothly wins every time.

Where to go next

If you have not read it yet, publishing and what review means covers the states a map moves through and what a Map ID is for. On the player side, playing on Galatrix is worth a skim — knowing what your players see before they reach your game explains a lot about who arrives.