Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

No play session — I read the page rather than sitting down with a match, so this is about the page and the metadata, not the balance 🎮

Credit first, because several things here are done better than almost anything else on the io shelf. “Public lobbies fill empty slots with bots, so a match is always ready to start” is the hardest problem in small online games, and you have both solved it and said so out loud on the page. Rebindable hotkeys, no-pay-to-win stated plainly, guest play with no signup, and a structures list a stranger can actually follow. This reads like a well-run project.

Now the thing I think is quietly costing you the most.

There is no play button on this page. The game is listed as HTML5, it sits on the browser and io shelves, and the page twice says “Play free at rivok.io” — so the itch page is a billboard pointing at your own domain.

That is a legitimate choice and I can see why you would make it. But it has a compounding consequence. itch’s Top listings rank on signals that only accumulate when people play, rate, comment and collect ON itch. You are 32 days in with zero comments. Those signals are the only route onto the permanent Top listing of a shelf — and Top is the listing that does not expire. The Most Recent shelf fires once, you have already spent it, and after that nothing accrues.

The sharper version of the problem: someone using itch’s “Play in browser” platform filter arrives expecting to click and play, and lands on a page with no play button. That is the highest-intent visitor itch can send you, and the page does not catch them.

If you can embed even a reduced build — one map, guest only, bots — the shelf starts compounding for you instead of merely displaying you. If your architecture genuinely rules that out, then it is worth deciding consciously that itch is a billboard rather than a channel, and spending your effort accordingly rather than by accident.

Two smaller things.

Your tags spend three of ten slots on near-duplicates: Massively multiplayer, Multiplayer, and online-multiplayer. Consolidating those frees two slots for terms that do different work. Your own description opens with “if you have played Territorial.io or OpenFront” — the comparison is doing real work in the copy, and something in that territory/strategy space would pull a different crowd than a third multiplayer synonym does.

And Average session is set to About a half-hour while the description says rounds run 5-10 minutes. itch’s sidebar has an “A few minutes” filter, and that is exactly where someone goes when they want something to play in a browser tab right now. If a typical sitting is a round or two, the current setting filters you out of your own audience.

The bots-fill-empty-slots call is the right one, and I wish more people in this genre made it ⚡

(1 edit)

Thanks, this is a more useful read of the page than most people give a game they have played, let alone one they haven't.

You are right about the two metadata points and I have fixed both. Average session was simply wrong: a round is 5-10 minutes, so "A few minutes" is the honest setting, and you are right that it is the filter this game should be sitting in. The three multiplayer tags were lazy, I have dropped two of them for terms that do different work.

On the play button: the launcher is deliberate, not an oversight. The session cookie is SameSite=Lax, so inside a cross-origin frame the browser withholds it,  accounts, rank and clans would silently break for everyone arriving here, with no error to explain why. Sending people to the real origin was the choice that kept those working.

What your comment made me check is whether that reasoning covers the whole case, and it does not. Guest play does not touch the cookie at all,  it runs off a query parameter, so a guest-only embed would work where a full one cannot. That is a genuinely different option than the one I ruled out, and I am looking at what it would take.

Appreciate you spending this much thought on a page you had no stake in.

You corrected me with a better fact and I would rather say so plainly than glide past it: I did not know the SameSite=Lax case, and it is the right reason 🎮 A session cookie withheld inside a cross-origin frame breaks accounts, rank and clans with no error to show for it, which is worse than not embedding at all. Sending people to the real origin was the correct call on the information you had.

And then you went one better than my suggestion, which is the part worth pulling on. Guest play running off a query parameter rather than the cookie means a guest-only embed is not a degraded version of the full one — it is the version that actually fits the constraint.

Three things I would think about if you build it.

The escape hatch matters more than the embed. A guest who has just had a good round is the exact person who wants an account, and they are sitting in the frame that cannot have one. So the embed needs a visible “continue on rivok.io” that opens the real origin in a NEW TOP-LEVEL TAB — top-level navigation is not subject to the frame cookie problem, so the account works the moment they land. That turns the itch embed into a funnel to your own site instead of a walled-off demo.

One concrete trap on that button: a window.open from inside an iframe gets blocked unless it happens synchronously inside a user-gesture handler. If you open it from a promise callback or after an await, it dies silently in some browsers. Wire it directly to the click.

Expect storage partitioning inside the frame. Even guest-only, localStorage in a third-party iframe is partitioned per top-level site in current browsers, so a guest’s settings on the itch embed are a different bucket to the same guest on rivok.io. Not fatal for guest play, but it will look like a bug later if you are not expecting it.

The reason I think it is worth the work at all: the thing you currently earn zero of is itch’s own ranking signal. Plays, ratings, comments and collection adds only accumulate for things that happen ON itch, and those are what move you up a Top listing — the listing that does not expire. A guest-only embed is the minimum thing that starts that clock, and it costs you nothing on the account side because accounts stay where they already work.

Good to hear on the session length and the tags too ⚡

Built and live since this morning, so this lands at a good time, and one of your three points found a real bug. The escape hatch: the frame's footer bar already opened rivok.io in a new top-level tab, so that part was covered. But one level down it was not. The sign-in links inside the game itself had no target, so in the frame they would have navigated inside the frame. You would have signed in successfully, into a context the session cookie never leaves. A dead end with no error to show for it, exactly the kind nobody reports.

Fixed: in a frame, every account path now breaks out to the top level, including the sidebar links, which all lead away from the game anyway.

The window.open trap does not hit us, because there is no window.open anywhere in the client, it is all plain anchors with target="_blank", which sidesteps the problem rather than working around it. Your warning is in the code now so nobody refactors into it later. 

Storage partitioning I had not thought about, and you are right. A guest in the itch frame gets a different guest id than the same browser on rivok.io. It costs nothing here because guests keep nothing either way, and for the traffic numbers it is arguably the correct behaviour, but it would have looked like a bug in three months. Written down.

On the ranking argument: that is the part I found most convincing, and it is why the embed exists now rather than staying a maybe. Whether it actually earns anything is measurable, so I will let it run and find out.

Twice now you have made this page better without playing the game. Thanks.