I played a 3 minute match and lost 2-3. This game has potential! However, my players currently run to fast to get or hold the ball. I would have to wait until the CPU is in front of their goal. I didn't use the pass button once. The "You lost" screen did not look right on mobile. 

The Gumroad link also does not work. However, almost no one will but AI-generated content, not even for $1. I can't even get one of my 500 players to buy or donate to me.

I gave a five star rate to help others find your game.

My game is: https://codergenius72.itch.io/dualspace

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.

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.

Hi, I played your game. Here is a video of it: 

I have also made a game and are looking for feedback. You can find it here: https://simenhs.itch.io/hexatown It would also be super helpful if you could make a video recording if you're going to play it.

interesting!

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 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.

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” ⚽

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 ⚽