The coast provides another place to meet potential customers as the afternoon turns into evening.
The city map connects neighbourhoods and trading locations, with Harbour Island visibly reserved for a future expansion.
The trading plan shows district activity, interested customers and visiting times to help decide where to go next.
Willing customers approach the bicycle seller and receive their samosa through an animated handover.
Students leave Vidya School while the surrounding homes and public library give the neighbourhood a daily rhythm.
A highlighted road route guides the rider toward a chosen selling destination.
The garden, fountain and neighbourhood visitors create another stop on the seller’s route.
The start screen introduces the Indian street-food setting and the journey from a small bicycle business.

Inspiration

I built Samosa Streets because I wanted to capture the raw, grounded reality of the Indian street-food hustle: starting with almost nothing, earning your dihadi one sale at a time, and slowly turning a bicycle basket into a permanent establishment. The colourful gallis, bicycle bell, neighbourhood crowds and hand-pulled thela are not merely visual details; they represent a journey familiar across Indian towns and cities.

As a simulation and management game, I wanted every constraint to tell that story of growth. Instead of simply clicking a menu and instantly owning a restaurant, the player must physically travel through the streets, carry limited stock, choose the right selling locations, serve individual customers, return home to deposit earnings and refill, and gradually invest in better equipment. The bicycle’s 25-samosa capacity makes every route meaningful, while customer cooldowns prevent repeatedly selling to the same people and encourage deeper exploration of the neighbourhood.

Upgrading to the thela changes more than the vehicle’s appearance. Its larger capacity and wider circle of influence shift the experience from chasing individual customers to strategically parking where crowds naturally gather. Progressing from the bicycle to the thela, food truck and finally a restaurant makes every sale feel like a genuine step towards stability.

Samosa Streets is my tribute to grassroots enterprise and the Indian street-food hustle: the physical effort, spatial strategy, inventory pressure and patient economic scaling behind the journey from a small bicycle setup to a permanent business.

What it does

Samosa Streets is a single-player 3D Simulation & Management web prototype. You begin on a bicycle, carry samosas, choose where to trade and park near potential customers. Willing buyers walk over to the seller themselves. A short handover animation completes before money changes hands; simply riding past someone does not force a purchase.

The first goal is to complete a 15-sale contract and fund another batch. You can bank earnings, buy ingredients, choose recipes and pricing policies, and progress through a pushcart, food truck and restaurant. Higher prices can improve the return on a sale, but customers have their own budgets and preferences.

The town includes a school, market, garden, offices, homes and a beach. Residents follow daily schedules, making location and timing part of the strategy. Road guidance and both maps highlight a selected destination. Pocket, Bank, Sold and contract progress keep the results visible.

How I built it

I prompt-built the prototype with Codex, describing changes, reviewing the result and asking for focused fixes. Three.js renders the world; HTML, CSS and JavaScript handle the interface, input and simulation. The existing img2threejs-derived development factories provided a starting point for procedural models, which were adapted and refined during development. Imagegen supplied artwork, including the title illustration.

Customer behaviour uses local rules, schedules, hunger, budgets and preferences. It does not call a generative AI service while the game runs. Web Audio produces music, ambience and effects, while localStorage keeps saves. Node.js tools prepare the build, and Playwright supports browser checks. The packaged runtime includes its libraries and assets locally.

Challenges I ran into

Selling needed several revisions. Initially, being close to someone felt too much like collecting a pickup. A later version made buyers approach but still required a confirmation button. I removed that extra step: parking now invites willing customers, and arrival starts the exchange. Cancellation and exactly-once payment still matter when the player moves away.

The city also had to work physically. Decorative buildings, signs and roads could look right while blocking movement or pointing the wrong way. I used collision checks and browser screenshots to catch those problems. Touch gestures, small-screen menus and different fullscreen behaviour required separate attention rather than assuming a desktop test covered phones.

Accomplishments I'm proud of

The business loop now connects decisions to visible consequences. Customers actually approach, receive food and leave; investing in larger equipment changes how service works. Garden and beach crowds create reasons to change routes. The bicycle bell, animated handovers and neighbourhood sounds help the streets feel active.

The management idea can be expressed conceptually as:

$$ \text{Profit} = \text{sales revenue} - \text{ingredient costs} - \text{operating costs} $$

That trade-off shaped the loop: every expansion needs enough stock and money to keep operating.

What I learned

Prompt-building still requires clear decisions and repeated playtesting. A feature being present is different from its behaviour making sense. Smaller requests, explicit acceptance checks and an honest build log made problems easier to isolate. I also learned to separate automated browser evidence from claims about real-device performance or how enjoyable the pacing feels to a new player.

What's next

I want to test with fresh players, tune early progression and pricing, and check physical phone and tablet performance. Harbour Island is visibly locked in this prototype; its businesses and routines are future work. I would develop that expansion after the existing neighbourhood loop feels clear and satisfying.