Post by Hartix in Rivok — Real-Time .io Strategy comments

Rivok — Real-Time .io Strategy » Comments

Viewing post in Rivok — Real-Time .io Strategy comments

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.

HKM Industry6 days ago

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 ⚡

Hartix5 days ago

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.

itch.io

Viewing post in Rivok — Real-Time .io Strategy comments