itch.io

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

Hi. I’m a game developer and a student, based in Germany, and most weeks those two jobs argue about who gets the evening.

I grew up on Bomberman. A grid, soft bricks, two seconds of fuse, and four people on one couch discovering exactly how petty they can be — that is still, to me, the most honest multiplayer ever designed. Everything is on screen. No hidden information, no unfair angle. If you die, you walked into it, and everybody watching knows you did. The series taught me that a game does not need depth in its systems so much as depth in the decisions it forces, and I have been chasing that feeling in my own work ever since.

Outside the maze, I collect. Trading games and card collections are the other half of my shelf: binders, sleeves, and a completely unreasonable memory for which set a card came from. I like the economy of them — the negotiating, the slow assembly of something complete, the fact that a collection is a project with no deadline. And I play a lot of puzzle games. Falling blocks, tile matches, logic grids, anything that hands me one clean rule and then asks how well I actually understood it.

That mix is not an accident. A Bomberman round is a puzzle you solve while it is trying to kill you, a card collection is a puzzle you solve over years, and building games is a puzzle where you write the rules and then find out what you really meant by them.

What I care about as a developer: readable rules, fair deaths, and a game that is fun in the first minute and still interesting in the hundredth.

If you play any of that, or make any of it, I would like to hear from you.

https://www.youtube.com/watch?v=Z8hb4xp6Yao&list=RDZ8hb4xp6Yao&start_radio=1

https://en.wikipedia.org/wiki/Witchblade_(2006_TV_series)

its a title.

is this the witchblade games concept?

its a very cool game concepts

how does it work well in graphic

how does it work

looking good

cool looking

cool animation

I’m developing a game that’s not out(or anounced) but i would like you to play one of my games:h https://cx99industry.itch.io/

recently working on this https://cx99industry.itch.io/bomberonlinewc

BOMBERMAN Online World Cup Edition update the landing page; https://cx99industry.itch.io/bomberonlinewc

Hello! I've spent a long time loving Bomberman — the living-room chaos, the kick that goes wrong, the round where you farm too greedily and gift someone a free kill. Atomic Bomberman on PC especially stuck with me: continuous movement, punch/grab/jelly/trigger, a kit that rewards reading the board instead of memorizing one grid pattern.

Anyone who's gone deep on that genre knows the wall you hit when you try to remake the feel: the bombs have to slide right, chains have to feel instantaneous, and the stages can't be empty rectangles forever. Soft bricks, powerups, diseases, conveyors, voids — it all has to stay legible when four people are panicking at once.

So I built something to play with that feeling again.

https://cx99industry.itch.io/bombermangenz

Bomberman Online (Bomberman World Cup 2026) is a free, fan-made browser Bomberman — not an official Hudson / Konami / Nintendo release. Matches are already running between named AI fighters when you open the site. You can watch a round, take a seat, or create a room and fill it with bots. Last bomber standing, classic kit (kick, punch, grab, jelly, trigger, spooge), plus authored stages with conveyors, warps, ice, rails, revenge carts, and a denser item layer (mines, pierce, hearts, Louie, Fireball kick).

Mechanically it's short sessions: a match is a few minutes; a useful playtest is maybe 15–30 minutes across a handful of rounds. Solo vs Easy bots is totally fine if you just want to learn the fuse and the corner-slide. 2–4 humans is ideal when you want to judge fairness.

I'm mainly looking for honest reactions right now:

- Does Fireball + Kick (bomb slides through soft bricks) feel like a fair delivery, or too mean when someone is camping behind cover?

- Do carts / rails / hurry-up feel confusing or cheap anywhere?

- If you're new: where did the kit or the stage gimmicks stop making sense?

All of that is genuinely more useful than compliments right now.

It's free to try in the browser — no download, no account. Early build energy still applies: things might not behave like you expect. If a bomb stops early, a cart skips a stop, or something feels wrong, comment with the map name and what you pressed. Thank you!

If you want to help, just reply here or leave a note on the game page after a short session. Looking forward to your feedback!

the old entry point is outdated. We will use the new one

hint: fullbloodangle

find the secret dialog and enter it.

find the secret dialog

hint: showboobka

what else?

New portal for the latest game release: https://liluo.io/jobjobhk/gg-summer-watch

interesting

amazing design game.

show me the mac version. I go test it out!

why there is no mac version?

Now also available in gamejolt

https://gamejolt.com/games/alienkiller/786168

I tested the working version in mac.  The ball easily fall into the dead hole. I guess its a bad skill.. Overall runs smooth. I tested around 3 mins. Its fine so far.

ok, I go take a look