Free browser demo, no download, no signup: https://rldgamesstudio.itch.io/shelves-and-streets

WHAT IT IS

You run a corner shop and its delivery arm. Before opening you compare four wholesalers, catch the rotating deals, fill normal and cold storage, and pack multi-item baskets for the orders you accepted. Then you plan the runs: combine nearby customers, respect scooter and van capacity, avoid congested streets, and send each vehicle out. The vehicle drives the actual street network, so the order you combine customers in genuinely costs you fuel, customer patience and store rating.

There is no timer during preparation. The shop opens when you say it is ready. The pressure comes from your plan being wrong, not from a countdown.

WHAT I WOULD LIKE FEEDBACK ON, in order of how much it helps me

1. The first five minutes. It is a guided first shift with a character walking you through it. Does it explain enough, or does it explain too much before letting you touch anything?

2. The route screen. That is the actual game, and it is also the part most at risk of reading as busywork. Did combining stops feel like a decision, or like clicking?

3. Where you stopped. If you closed the tab, the sentence "I quit when ___" is worth more to me than any amount of praise.

HONEST FRAMING

This is a two-day demo of a game that is already out on iOS and Android, not a standalone free game. Day two is where the real dispatch desk opens, so the demo cuts after it rather than at the end of the tutorial. Store links are on the page; nothing in the browser build asks you for money. The art is generated with AI, which is declared on the game page as well. The code and the design are not.

THE EXCHANGE

Link yours and I will actually play it and write a real comment, not a one-liner. I did that for Dot Siege on this board earlier today if you want to see what you would get. Tell me what you specifically want looked at and I will focus there.

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

You can find my game her: https://simenhs.itch.io/hexatown  If you could record a video while playing it it would be very useful.

Thanks for playing it, and the honesty is worth more to me than praise would be.

First: your video did not attach. The post reads "Here is a video of me playing:" and then stops, no embed and no link. If you can get it up I would genuinely like to watch it. "Confused the whole time" is the most useful sentence anyone has sent me about this game, and watching where your hands actually go would tell me more than any description could.

And you did not miss something. You are the third person to say this, so it is the game, not you. After the second report I measured it: on day one, before you touch anything, the screen carries 110 text labels and 29 controls, and a quarter of those labels are just zeros and empty shelf slots. That is what "could not figure out what anything did" looks like from the inside. I am cutting it down rather than explaining it better.

On Hexatown, I owe you honesty. I could not give you a fair playthrough today and I cannot record video at all, so instead of inventing impressions here are two things I could actually measure.

Your web build is a debug export. The browser tab reads hexatown_worker_edition (DEBUG) - the internal working name and the debug flag both going out to players.

And it is heavy for what it is. index.wasm is 10.1 MB and index.pck is 513 KB, so a player waits on roughly 10.9 MB before anything happens, and about 95 percent of that is the Godot engine rather than your game. A release export instead of debug usually takes a serious bite out of that. For something described as a short incremental game of about thirty minutes, that download is currently the biggest thing between a curious person and your first tile.

Neither of those needs a playthrough to be worth fixing. I will come back with real play impressions once I can.

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.