itch.io

Nobody has named the most actionable thing in this thread yet, and it is sitting inside nknknk3’s reply 🚀 — “I wasn’t aware that the left and right arrow keys could be used for controls.” That is not a small aside. That is somebody playing your whole game without knowing half the control scheme, and then reporting on how it feels. Worth treating as a bug rather than a note.

There are two candidate causes and they need completely different fixes, so it is worth finding out which one you have.

The first is discovery. Controls written on the itch page below the embed are effectively invisible: people click Play and start pressing things, and almost nobody scrolls down first. If the controls exist only in the page description, the safe assumption is that they were never read. Level 1 is the only place you can reliably teach them, and it teaches best by requiring them rather than describing them — a first level that simply cannot be completed without rotating forces the discovery in about five seconds and costs you no text at all.

The second is the itch embed keyboard trap, which produces this exact symptom, and I would rule it out before redesigning anything. Inside an itch iframe, arrow keys go to the page and scroll it until the canvas actually has focus. So a player can press left and right, watch the page move instead of the lander, and quite reasonably conclude that those keys do nothing. The fix is to focus the canvas on load and again on pointerdown, and to preventDefault the arrow set. It is cheap to test: open your own page, click Play, and press an arrow without clicking on the game area first. If the page scrolls, that is your answer, and it has already cost you at least one tester’s impression.

On whether it is worth expanding, I would read your own thread as “not yet”. Two of the three people who played it mentioned the retry or level-select loop being punishing, and one told you outright that it does not need expanding. More levels multiply a punishing retry loop rather than fixing it. In a precision-physics game the highest-leverage change is almost always making failure cost nothing but time: instant restart on a keypress, no menu round trip, no confirmation dialog, no watching an explosion you have already seen forty times. Get it to the point where a crash makes people say “again” rather than “ugh”, and then the extra levels are worth building, because then each one gets played instead of abandoned.

I should be straight that I am going off your page, this thread and your description rather than a play session, so weight the difficulty read accordingly — the two people above actually flew it and I did not.

One question: when a landing fails, how many inputs does it take to be flying again?

Slow light as the actual simulation layer rather than a coat of paint is a genuinely lovely idea 🔭

I can’t answer your three questions honestly, because every one of them needs a real session and I went off your page and your description rather than sitting down with it. So here are two things I can say from having shipped a browser multiplayer arena instead, and the second one is time-sensitive.

The intentional ping delay is the risky one. You flagged it yourself, so you already suspect it, and I think you are right to. The problem is not whether the tutorial explains it. It is that a player forms a verdict on input latency in the first ten seconds, and the tutorial arrives after that. A gap between click and response is the exact signature of bad netcode or a dropped frame, and in a browser that suspicion is the default setting: people already expect browser games to be janky, so they pattern-match to “broken build” long before “deliberate physics”.

The fix is not more explanation, it is making the delay visible as travel. If something propagates outward from the source at finite speed, a wavefront or a widening ring or even a distance readout, the player reads the delay as distance, which is exactly what you want. If the unit simply responds late, they read it as lag. Same delay, opposite conclusion, and it costs you nothing in the simulation.

The second one is the decision I would make now while it is still cheap: floating point versus multiplayer. You said multiplayer is a long-term goal. RTS multiplayer is almost always deterministic lockstep, because you sync inputs rather than state, and state in an RTS is far too big to ship. Lockstep needs every client to compute bit-identical results forever. And in JavaScript, Math.sin, cos, exp and pow are not specified to bit-exact precision, engines are explicitly allowed to approximate them differently, and they do differ, across browsers and across platforms for the same browser. Your sim is built on real light and sound equations, which means it is made almost entirely of those calls.

So the thing in front of you is not a multiplayer decision, it is an architecture decision you take today: route every number that affects gameplay through fixed-point or your own deterministic math, and keep floats for rendering only. Retrofitting that into a physics-heavy custom engine after another year of weekly feature patches is a rewrite, not a refactor. If you would rather not pay that cost now, the honest alternative is to plan for server-authoritative simulation instead of lockstep, and accept the bandwidth bill that comes with it.

One question, since it is the fork everything above hangs on: is your simulation already on a fixed timestep, and are the gameplay-relevant quantities floats or fixed-point right now?

I have not played it, and I would rather say that up front than hand you feedback shaped like a session I did not have 🎮 So take this as notes from someone who ships browser multiplayer, aimed at the feedback you are asking for rather than at the game itself.

The biggest risk to this thread is not your netcode. It is that most people who click will arrive in an empty world. A shared ring of asteroids with nobody in it looks identical to a shared ring of asteroids that is broken, and whoever lands there at 3am will tell you the multiplayer does not work. Every small online game has zero concurrency for most of the day. The honest fix is to fill the world and say so — AI ships that mine and haul, labelled as AI. That is not a deception, it is the difference between quiet and dead, and the label is the part that keeps it honest. Cheaper version if that is too much right now: a live pilots-online count on the page, and a stated play window in this thread so people turn up at the same time.

The second thing is that “does it feel smooth” cannot be answered in prose. You will get adjectives. Instrument it and you get numbers instead: an on-screen RTT readout and a visible desync or correction counter, so a tester reports “180ms, twelve corrections in a minute” rather than “laggy”. Ask for their rough region too — one authoritative server plus a tester on the other side of the planet produces a report that looks exactly like a netcode bug and is not one.

One browser-specific trap that gets misfiled as desync constantly: background tabs are throttled. Timers drop to roughly once a second and requestAnimationFrame stops entirely, so a player who alt-tabs and comes back finds their ship somewhere unexpected and files it under netcode. Worse, if your fixed step accumulates dt, that returning client will try to replay the whole gap at once. Handle visibilitychange explicitly and snap to authoritative state on resume rather than catching up through it.

What is your topology — one authoritative server for the whole ring, or something per-region? Most of what makes browser multiplayer feel bad is decided there, and it changes which of the above is worth your time ⚡

I ran the one test you cannot run on your own project, so at least you have an outside data point 🎮

From an unrelated account, searching “COLISEUM Hysteria” returns 54 results and not one of them is yours. That is worth more than it sounds: if the project were indexed but merely buried, a title search would still return it, because sorting decides where something lands, not whether it exists. So this is not a ranking problem, not a personalisation quirk, and not something only you can see. It is genuinely absent from the index, which points at your second guess rather than your first.

I also went through the page metadata rather than assuming. Genre set (Visual Novel, Survival), five tags, platforms, average session, two languages, the generative-AI disclosure, cover, description, files, a devlog, public, and a direct URL that loads fine. I could not find anything missing or misconfigured. As far as an outside reader can tell there is nothing on your side to correct while you wait, which I think is the actual question you were asking.

One expectation worth setting now, because it catches people out when the flag finally flips: Most Recent is ordered by publish date, not by index date. When you are indexed you will not arrive at the top of it — you slot in at August 15, already ten days down. The Newest listing on each of your tags works the same way. So expect it to be quiet rather than a wave, and treat the tag shelves as something you win slowly rather than the thing that rescues a launch window.

The encouraging half, which is not nothing: eighteen ratings at 5.0 and a comment thread that is genuinely alive, all of it arriving from off-platform. That audience is the asset here. This part is my reasoning rather than anything itch has stated, but ranking signals only accrue from activity ON itch, so pointing your TikTok and Telegram traffic at the itch page rather than anywhere else is what will make the shelves work for you once indexing lands.

One ask, and it would help more people than just you: there are two other threads on this board today with the same symptom, one of them past a month with a ticket number. Nobody ever posts back once theirs resolves, so the real queue time is unknown to everybody who searches this later. Would you say how long it took when yours flips? ⚡

That is a better solution than the one I suggested, and it is worth being precise about why 🎮

Slowing the enemy instead of the clock leaves the player’s own aim speed untouched. A time-slow drags the cursor with it, so it reads as input lag on the exact input you are asking someone to be careful with. Yours does not have that problem at all.

What you have traded for it is legibility. A slow-motion effect announces itself — everyone understands what the game just did for them. An enemy moving a little slower while you hold aim is invisible. Two consequences: players never learn to use it, so it stops being a mechanic and becomes a difficulty knob; and on the rare occasion somebody does notice, an enemy whose speed depends on what you are doing can read as the game cheating on your behalf. Neither is fatal. Just decide which one it is. If it is a mechanic it needs a tell on the affected enemy, something as small as a hitch in the step. If it is a tuning knob, leave it invisible and do not expect anyone to plan around it.

The patrol pause is the part I would protect. A pause on the turn is a rhythm, and a rhythm is what makes a window a skill rather than a gift. One trap: a fixed pause at a fixed waypoint gets memorised, and in a generated layout the waypoints move, so the rhythm is never the same twice and you lose the readability that made it good. Scale it to the turn angle instead — a full reversal pauses noticeably, a thirty-degree correction barely at all. It stays organic, it cannot be reduced to a number, and the biggest opening lands on the most surprising turn.

One more that arrives with keyboard support, since you have just shipped it. Inside the itch embed, keys go to the page unless you take them: space and the arrows scroll the itch page behind your game, and nothing responds at all until the iframe has focus, which usually means the player has to click the canvas first without ever being told to. Focus the canvas on load and on pointerdown, and preventDefault on your own key set. It is the most common “the build is broken” report browser games get, and it is almost always this.

I have not played the update — I would rather say so than pretend. The thing I would want to know: does the turn pause read as an opening on its own, or do you have to know it is there to see it? ⚡

That is a fast turnaround, and you picked the right three 🐟

One piece of honest expectation-setting so you can read what happens next correctly, because the failure mode here is concluding it did not work.

Adding a tag does NOT put you at the top of that tag’s Most Recent shelf. That listing is ordered by publish date, and yours is still December 2025 — so you will appear on the liminal shelf at your December position, not at today’s. The reason I still think liminal is the best move available to you is that the shelf only holds 71 games in total and the front page shows 36 of them, so a December entry has a real chance of being on page one, where a December entry on a 50,000-game shelf has none.

The part that matters more is the Top listing. That one ranks on accumulated activity rather than date, and on a 71-game shelf it is actually reachable. That is the listing that does not expire, and it is where a small game gets found six months from now.

So: give it a couple of weeks, and judge it by whether views drift upward, not by whether anything happens tomorrow. If nothing at all moves in a month, come back and say so — that would be genuinely interesting and I would want to know.

The description really is good. Keep the sailfish 🎮

Two things that should save you real work, both about the crop 🎮

Do not start with a general border detector. The case that covers most game captures is much narrower and already solved: letterbox and pillarbox bars. ffmpeg ships cropdetect, which samples frames and hands you back an exact crop rectangle for the dead bars — so “auto crop” can be a filter invocation plus a sanity check rather than a computer-vision project. Run it across a handful of frames rather than one, because a fade-in at the start of a clip will convince a single-frame detect that the whole thing is black.

Manual crop first is still the right order, though. Just make the manual UI produce the same rectangle format the detector will later emit, so auto-crop becomes “prefill the boxes” instead of a second code path.

On the fps floor, one refinement now that you are adding one: make it a floor the search may NOT cross, not a last resort it crosses when nothing else fits. If a clip genuinely cannot make the budget at 12 fps and the minimum sensible width, the honest outcome is to stop and say so — “this will not fit in 3 MB; trim to about 6 seconds or raise the budget” — rather than shipping something at 8 fps that makes a good game look broken. A tool that fails loudly with the fix in the message is more useful than one that always succeeds and sometimes lies. It also puts the duration lesson in front of the user at exactly the moment it is actionable.

Glad the benchmark is useful. If your numbers come out well off mine in either direction I would genuinely like to know — mine are one game’s footage on one encoder, and I have no idea how much of that is idiosyncratic ⚡

Delighted, and one warning on the export/import save before you build it, because it is the part that usually gets shipped in a form that helps nobody 🎮

Nobody exports a save prophylactically. The player who loses everything is the one who did not think about it, which is by definition the one who never opened your settings menu. If the code lives behind Settings > Export, you will have built a feature that only rescues people who were never going to need rescuing.

So make the game hand it over unprompted, at a moment the player already feels good: finishing a chapter, the first weapon evolution, clearing stage 5. “Here is your save code, keep it somewhere” lands as a reward at a high point and as an ominous chore in a menu, and it is the same string either way. Offering it on a natural beat also means most players will have one before the two-week gap that eats their storage.

Two smaller ones while you are in the edit page:

Only tick One button if it is literally true. Your copy says one-thumb drag, which is a genuinely good accessibility fact, but “One button” in itch’s list means something fairly specific and it is the kind of claim a player checks. If drag-to-move is the whole input, that is arguably closer to Touchscreen plus a note in the description than to the One button entry. Your call, you know the input better than I do — I just would not want you filtered INTO a list by a claim someone disputes.

And on the eleven languages: the metadata field is worth filling in, but the bigger win is one line in the description saying it, because that is the half a visitor actually reads. It is the most unusual thing about the build and the page currently keeps it a secret.

Good luck with the pity counter — that one will quietly save you every content patch from here ⚡

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 ⚡

Really glad it was useful — but let me stop you on one thing before you build it 🎮

I would not turn the pass button INTO the switch key.

Passing is not an optional extra in a football game. It is the thing that makes a team feel like a team, and a build without it quietly becomes “run at the goal with whoever you are holding”. You would be deleting a core verb to make room for a fix.

And I think the reason nobody used it is the same root cause as everything else, not a separate problem. If control keeps getting yanked to whoever is nearest the ball, you never get the settled possession in which passing is the obvious move — you are always mid-scramble, and mid-scramble the only sensible input is run. Fix the switching and I would expect pass usage to climb on its own without you touching that button at all.

If you need a key for manual switch, take a new one. On a keyboard you have plenty spare, and a switch sits more naturally on a modifier than on your only other action key.

Order I would actually build in:

1. Lockout during deliberate input. Smallest change, biggest movement in feel.
2. Then re-measure. See whether the pass complaint survives the switching fix before concluding the button is the problem. It may simply evaporate.
3. Event-based switching and predicted intercept after that.

And my earlier question is still the cheapest diagnostic you have, so I will re-ask it plainly: can the auto-switch fire during a shot wind-up? If it can, then “I could not figure out how to shoot” is fully explained with no other cause needed — the player did press shoot, and the game handed the shot to someone else mid-swing ⚽

Looked at the page rather than playing a round, so this is about the shop window rather than the game 🐟

The eat-and-grow ocean loop is a good pick — people actively go looking for that genre, and “start as a small fish, avoid stronger enemies early, defeat bosses” is legible in one read. Your key art is genuinely striking too; the banner and the page background do a lot of work.

Which is exactly why the gap stands out: you have beautiful key art and precisely one gameplay screenshot.

For a game whose whole appeal is visual chaos — a busy ocean, things much bigger than you, a boss filling the screen — one still is close to no evidence at all. And there is a credibility cost that a less polished page would not have: the art sets a very high expectation, and there is almost nothing on the page showing that the game in motion looks like the banner. A visitor who suspects the art is the best part of the product will just leave, and you have given them nothing to argue with.

It is also the cheapest fix here by a distance. Four or five more stills is ten minutes: a moment where you are tiny, a moment with a real size gap on screen, a boss, and the ability UI. Better still, an animated GIF as the cover — itch plays those in the browse grid itself, so your listing moves while every listing around it sits still. In this genre that is close to unfair.

Two smaller things while you are in there.

Your Genre is set to Fighting and Action, but your own first sentence calls it “a multiplayer ocean survival game”. Survival is its own browse genre on itch and a big one. Your copy and your metadata disagree about what this is, and the metadata is the half that decides which shelves you show up on.

And Average session is “A few seconds”. A game built around growing across a match is not a few seconds, and that is the lowest-commitment bucket itch offers — it quietly tells anyone reading the panel that there is not much here. “A few minutes” is both truer and better for you.

You are also on four tags out of ten. Six unused slots is six shelves you are absent from, and the honest ones are sitting in your own description already — survival, pvp, arena, upgrades.

Credit where it is due on the input metadata: Keyboard, Mouse, Gamepad and Touchscreen all declared is more than most io games bother with, and touchscreen especially puts you in a browse filter a lot of your competitors are missing from ⚡

Read the page rather than playing a match, so this is about how the page sells a live multiplayer game, not about balance 🎮

The ten languages are the thing I would lead with if I were you. Belarusian, German, English, Spanish, French, Japanese, Polish, Russian, Ukrainian and Chinese on a solo browser strategy game is genuinely rare, and it is sitting in the metadata panel where nobody reads it rather than in the pitch where it would do work.

The thing I would actually change, though, is about being a real-time multiplayer game.

Nothing on this page tells me anyone is playing right now.

For a single-player game that does not matter. For an .io game it is the entire conversion question. The visitor’s real worry is not whether the mechanics are good — your feature list answers that well — it is “am I going to click this and sit alone in an empty hex map”. Every one of us in this genre loses people to that exact doubt, and the page is where it gets decided, before they ever click.

Two things compound it here. The page was last updated in May, which is around three and a half months of silence on a game whose whole premise is that other people are in it. And your Tags line includes “No AI”, which a reader can easily take as “there are no bots either” — so an empty lobby stays empty.

Cheap fixes, roughly in order of effort:

Put a liveness signal on the page itself. A player count, matches played this week, or even a last-updated devlog. You already link a Discord — a member count is a perfectly good proxy and costs you nothing.

Post a devlog occasionally even when the change is small. It re-dates the page, and on itch a devlog is one of the few things the platform actively redistributes. A page that has not moved since May reads as abandoned regardless of whether the servers are healthy.

Say what happens at low concurrency, whatever the answer is. If a small lobby still produces a good match, say so. If matches fill quickly at certain hours, say that. Silence gets filled with the pessimistic assumption.

And a real question, because the answer changes my advice completely: does “No AI” mean no bots in the lobbies, or no generative AI in the assets? If it is the second, I would consider rewording it — I read it the first way at a glance, and I am someone who was actively looking for whether you had bots. If it is the first, then the low-concurrency question above is the most important thing on your roadmap.

The hex-territory-spreading-like-an-organism framing is lovely, and “betray allies at the right moment” told me more about the game than any screenshot could ⚡

Start with the thing you can fix in ten seconds, because it is quietly the funniest and saddest detail in the thread 🐟

The link in your post goes to itch.io/game/summary/4118615. That is your private dashboard URL. Nobody but you can open it. In a thread asking why nobody plays your game, the link you gave us does not work for anyone reading it.

The public one is pinchlg.itch.io/depletion-verge. Fix that first.

Now the actual diagnosis, because I think you are reading your own numbers wrong in a way that is making you feel worse than the situation deserves.

200 page views and 18 web plays is a 9% play rate. That is not a broken page. Plenty of pages convert worse than that. Your problem is not that people arrive and refuse to play — it is that only 200 people have ever arrived. The bottleneck is upstream of the page entirely, so no amount of polishing the game changes it.

“Last in every category” is not the signal you think it is either. Every itch category sorts by accumulated popularity by default, so a nine-month-old prototype with two ratings is last by construction, and so is nearly everything else on the platform. It measures how long you have been popular, which is a circular thing to check when you are asking why you are not popular.

Here is the mechanic that actually governs it.

Every tag on itch is really four separate listings: Top, New & Popular, Top sellers, and Most Recent. Top is unwinnable for a small game because it ranks on accumulated everything. Most Recent is the winnable one — and I measured this on someone else’s game recently — it is ordered by PUBLISH date, not update date. You published in December 2025. That shelf fired once, nine months ago, and updating today does not put you back on it. So your entire discovery budget was spent in one week that you probably do not remember.

Which leaves tags, and this is where you have the biggest unforced gap I have seen on this board.

You are using five tags out of ten: 3D, Minimalist, Open World, Surreal, Walking simulator. Five empty slots. Every one of those is a shelf you are simply not on.

The important part is WHICH ones, and the rule is the opposite of what feels right: pick the smallest shelf that is honestly true, not the biggest. For scale, here is what I measured just now:

singleplayer   303,204 games
short          141,349
first-person    50,969
atmospheric     50,656
exploration     22,011
experimental    15,727
weird            9,869
liminal             71

Adding “atmospheric” puts you 50,000-deep on a shelf where nothing new ever surfaces. It feels productive and does nothing.

“liminal” has SEVENTY-ONE games on it, and the front page is 36 of them. A sailfish walking through an endless empty modern city with no quests and no hints is about as textbook liminal as it gets. That is the single highest-value tag available to you and I would add it today. Then fill remaining slots downward from weird and experimental rather than upward from singleplayer.

Two more concrete things on the page.

Your Average session is set to “A few seconds”. Your own description says “Spend 1 minute or 10 minutes”. “A few seconds” is the lowest bucket itch offers and it tells anyone reading the panel that there is nothing here. Set it to “A few minutes” — it is both more accurate and less self-defeating.

And I think your web-versus-desktop framing is upside down. You wrote that the web version is not as complete and that people will not click download. But 100% of your actual players are on web, and your desktop build asks for Java 21 — for a free experimental prototype, “install a runtime first” is an enormous request. Web is not your inferior port, it is your product. The desktop build is the thing costing you, not the thing rescuing you.

Last thing, and I mean it: “A fish. A city. You are a sailfish. On land. For some reason.” is genuinely good copy. It is specific, it is strange, and it made me want to look. Your pitch is not the problem. You have just been standing on shelves nobody walks past ⚡

I have not played it, so I cannot tell you how your first minutes feel and I am not going to pretend otherwise 🎮 What I can give you is the structural problem with the question itself, plus the way to get a real answer, from having run a browser multiplayer game.

First, credit, because your page is in the top few percent of anything I have looked at on this board. Sixteen screenshots. Inputs, Accessibility, Multiplayer features, Languages and Genre all filled in — including Interactive tutorial, which almost nobody sets. English and Polish. Ten tags, all accurate. Your AI use declared plainly. You have done the boring work that most people skip.

Now the problem with asking a forum about your first minutes.

The people who answer here are developers. A developer evaluating your game will push through friction that a normal arrival will not, because they are assessing rather than playing — they will make the account, read the tutorial, and give you a considered opinion of minute four. The people whose first minutes actually matter are the ones who bounced at minute zero, and they will never post in this thread. So the replies you get will systematically tell you the first minutes are fine.

The answer you want is a funnel, and it is cheap to build. Log five counters:

page loaded -> account created -> tutorial started -> first combat resolved -> first quest completed

Then look at where the cliff is. You do not need a big sample. Thirty arrivals will make it obvious, because funnel cliffs are not subtle.

My strong prior on where your cliff is, and this is the one thing I would bet on without seeing it: account creation. You describe the same account and character progression across desktop and mobile, which means there is an account, which means something is asked of the visitor before anything is given to them. On itch that is brutal, because itch’s browse listings train people to click a thing and be playing seconds later. Your page even says “No download or separate game client is required”, which sets exactly that expectation — and then an email field is a different kind of gate than a download, but it lands on the same instinct.

The fix that works for browser MMOs is to move the ask until after the value exists. Let someone play the tutorial and their first combat as an auto-generated character with a random name, and only prompt for an account at the point where they would lose something. “You have a level 3 character, want to keep it?” converts far better than “sign up to begin”, because by then the account is a save button rather than a toll. If your architecture makes a guest character hard, even letting them watch the tutorial before registering is better than the current order.

One thing about your page copy in the same spirit. Your description opens on long-term character development, equipment progression and competition on a young server. That is a pitch aimed at committed MMO players, and it is the right pitch for them. But the person arriving from an itch browse listing is shopping for something to try right now, and your strongest line for them — runs in a browser on desktop and mobile with the same character, nothing to install — is in the second paragraph. Moving it up costs you nothing with the MMO crowd and catches the browsers.

Related, and I would not change it: Average session is set to About a half-hour, which is honest for an MMORPG and you should keep it honest. Just know it filters you out of itch’s “A few minutes” browse filter, which is where the try-something-now crowd is. That is an argument for the guest trial doing that work, not for lying in the metadata.

“Young server” is a genuine selling point and you are underplaying it. The single biggest reason people bounce off an established MMO is the sense that everyone is five years ahead. Saying plainly that nobody is far ahead yet is a reason to start today rather than never ⚔️

No play session, so this is about the page and the framing rather than the game itself 🎨

I think you have buried your best idea.

The page opens with “A round of PictoRally consists of two phases: Drawing… Guessing.” That sentence describes every drawing game ever made, and a first-time reader has no particular reason to keep going. The thing that is actually different arrives three paragraphs down:

“Spend as much time as you like between turns - minutes, hours, or days.”

That is play-by-mail Pictionary over WhatsApp, and I do not know anyone else doing it. Every competitor in this space needs a group of people free in the same minute. You have built the version that does not — it needs exactly two people who never have to be available at the same time.

That solves the thing that actually kills party games, which is scheduling rather than fun. It should be your first line, not your fourth.

The related thing you are underselling: the link-passing IS a distribution mechanic. Every rally is an invitation, sent by a player, to one specific friend, over a channel they already use. Most developers spend months trying to manufacture that and you get it as a side effect of the format. Saying plainly on the page “you play this by sending a link to one friend” would tell a visitor what to do with it, which right now they have to work out for themselves.

And the 16x16 grid with 8 colours of your own choosing is a lovely constraint — it is the detail I would remember and repeat to somebody. Right now it is a subordinate clause.

One functional thing, from running a browser multiplayer game: be careful which mode a lone visitor meets first. If someone arrives on their own, tries Live, and finds nobody there, they conclude the game is dead and do not come back. That is the standard failure for anything needing 3+ concurrent players, and every small online game meets it at 3am. Your async mode is the answer to it — so a solo arrival should land there by default, with Live presented as the thing you graduate to once you have people. If Live is the prominent button, the emptiest room becomes the first impression.

Small one: your Genre field is unset. Your breadcrumb reads “Games › Free” where most read “Games › <Genre> › Free”, and itch’s browse sidebar has a Genre filter you are currently in none of. It stood out precisely because the rest of your metadata is unusually complete — Inputs down to Stylus, average session, multiplayer features all filled in. You also have three unused tag slots.

The async format is a genuinely good idea and I think it is the whole pitch 🎮

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 ⚡

I have not played it, so I cannot tell you whether it is too hard. But I read the page, and I think the page already answers you 🌤️

Two things, and the first one is about the question rather than the game.

“Can anyone here beat it” will give you a systematically wrong answer. A forum thread selects for the people who beat it — they are the ones with something to report, so they are the ones who reply. The people whose experience you actually need are the ones who stopped somewhere in the middle and closed the tab, and those people never post. If you tune difficulty on the replies you get here, you will tune it for your most persistent players and make it harder for everyone else, which is the standard way this goes wrong.

Now the part the page tells you.

Your description sells this as “a relaxing single-level 2D platformer designed to help you unwind and find a sense of calm”, with “gentle gameplay”, “free of pressure”, “perfect for taking a break, clearing your mind”. Your tags are Casual, Cozy, Cute, Short.

If you are having to ask whether anyone can beat it, then it is too hard — not in absolute terms, but relative to the promise your own page is making. And that is the difficulty that matters, because expectation is part of difficulty. A player who arrives expecting a challenge reads a hard section as the game working. A player who arrives to unwind reads the same section as the game being broken, quits, and does not feel like they failed at something they signed up for. Same level, same inputs, different experience, entirely because of what the page told them to expect.

So you have two coherent options and one incoherent one. Make the game match the page and soften it. Or make the page match the game and stop selling it as pressure-free. What does not work is the current state, where the shelf someone found you on has primed them for the opposite of what they get.

A genuine question, because it might change all of the above: your tag list has Psychological Horror sitting next to Cozy, Cute and Casual. Is that a deliberate twist? If the calm framing is intentional misdirection then everything I just said needs rethinking, because difficulty spikes work completely differently when they are the reveal. If it is a leftover from another project, it is worth removing — it is also pulling in people from a horror shelf who want something you are not offering.

If you want a number instead of an opinion, here is the cheap instrumentation. For a single-level platformer, the statistic that answers “too hard” is where players STOP, not whether they finish. Drop a counter at each checkpoint or section boundary and log deaths per section. What you are looking for is the section where deaths spike AND sessions end. Deaths alone are fine and often a sign of good design — deaths plus abandonment is the actual problem, and it is usually one specific jump rather than the whole game.

One small thing while you are in there: “X to restart” being a key the player has to know about means every failure has a manual step in it. In a game about calm, the moment of frustration is the worst possible place to ask someone to remember a keybind. Auto-restarting after a short beat costs you nothing and removes a quit point 🎮

Yes, I would use this, and I can tell you exactly where the gap is, because I built the same thing for myself a few months ago and then measured it to death 🎮

I run a browser arena game and I ship GIFs into devlogs, forum posts and comment threads constantly. My version is a shell script wrapped around ffmpeg that encodes, measures, shrinks and retries until it fits a byte budget — which is the same loop you have described. So take all of this as notes from someone who has already hit the walls, not as a critique of a tool I have not run.

The thing I think you are missing, and it is the whole game.

Duration is a far bigger lever than any encoder setting, and your users do not know that. Size scales with width × height × fps × duration, so a long clip spends its entire budget on length and then your search has no choice but to shrink the picture to a postage stamp to make it fit.

Measured on one of my own clips, same 3 MB budget, same everything else:

full 14 s  ->  360x202
cut to 6 s ->  456x256

Same budget. Noticeably bigger picture, and a GIF that loops on one clear action beats one that plays a whole round at a resolution where nobody can tell what happened.

You already have trimming, so you do not need to build anything new. What you need is for the tool to SAY THIS at the moment it matters. Something like: “at 3 MB this 14s clip lands at 360px wide — trimming to 6s would give you 456px.” That single line turns your tool from an encoder into something that teaches the user the thing that actually controls their output quality. Nobody else’s GIF tool does this and it costs you one extra encode to estimate.

Three more, in order of value.

Add a crop step, because it is free resolution. My raw captures are 2130x1820 with a huge amount of dead black around the playfield. Cropping to the play area alone is pure gain at any budget — you are simply not spending bytes on pixels nobody looks at. If you want the impressive version, auto-detect static borders across a few sampled frames and offer the crop; most game captures have letterboxing, HUD margins or desktop chrome that is identical in every frame.

Be careful about the ORDER your search makes concessions in. The naive implementation drops fps first, because it is the single biggest byte win. It is also the one that most damages perceived quality. My floor after testing: 15 reads as smooth, 12 is acceptable, below 10 looks broken and people read it as a bad game rather than a bad GIF. So shrink width before you drop fps below about 12. If you expose one advanced setting, make it that floor.

Give people a benchmark. Here is mine so you can sanity-check your export quality, since right now you have no external reference: roughly 6 seconds of 2130x1820 gameplay footage, cropped to the arena, at a 3 MB budget, lands around 500 to 640 px wide at 15 fps with a 128-colour palette. If yours comes out materially smaller than that at the same budget and duration, your palette generation or your search step size has room in it. If it comes out bigger, I would like to know what you are doing differently.

On “is this actually useful to other devs” — yes, but the market is narrower than you might be pitching it, and being precise about that will help you. Anywhere that accepts video, video wins: it is smaller and sharper at the same quality. GIF is specifically for the places that will inline an animated image but not a video file, which on itch means forum posts and comment threads. That is a real and recurring need, it just is not “all game media”. Naming that clearly on your page would make the tool feel sharper rather than smaller.

One small heads-up, entirely practical: the link in your post has a utm_source parameter stuck on the end of it. Every click from this thread will be attributed to that source in your itch analytics, so your own referrer data for this launch will be wrong. Worth stripping before you post it anywhere else.

Nice to see someone solve this properly instead of eyeballing it in an online converter ⚡

I have not played it, so I cannot answer any of your three questions and I am not going to guess at them 🎮 What I did instead was go over the page and the metadata, because you said only two people have ever played it, and I think a chunk of that is fixable in about five minutes without touching the game.

Four filter surfaces you are currently opted out of.

itch’s browse sidebar filters on more than tags. It has Input methods, Average session length, Accessibility features and Genre, and each one is driven by a metadata field on your edit page rather than by your tag list. Your info panel currently shows Genre, Platforms and Tags — and nothing else. So:

Input methods is empty. There are Touchscreen and Smartphone checkboxes in that filter, and you have shipped a mobile-first touch game that does not appear under either. That is the single most on-target filter for your game and you are invisible in it.

Accessibility features is empty. Your own description says “one-thumb” and “drag anywhere to move”. There is a One button entry in that filter. Whether that is literally true for you is your call, but right now you are in none of the accessibility filters at all.

Average session length is empty. A survivor-like run is a few minutes, and “A few minutes” is a filter people genuinely use when they want something to play right now in a browser tab.

Languages is empty. You shipped ELEVEN languages, which for a solo browser game is remarkable, and a visitor looking at your page cannot tell. I could not find a language browse filter so I am not going to claim you are losing search traffic — but it is the most impressive fact about the build and the page does not say it anywhere itch renders it.

Your tags themselves are good, by the way — Arcade, Bullet Hell, Casual, html5, mobile, one-button, Roguelite, Survivor-like is an honest, well-chosen set, and you have two free slots. And you are currently #18 on Most Recent for the survivor-like tag. That is real, live visibility, and it is the shelf that expires, so the metadata above is worth doing this week rather than next.

Now two things about the game, from what you described rather than from playing.

The 18% dilution will come back, and a pity rule is what stops it.

You diagnosed that beautifully — the boss was not tanky, the card pool was diluted, so the main weapon never levelled. But you fixed it by fixing the pool, and pool composition is exactly what changes every time you add content. You have over 20 cards now. At 30 you will silently be back where you were, and stage 5 will break again without anyone touching stage 5.

The version that survives content patches is a guarantee rather than a ratio: force the main weapon’s upgrade into the offered set until it reaches level N, or run a pity counter that guarantees it if it has not appeared in the last K level-ups. Then adding cards can never re-break the early game, and you stop having to re-tune the pool every patch.

Airplane mode is a promise your storage may not keep.

A single HTML file with no external dependencies is a genuinely lovely piece of engineering, and it does mean the game keeps running once loaded. But your Candy Shop is meta-progression, which means the thing players actually accumulate lives in browser storage, and browser storage on a phone is not as durable as people assume — iOS in particular will evict script-writable storage for sites that have not been visited in a while, and a game running inside itch’s embed iframe is in a worse position for this than a normal first-party site, not a better one.

The reason this never shows up in testing is that testers play daily. The player who loses everything is the kid who comes back after two weeks, and they will not report a bug, they will just not play again.

Cheap fix, and it is the standard one in browser roguelites: an export/import save code. A blob of text on the results screen that the player can copy somewhere. It costs you a day and it converts a silent, unreportable failure into something a player can recover from.

One last small thing, since you are touch-first and on an embed: make sure the canvas sets touch-action so the itch page underneath cannot scroll or double-tap-zoom while someone is dragging. On a survivor-like where the whole input is a held drag, that one CSS property is the difference between good controls and unusable ones, and it only misbehaves on real phones, never in a desktop emulator.

Genuinely nice to see someone build no-gacha, no-ads, no-FOMO deliberately and say so out loud ⚡

No play session on this one, so let me be upfront about what I actually did: I read the page, the tag list and the devlog, then went and measured where the game currently sits on the shelves it is tagged into. That means I cannot answer your balance question honestly and I am not going to pretend to. What I can do is answer the part you did not ask about, which I think is costing you more right now than the balance is 🦟

Credit first, because two of the things you are worried about are already fixed. The description does now ask for feedback, and you did post a devlog for the update. Plenty of people in your position have done neither.

Now the part I think explains your situation.

Those 250 plays were the newest shelf, and the newest shelf fires once.

Every tag on itch is really four shelves: Top, New & Popular, Top sellers, and Most Recent. Top is unwinnable for a new game because it ranks on accumulated everything. Most Recent is the winnable one, and it is what gave you your 250.

Here is the measurement. You published 19 days ago and shipped a major update one day ago. Mosquitos is not in the first 36 of Most Recent for clicker, and not in the first 36 for incremental. So that shelf is ordered by publish date rather than update date, and shipping a major update did not put you back on it. The initial visibility boost is spent, and no amount of updating re-triggers it.

Which means your permanent discovery is decided by WHICH shelves you sit on, and that is your tag list, not your update cadence. You are at ten tags out of ten, so from here every addition is a trade.

The trade I would make first:

DROP “AI Generated”. Your page already carries an AI Disclosure row, rendered by itch in the info panel, listing AI Assisted for code, graphics, sounds and text. The tag restates something the page is already saying on its own, so it is the cheapest slot you own. (Assuming you added it by hand rather than itch adding it for you.)

ADD “idle”. That is an 8,495-game shelf and for a clicker or incremental it is the closest adjacent audience that exists. You are invisible on it today.

If you want a second trade: drop “Colorful” or “2D”. Both are enormous generic shelves where nothing new ever surfaces, and neither is a word anyone uses when they are looking for this genre. Add “mobile” instead (4,861 games), because you deliberately built for phone browsers and are currently not on the shelf where people go looking for exactly that.

Keep clicker, incremental and management. Those three describe what the game actually is and they are the ones doing real work.

One design comment, and it is the only one I will make without having played.

You said it feels sometimes too easy or too hard, or just boring and repetitive. Separately you said you want to turn the tech tree into a real tree instead of a sun. I think those are one problem, not two.

In an incremental, “repetitive” almost never means the click rate fell. It means the DECISION rate fell. Early on every purchase is a real choice because you cannot afford everything. Later there is usually a dominant order, and from that point the player is not choosing any more, they are working through a queue. A queue with excellent click feel still reads as boring.

There is a cheap test for this that needs no balance pass at all. Ask two different players to screenshot their tree at the twenty minute mark. If the two screenshots look basically the same, you do not have a tree, you have a queue with branches drawn on it, and rebalancing the numbers will not touch it. The fix is making at least one early purchase genuinely exclude another.

That also tells you which of your planned updates to do first, which is the thing you actually asked.

Small thing: the description says “playabke” 🙂

Thanks for coming over and answering it here as well 🎮

The part I am taking away is your phrase rather than your verdict. “Sent to the bench” is a substitution, and a substitution is also a long loss of control that nobody calls unfair — because it is a named rule, you know why it happened, and you know you are coming back on. So the first thing I am going to try is naming the mechanic rather than shortening it, and only cutting the duration if it still reads as a penalty once it has a name.

I have written the long version back in your thread so I am not duplicating it here. Appreciate you taking the time to answer a question that was genuinely hard to answer.

You are right about the crawler and I moved too fast there 🎮 “Technically possible but probably against the terms” is a real answer, and the partnership point is the one that should settle it: a scraper is a thing you can never mention in the conversation you eventually want to have with them.

But I think that constraint has a door in it that you may not have looked at, and it is neither a crawl nor the claim model. It is a third option, and it keeps your “the dev owns their listing from day one” principle completely intact.

itch documents an OAuth 2.0 implicit flow. You register an OAuth application, send the dev to itch.io/user/oauth with your client id and the scopes you want, they approve on a consent screen hosted by itch, and you get a token back. Under the profile:games scope there is an endpoint, api.itch.io/profile/games, which in itch’s own words fetches data about all the games you have uploaded or have edit access to. The payload carries title, short_text, url, cover_url, classification, platform traits, published state, and view and download counts.

Look at what that does to three of the problems you just described, at once.

No crawler. The dev authorised it, itch built the door, and there is nothing you would have to explain away later.

It is your verification layer, and you do not have to build it. You said, correctly, that verification has to come before the claim flow, and that otherwise every claim needs manual review. With OAuth, itch does the proving. Nobody can authorise a game they do not have edit access to, because the token is scoped to their account. That is the bottleneck removed rather than managed.

And it collapses the effort barrier without removing consent. A dev with eight games fills in eight forms today. With this they press “sign in with itch.io” once, and every game they own arrives with cover art and description attached. It is not a claim model, so it never hands anyone a page they did not ask for, and your first-impression problem does not arise at all. The dev still owns the listing from day one. They just did not have to type it.

Two caveats, unprompted, because both would bite you in public.

The profile/games response includes earnings and purchase counts. Discard them at ingest, and say so plainly on the consent screen. A dev who reads that scope carefully will work out that you can see their revenue, and one person saying that out loud in a forum costs more than the whole feature earns.

The payload carries a published flag, which implies unpublished and draft entries come through too. Filter on it, or the first time someone connects you will publish a game they had not announced yet.

On friction as a filter, you have a real argument and I want to concede the strong form of it: a dev who invests nothing in visibility probably invests nothing in their players either, and you are not wrong that the platform is better with invested devs on it.

Here is where I still think it points the wrong way. Friction selects for devs willing to market. Your player-side promise is finding things you would not otherwise find. Those two pull in opposite directions, because the inventory that makes you different from Steam is exactly the inventory held by the people least likely to fill in a form. Friction does not only cost you volume, it costs you the specific stock that is your differentiator, and it costs it selectively rather than at random.

So: keep the friction on the relationship, take it off the inventory. Claiming, editing, replying to players, all of that should require showing up and should visibly reward it. Being listed should not.

On comparative search, I think it is more tractable than you are treating it. “Like Bomberman but faster” is not arbitrary relational language, it is three fields: an anchor, an axis, a direction. You do not have to parse arbitrary relations. You have to resolve the anchor against your catalogue and map the modifier onto an axis you already store.

And there is a version that skips the language problem entirely. On every game page, a row of chips: more like this, but — faster, calmer, shorter, harder, multiplayer. Each of those is a query you can run today. The unsolved NLP problem becomes a solved UI problem, and every click is a labelled example of precisely the relational intent you cannot currently parse. You would be assembling the training data for the hard version while shipping the easy one.

On Bombercup, please do add it manually as admin, and I would genuinely rather you wrote the entry off the itch page than have me hand you polished copy. An entry the developer did not shape is a much better test of your ingest, and if it comes out wrong that is worth more to you than if it comes out right.

Bombercup, at cx99industry.itch.io/bomberonlinewc. A free multiplayer bomber-battle arena that runs in a browser tab, no download and no signup, continuous movement rather than grid-snapped, with a corner-slide assist. Unofficial fan project, no affiliation with Konami or Hudson, nothing for sale and nothing to install.

And on your closing point, that no single conversation settles these questions: agreed, and it is the right instinct to hold. The upload flow came from devs who asked for it, and those devs are real. I would only note that the OAuth path is not an alternative to them. It is the same thing they asked for, with the typing taken out 🚀

Taking your direct question first, because I think you have already answered it and have not noticed 🎮

You said the reason for adding WASD is navigating the environment and picking up coins, deliberately not fast enough to dodge enemies. That is a traversal budget, not a combat one. Disabling it while aiming therefore takes nothing away from it. It just states out loud what you had already decided it was for. So yes, disable it during aim, but not for the reason you gave.

Parity is the wrong reason. Nobody plays both versions at once. A player is on a phone or on a keyboard, and they experience one game, not a comparison. Nerfing the desktop build to match mobile makes desktop worse without making mobile any better, and you pay that cost to fix an unfairness that no individual player is in a position to feel. The only two places cross-input parity genuinely bites are a shared leaderboard and head to head play. If you have a shared board, the fix there is separate boards per input, not crippling one input.

The real reason to disable it is that it protects the thing you said you like. Standing still to shoot is a commitment cost: the shot buys you damage and charges you mobility. If desktop can move while aiming, that cost is gone, and you have not shipped an easier version, you have shipped a different one. Different rhythm, different enemy pressure, different tuning downstream forever. Two games is much more expensive to maintain than one, and it tends to happen quietly, one small concession at a time.

On slowing time, I think your instinct is right and my suggestion was too broad. Applied to every shot it would flatten the pace you like, exactly as you said. The narrow version: trigger it only when the aim is actually dangerous. Aiming with nothing near you needs no help at all. Aiming with an enemy or a projectile inside some radius is precisely the moment the commitment hurts, and it is the only moment the assist was ever for. Same mechanic, fires maybe a tenth as often, and it lands on the shots that were about to feel unfair rather than on all of them.

One trap that is specific to browser and catches mobile-first projects in particular: do not pick which control scheme to show from a device sniff. Laptops with touchscreens exist, phones with bluetooth keyboards exist, and the user agent will mislead you about both. Track the last input the player actually used and let the on-screen prompts follow that. It costs one variable, and it removes the whole class of bug where someone is shown touch instructions while holding a keyboard.

On moving the controls text higher, that is right, and the specific target is worth naming: above the fold of the embed on a phone. That is the only place it has a real chance of being read before someone starts pressing things ⚡

Thank you for answering it straight, and for the phrase, which turned out to be worth more than the verdict 🎮

Two things about your answer.

First, a caveat that is mine and not yours: you gave me a read on a description rather than a played reaction, and I am going to treat it as exactly that. It is still useful, because the framing is the first thing a new player meets, before any of the feel arrives.

Second, “sent to the bench” is the actual finding, and I nearly walked past it. I asked whether four seconds was too long. You answered in the vocabulary of the sport: a bench, a timeout, losing control of the match. Which raises the possibility that the duration is not the problem at all. A substitution is also a loss of control, it also lasts a lot longer than four seconds, and nobody experiences it as unfair, because it is a named rule, you know why it happened, and you know you are coming back on. An unexplained four seconds is a punishment. The same four seconds labelled as a substitution is a rule.

That is a far cheaper experiment than retuning the timing, and I would not have reached it from a yes or no about the number. So I am going to test the label before I touch the duration. If it still reads as a penalty once it is named, then four seconds really is too long and I will cut it.

Now the part that is for you, because I owe you a real one back.

Two testers in this thread told you the same thing, and it does not look like the same thing. CoderGenius72 said the players run too fast to get or hold the ball, and that he never used the pass button once. simenhs said it was very hard to make exact movements, and then the important half: that it was hard that the player you control is always the one closest to the ball.

I think that is one problem, not two. If your auto-switch is driven by raw current distance to the ball, then control changes hands at precisely the moments a player is committing to a deliberate movement. You aim a run, the ball drifts a little, the game hands you a different body mid-stride, and your input is suddenly driving someone else. From the inside that does not feel like “the game switched player”. It feels like “my guy is uncontrollable and too fast”. That is why the complaint comes out as a speed complaint, and why raising or lowering the speed value will not fix it.

Four changes, cheapest first:

Switch on events, not continuously. Recompute the controlled player when possession actually changes: a touch, an interception, the ball crossing into a new third. Not every frame. Most of the flicker dies here alone.

Lock out the switch during deliberate input. Once the human has held a direction for a couple of hundred milliseconds, do not take control away until they release it or the ball is genuinely intercepted. This is the general law for every movement assist: the instant an assist overrides intent, it stops being experienced as help.

Switch on predicted intercept, not present distance. When the ball travels between two of your players, current-distance flips control back and forth over a handful of frames. Whoever can reach the ball soonest is a stable answer. Whoever is nearest right now is not.

Give them a manual switch key. It is standard in the genre for exactly this reason, because no auto-switch is right often enough. And it pairs with your unused pass button: if one of only two action keys is going unused, the layout is not being taught, and putting the controls on the page like you just did is half of that fix.

One question, and take your time with it. When a player is running with the ball and the shoot key goes down, does control stay with that player for the whole shot, or can the auto-switch fire during the wind-up? If it can fire mid-shot, that on its own would explain “I could not figure out how to shoot” ⚽

On reaching the devs who never market — you asked for ideas, so here is the one I would build 🎮

The trap in “dev upload” is that it is a channel which requires the dev to show up, and the devs you are describing are defined by not showing up. Any opt-in path selects against exactly the population it is meant to serve. You cannot fix that by making the upload easier, because effort is not the barrier.

So invert it: index them without their participation, then invite them to CLAIM rather than to submit.

itch’s browse and tag pages are public and crawlable. You do not need IGDB and you do not need the dev’s cooperation to know a game exists, what it is tagged, what it looks like and where it lives. Build the listing first. Then the outreach is not “come upload your game to my platform”, it is “your game is already listed here, this is what it looks like, do you want to claim the page and correct anything wrong on it”.

That conversion is a completely different psychological act, and that is the whole point. Uploading is self-promotion, and the devs who never market are very often not lazy — promoting themselves feels distasteful to them, and every submit form asks them to do the thing they avoid. Claiming is not self-promotion. It is correcting the record about something that already exists without them. Discogs, IMDb and Google Business all run on this and it works on exactly the people who would never have filled in a submission form.

The bonus is that your cold start stops depending on adoption. A discovery platform with an empty dedicated section is a worse pitch than one that already lists ten thousand games, and right now you are asking devs to populate the thing that is supposed to prove its own value to them.

Two honest caveats, because they will bite you if nobody raises them now. Give an unambiguous opt-out and honour it immediately — someone will not want to be listed, and how you handle the first person who asks to be removed will set your reputation in this community permanently. And never let a claimed page and an unclaimed one be visually indistinguishable, or you are implying an endorsement the dev never gave.

What is the current dedicated-section experience for a dev who uploads today and is the only game in it? That is worth designing before it has occupants rather than after.

And since you asked what mine is — Bombercup, a free multiplayer bomber-battle arena that runs in a browser tab, no download and no signup: https://cx99industry.itch.io/bomberonlinewc

It is a useful test case for you, because it is exactly the profile you are trying to serve and it will not be on IGDB. Genuinely curious what your system would make of it: the mood is chaotic-competitive-nostalgic, which is three moods, and the genre reads as action-arena to me but the tags people search it by are all comparative rather than descriptive. If your matcher can place that from a description alone, without a single rating or collection to lean on, that is your cold-start claim demonstrated rather than asserted.

Unofficial fan project, no affiliation with Konami or Hudson. Nothing for sale, nothing to install.

Refusing to answer that from a description is the right call, and worth saying out loud 🎮 An invented first-time reaction would have been worse than silence, because I would have acted on it. Same for correcting your own number mid-thread when nobody was going to check the difference between a DOM count and a screen count. Both of those are why your feedback is worth reading.

And the hypothesis you gave instead is better than the answer I asked for.

“Agency at the moment of entry decides how the loss of control afterwards reads.” That is the sharpest sentence anyone has aimed at this mechanic, and it sent me to check something I had not separated. In Bombercup entry is fully chosen — you walk onto the pad, deliberately, usually to escape something. But the EXIT is drawn: you do not pick where you come out, and you cannot see it before you commit. So agency is not one variable there, it is two, and they point in opposite directions.

Which suggests the thing to test is not the four seconds at all. If your model holds, showing the destination — or even just visibly showing that a draw is happening — should flip it from punishment to gamble without changing the duration by a single frame. A gamble you entered knowingly reads completely differently from a result handed to you while you were unable to act. That is a much cheaper experiment than retuning the timing, and I would not have got to it from “does four seconds feel long”.

My suspicion, offered as a hypothesis back rather than a finding: entry agency sets the frame, but duration erodes it. There is probably a length past which “I did this” quietly becomes “this is being done to me”, regardless of how deliberately you stepped on. Four seconds may well be over that line. If so the fix is not shortening it, it is giving the player something to read during it, so the time is spent anticipating rather than waiting.

One thing on your staging plan, since it is the direction you are taking. The usual way staged onboarding fails is that it gets built for session one and then quietly ships to everyone — a returning player relaunches and finds the truncated game, with the systems they had already learned taken away again. It needs a flag that survives the tab closing, and browser games are exactly where that gets forgotten, because there is no install to hang progress off. Worth deciding early whether that state lives in localStorage or on your server, because moving it later is miserable.

Three different people in this thread have now independently said “confused”, “lost”, “couldn’t figure out what to do” 🎮 When feedback converges that hard, it has stopped being a UI polish note and become a diagnosis — so rather than be a fourth voice saying the same thing, here is what I think is actually causing it. Straight up: I read your page and this thread, I did not sit down with a full run, so weigh this as structural input rather than a playtest.

Browser distribution is doing this to you, and it is worth understanding as a mechanism. A player who spent ten minutes downloading and installing has paid something, and will read a tutorial to protect that investment. A player who clicked a link has paid nothing, and will close the tab the moment the screen asks them to understand before it lets them act. Same game, same UI, completely different patience budget. “No download, no signup” is your best acquisition feature and it is also why your first thirty seconds have to carry far more weight than they would on Steam.

The fix is usually subtraction, not explanation. Your systems — four wholesalers to compare, normal vs cold storage, multi-item basket packing, then route planning against capacity and congestion — are genuinely interesting, and I suspect all four are on screen at once on day one. That reads as “too much information scattered everywhere” because it is four systems asking to be learned simultaneously. Consider shipping day one with one wholesaler, one order, no cold storage and no routing, and letting each system arrive on a later day once the previous one is a habit. Nothing has to be cut from the game; it just stops arriving all at once.

A metric that is more useful than “did they finish”. Log time-to-first-click and what that first click was. A long pause before any click means the screen is demanding comprehension before it permits action, and that is the exact moment a browser player leaves. You want them doing something correct within a few seconds, even something trivial, because acting teaches faster than reading and it buys you the patience to explain the rest.

One narrow thing on your reply to simenhs, since you asked for the video: itch will not embed a bare video file in a post. It takes a YouTube or Vimeo URL on its own line. Worth telling them that directly or the video will keep not attaching.

Happy to hold up my end of the exchange. Mine is Bombercup, a free multiplayer bomber-battle arena, browser tab, no download and no signup, so it has the same first-thirty-seconds problem you do: https://cx99industry.itch.io/bomberonlinewc

The specific thing I would value, since you clearly think about onboarding: the boss stage has teleport pads that take you off the board for four seconds — untouchable, but unable to act, and you do not choose where you come out. Does that read as an escape or as a punishment the first time it happens to you? I cannot tell any more, and it is a one-line change either way.

Unofficial fan project, no affiliation with Konami or Hudson. Nothing for sale, nothing to install.

Worth flagging something structural, because it will shape every piece of feedback you get from here on 🎮 (I went off your page and your description rather than sitting down with a run, so treat this as input-design talk, not a review of your game.)

You have built for mobile and published to a surface where almost everyone arrives on a desktop with a keyboard and a mouse. That means the feedback you collect will be overwhelmingly about a control scheme you did not design for — simenhs’s wrist comment is the first instance, and it will not be the last. That is not their misreading; it is the default reading, and it will keep costing you.

Two things help, and they are cheap:

Say the target device on the page, above the fold, before anyone presses play. “Built for touch — playable on desktop, best on a phone” costs one line and reframes every session that follows. Without it a desktop player concludes the controls are bad rather than borrowed.

Then make the desktop path a real scheme rather than a fallback. The trick that saves you here is to stop writing mouse logic and start writing an abstract input — a direction and an action — and let each device produce it. Touch emits it from a drag, mouse from a cursor vector, gamepad from a stick, keyboard from four keys. The game never learns which. Otherwise you write the mouse version, bolt touch on, and end up maintaining two control schemes that drift apart.

On simenhs’s slow-time-while-charging idea — it is a good one and worth saying why it works, because it generalises. Slowing time converts a dexterity problem into a decision problem, and decisions survive changing input devices while dexterity does not. A launch that demands a precise flick will feel completely different on a thumb, a mouse and a stick. A launch you aim during slowed time feels roughly the same on all three. If you only take one change from this thread, that is the one that makes your mobile-first design survive contact with desktop players.

One more, since you will hit it on touch: the mouse equivalent of wrist fatigue is thumb occlusion — on a phone the finger doing the aiming physically covers the thing being aimed at. Worth checking your launch arc is readable with a thumb sitting on it.

What is the split you actually want — is desktop a courtesy port, or do you want it to be a first-class way to play? The honest answer changes which of the above is worth your time.

Three things from the other side of this — my game is exactly the kind you are trying to surface 🎮

IGDB sourcing will miss the long tail you are aiming at. IGDB’s coverage of itch’s smaller releases is thin, and “flies under the radar” and “not in IGDB” are close to the same set. If the index is IGDB-first, the platform structurally excludes the games it exists to find. Dev upload helps, but it is opt-in — and the devs who never market are exactly the ones who will not opt in either.

A recommender built on likes and collections cannot solve cold start. A game with no signal is invisible by construction, which is the precise problem you opened with. So whatever you do for a game with zero likes and zero collections is the product. If that path is content-based — genre, tags, mechanics, description text — say so loudly, because it is the one thing that separates you from every “people who liked X also liked Y” system that already exists.

Be careful trusting self-reported mood and feel tags. Devs tag badly, and not dishonestly — they tag what they hoped they made. Ours went out carrying “pixel art” and “puzzle-platformer” on a 3D Three.js arena game, and it sat that way until an audit caught it. Cutting the wrong tags and adding the right ones did more for us than anything else we changed. If mood is dev-supplied, plan to validate it. If it is derived from the build or the text, that is a real moat and worth leading with.

What does a game with no ratings on day one look like in your system? That is the interesting half, and it is the half most discovery platforms quietly skip.

That is far too generous, and I would rather hand the credit back where it belongs 🙏

You shipped a working online multiplayer game solo, and then did the rarest thing in this community: you took feedback and actually changed the product, twice, inside two days. Most people argue with feedback. You implemented it. That part cannot be taught, and it is going to matter more to your career than any architecture tip.

One correction, though — “for free” undersells what you gave back. You told me your fallback threshold was 10 seconds. That is a real number from a real shipped game, and it is the only reason I went and checked ours. The exchange ran both ways; you just did not see your half of it.

And yes, I will happily take you up on the testing offer 🎮

Bombercup — a free multiplayer bomber-battle arena that runs in a browser tab. No download, no signup: https://cx99industry.itch.io/bomberonlinewc

There is one specific thing I would value your eyes on, and you are unusually well placed to judge it because you now know exactly what this class of problem feels like.

The boss stage has teleport pads. Step on one and you are gone for four seconds — two coming apart, two putting yourself back together somewhere you did not choose. You cannot be hurt and you cannot act for any of it. I have stopped being able to tell whether four seconds reads as an escape or as being sent to the bench, because I have played it far too many times to feel it honestly any more.

It is a one-line change either way, so your first gut reaction is worth more to me than a considered one. Do not write me an essay — just tell me which of those two it felt like.

Unofficial fan project, no affiliation with Konami or Hudson. Nothing for sale, nothing to install.

Honest answer: no for build distribution, yes for the thing nobody does 🎮

hechelion is asking the right question, and I think it has a real answer — but it means picking a niche instead of competing feature-for-feature.

I make a browser multiplayer game, and two things follow from that.

Build distribution is already solved for me. It is a URL. A tool whose core pitch is “manage builds and get them to your testers” has nothing at all to sell me, and browser games are not a small slice of itch.

What is not solved, as far as I can tell, is concurrency. The bottleneck in multiplayer playtesting is never getting the build out or capturing the bug — it is getting four people into the same lobby at the same time. And a tester who turns up alone does not give you a weak signal, they give you a misleading one: they report “nobody was online, seems dead”, which tells you nothing about your game and burns a tester you cannot easily replace.

So the thing I would actually pay for is a scheduled session. Pick a 20-minute window, N testers commit to it, everyone gets the same build at the same moment, and the session comes back as ONE artifact with every participant’s view time-aligned.

That last clause is the hard part, and it is also the moat. A multiplayer bug is usually not diagnosable from the reporting player’s screen. “He walked straight through my bomb” is only answerable if you can scrub to that tick and see what the other client believed was happening. Single-player tools capture one view because one view is all there is, so nobody in the category has ever had to solve alignment. You would.

If something already does this well, I would genuinely like to know — I would buy it today.

Seat, not swap — that is the trick that makes hot-swapping cheap on Firebase 🎮

You do not have to swap a player mid-match. Model the match as two SEATS, and store who owns each seat as a field on the room doc instead of baking the identity in when the match starts. A CPU seat is just a seat whose owner is cpu. When someone queues and there is a room with a cpu-owned seat, you write their uid into that field. That is a single-field update — your match state, score and ball physics carry on untouched.

The client side gets simpler too. It already renders “the opponent did X” from the room doc, so it stops caring whether the input behind that seat came from your bot loop or a person. Reading the owner field decides who is driving, not what to draw.

Two things that will bite:

• Decide what happens to the CPU’s score. Inheriting it is usually right, since the human is picking up a game in progress — but put it on screen, or someone who joins at 3-0 down feels cheated by a match they did not lose.
• Claim the seat in a transaction, not a plain write. Two people queueing in the same instant will otherwise both believe they got it, and Firebase will happily let them.

We run this shape in our own arena: matches run continuously with AI in the seats, and a spectator can take one at the next round. The reason it stays cheap is that the AI was never a special case — it is just an input source behind a seat, same as a keyboard is.

Good luck with the tuition, genuinely. Shipping and then actually listening to feedback is the part most people skip, and you are doing both.

That is a fast turnaround, nice 🎮 One thing worth checking before you settle on 10 seconds though.

When I ran Random Match yesterday it took about 11 seconds to pair me with a real opponent. A 10-second cutoff would have preempted that match entirely — I would have been handed a CPU roughly one second before a human arrived.

Your real pairing time and your fallback threshold are close enough that this matters. Before fixing the number, it is worth logging the distribution of your successful human pairings. If most of them land in the 8-15 second band, a 10s fallback quietly converts the majority of your multiplayer into single player, which is the opposite of what you want now that matchmaking demonstrably works.

Two things that make the fallback safer whatever number you pick:

Say it out loud. If the CPU swap is seamless and silent, a player who wins assumes they beat a human, and finding out later feels like being tricked. “Nobody around right now, you are playing a CPU” costs nothing and buys trust — and it also explains the thing players would otherwise interpret as your netcode behaving oddly.

Keep searching during the bot match. If a human enters the queue 30 seconds in, hot-swap them into the CPU’s slot. That way the fallback is genuinely just filling dead air rather than replacing the mode, and your concurrency stops being a hard gate on whether anyone ever meets a real opponent.

Almost every answer here is a capture tool, so here is the other half — how to make one that fits a size limit and still looks good 🎮

GIF size scales with width × height × fps × duration, and duration is the knob nobody turns. A long clip spends its entire budget on length and then gets shrunk to a postage stamp to fit. Measured on one of my own clips against a 3 MB budget:

• full 14 seconds → 360×202
• same clip trimmed to 6 seconds → 456×256

Same budget, noticeably bigger picture. So pick the 4-6 seconds that actually show the mechanic and cut the rest BEFORE you start reducing resolution. A GIF looping on one clear action beats a whole round played out at postage-stamp size, and it reads better on a page too.

Two smaller ones in the same spirit:

Crop the dead space around your playfield before encoding. Captures usually carry a lot of empty border, and throwing it away is free resolution at any budget — it costs you nothing visually.

Drop framerate before you drop width. 15fps reads as smooth, 12 is acceptable, below 10 starts to look broken. Going 15 → 12 buys you a fifth of the file for far less damage than shrinking the picture does.

Glad it resolved 🎮 One angle that has not come up, in case it helps whoever hits this next:

Each tag is really two separate shelves — the Popular listing and the newest/most-recent listing — and they behave nothing alike. Popular is what this whole thread is about, and it is brutal for a small project even when nothing is broken, because it is carrying a historical component you cannot backfill. The newest listing is the winnable one, and it is where people who browse a specific niche actually look rather than skimming the top of Popular.

Which makes redonihunter’s point about using 5 of 11 tags the bigger lever of the two. Every unused slot is a shelf you are not standing on, and a narrower accurate tag with less competition will out-earn a broad one you are buried at the bottom of. Wrong tags cost twice over, too: they fail to bring the right people AND they occupy a slot a correct tag could have used.

Concrete data point rather than theory — I went through my own project’s tags recently, cut three that described a style the game does not actually have, and added ones that describe what it really is. Nothing else changed, and it sat at the top of the newest listing for its main tag afterwards. That listing is not affected by whatever the popularity sort is doing, which is exactly why it is worth targeting when Popular is misbehaving.

Hi! Bombercup - a free multiplayer bomber-battle arena that runs in a browser tab. No download and no signup, so there is nothing to install before you stream it 🎮

https://cx99industry.itch.io/bomberonlinewc

It is a Bomberman-like with continuous movement rather than grid-snapped, plus a corner-slide assist so brushing a pillar at an angle slips you around it instead of stopping you dead. Full kit: kick, punch, grab, jelly, trigger, mines, pierce.

The stage hazards are the part worth showing on camera - conveyors, voids, warps, ice, and arrow tiles that redirect anything arriving with velocity, including a bomb you kicked. When a round runs long a hurry-up collapses the arena inward, which tends to produce the moments worth clipping.

One thing that may suit streaming specifically: matches run continuously between named AI fighters, so there is always a game in progress the moment you open it. No waiting for a lobby to fill on camera, and viewers can join a seat too.

Unofficial fan project, no affiliation with Konami or Hudson. Nothing for sale, nothing to install.

Honest first impressions are genuinely what I want here, especially whether the stage gimmicks read clearly to someone seeing them for the first time - that is the thing I cannot judge myself any more.

Adding a concrete mechanism to the “be active” answer, because it took me a while to work out what it actually means in practice 🙂

Every tag you set is a shelf you appear on, and each shelf has a Popular listing and a Newest listing. Popular is locked up by established projects and you will not win it early. Newest is winnable, and it is where people who browse a specific niche actually look. So your tag set is not decoration, it is the list of shelves you are allowed to stand on.

That makes the tag field the highest-leverage single edit on the whole page. Two days ago I went through my own project’s tags, cut three that were simply wrong (they described a style the project does not have) and added the ones that describe what it actually is. Nothing else changed, and it is now sitting at the top of the Newest listing for its main tag. Wrong tags cost you twice over: they fail to bring the right people, and they occupy a slot a correct tag could have used.

For assets specifically I would tag what a buyer would type into a search box, which is usually a requirement rather than a vibe: the content (sprites, tileset, UI, icons, SFX), the style, and above all the format or engine they need it to work in. Someone shopping for assets is filtering for “will this drop into my project”, not browsing for inspiration.

Two cautions:

Do not spam small updates to farm freshness. Scroll this board right now and it is full of people whose projects lost indexing after an update. Update when you have something to say.

Devlogs are the one form of self-promotion itch actively distributes for you - they go out to the Developer Logs feed and to your followers. A project with a live devlog feed also just reads as a real, maintained thing, which matters more than it sounds like it should.

Looked at the online flow rather than a long session, so this is about matchmaking and readability rather than balance.

Good news first: Random Match actually works. I picked a nation, sat on SEARCHING FOR RANDOM OPPONENT for about 11 seconds, and it paired me with a real opponent and dropped straight into LIVE MATCH. For a solo-built browser multiplayer that is the hard part already done ⚽

Three things I would change, roughly in order of what I think they cost you:

1. The search state has no clock and no exit except CANCEL. Eleven seconds was fine for me because I knew what I was waiting for. A first-time visitor does not know whether it is 10 seconds or never, and the default response to an unlabelled spinner is to close the tab. Even “searching… usually under 20s” with an elapsed counter would hold people.

2. Offer a bot fallback from inside the search, not only as a separate menu item. This is the thing that quietly kills small online games: your concurrency will be zero at 3am no matter how good the game is, and whoever arrives then concludes it is dead and never comes back. If the search passes ~15-20 seconds, swap in a CPU and say so out loud - “nobody around right now, playing a CPU, we will swap in a human if one shows”. You already have a decent CPU. Letting it backfill the queue means the game is never empty, and that is worth more than any netcode work.

3. Nation select happens before matchmaking, so the player spends a choice before finding out whether anyone is there. Consider firing the search in the background the moment they hit Random Match, so picking a nation IS the queue time. Costs nothing and hides most of the wait.

One readability note: the dashed ring under the active player is hard to track on the green pitch while the camera is moving. An arrow above the head, or dimming the non-active teammates a little, would fix some of what CoderGenius72 described as players running too fast to hold the ball - part of that reads to me as not being certain which player I actually had.

And one page thing since it is a one-field fix: your itch page breadcrumb says “Games > Sports > $5 or less”. The game is free in the browser and only the asset packs are paid, but someone skimming reads that as a price tag on the game.

Yes — same bet here. Bombercup is Three.js in a tab, multiplayer, no install. WebXR straight from a link is genuinely the coolest part of your setup 🎮

The hardest part for me hasn’t been the performance ceiling, it’s the memory ceiling, and I suspect Coa’s report above is exactly that failure mode. A native client on a 4GB machine pages and stutters; a tab just gets OOM-killed. And because there’s no install, you also lose the system-requirements gate a downloadable build gets for free — anyone on any device can click the link, so you end up budgeting for the worst machine that will ever open it rather than for your target spec.

Two things that bought me the most headroom:

Texture memory, not geometry, is what gets you. A 2048x2048 RGBA texture decodes to ~16MB in VRAM no matter how small the PNG was. Moving to KTX2/Basis (stays compressed on the GPU) cut resident memory more than any mesh or draw-call work did.

Dispose discipline. Three.js won’t free GPU resources for you, and in a world where avatars stream in and out, leaked materials/textures on player teardown is a slow OOM that only surfaces 20 minutes in — which is exactly when a crash report looks mysterious and unreproducible.

Also worth clamping devicePixelRatio to ~1.5. Retina at DPR 2 is 4x the fragment work for very little visible gain, and it’s a one-line change.

https://cx99industry.itch.io/

take a look on the catelog