whats4dinnergame

A time-management cooking puzzle! Food influencers turn recipes into custom playable levels, engaging followers in a brand new way. Fans play the dish to see who tops the leaderboard!

Comment

Inspiration

Food is the one thing every online platform — and every household — has in common. Recipe videos dominate feeds, food subreddits never sleep, and yet the question that actually rules our evenings is mundane and universal: what's for dinner? We wanted to bottle that shared obsession into something playable: not a cooking-reflex game, but the real puzzle home cooks solve every night — several hungry people, different cravings, one pair of hands, and everything needs to land on the table hot at the same time.

The second spark was watching how food influencers/recipe creators engage their audiences. An influencer's recipe is usually something you watch. We wanted it to be something your followers attempt — and get scored on. So the heart of the project became UGC: any player can turn their own recipes into a challenge post, and their followers compete on its leaderboard.

What it does

What's for Dinner? is a cozy schedule-then-simulate cooking puzzle that runs entirely inside a Reddit post. You meet tonight's eaters — each craving a real dish, each with flavors they love and can't stand, each with a patience meter — then plan the cooking across your counter, stove, and oven, watch the kitchen run your plan, season every plate to its eater's taste, and face the verdict.

There are two ways to play:

  • Arcade mode — cook by cuisine. Pick one of 8 cuisine tracks (~163 preset dinners, every one validated beatable) and cook through it day by day; 60%+ unlocks the next day.
  • UGC mode — design your own dinner. Build your cast, bring your own recipes (paste any recipe as text and the importer turns it into playable steps), set the topping answer key, and publish it as a new post with your designer credit on it. Your followers chase the 100% on that post's leaderboard.

A scheduler also drops a shared "Tonight's Dinner" post every evening — a daily ritual with its own board.

How we built it

The game is a Devvit Web interactive post: a vanilla-JS, tap-first webview client and a zero-dependency Node server on Reddit's platform, with Redis for levels, leaderboards, and anonymous play counters.

Under the cozy surface sits an honest scheduling problem. A dinner compiles into steps with durations, stations, and precedence edges ("the glaze waits for the scald"). Hands-on steps serialize on the single cook; runs-alone steps (a pot simmering, a duck air-drying) overlap freely. Planning a dinner is minimizing the makespan

$$ \min\; C_{\max} \quad\text{s.t.}\quad s_j \ge s_i + d_i \;\;\forall\, (i \to j), $$

with single-cook capacity on hands-on steps and per-station lanes — a small job-shop cousin. When a designer publishes a dinner, the game solves it: greedy seeds, local improvement, then branch-and-bound over the real lane rules. The optimal play matters for fairness — each eater's patience default anchors to their completion time $C_e^{*}$ in that optimal schedule, so a designer literally cannot publish an unbeatable dinner: the preview step ships a constructive proof that a 100% play exists.

Taste is the other half of the score. Each dish has a topping answer key: the designer picks the 1–3 ideal toppings, and the compiler bakes a score for every subset of the pantry — $2^{|\mathcal{P}|}$ entries — so the exact set scores 100%, an empty plate rests at a 35% baseline, and wrong guesses cost. The verdict each eater delivers blends the two halves: did dinner land within their patience, and did the plate match their palate?

The UGC pipeline is deliberately paranoid: the server recompiles every design from its raw form and never trusts client-baked scores; each chef gets one live design slot; the OpenAI-backed importer turns pasted recipe text into steps so creators start from what they already have.

Challenges we ran into

Making optimality fast and friendly. Branch-and-bound in a browser, on a phone, inside a Reddit webview, has a frame budget. Aggressive pruning off the greedy incumbent keeps the solver interactive, and surfacing its result as a gentle "best possible play" timeline (rather than math) took more iterations than the solver itself.

Designing for taps, not drags. Early versions leaned on drag-and-drop — mobile webviews punish it. Everything became tap-first: steps schedule with a tap, reordering uses up/down controls, and dependencies travel by stable step id so reordering can never corrupt a recipe.

Trusting creators without trusting clients. UGC in posts means hostile inputs by default. The validation matrix, server-side recompilation, and the one-slot rule came from asking "what's the worst design a client could send?" until the answer was "nothing interesting."

The platform bundle. Devvit's runtime re-evaluates server bundles in ways that break dynamic require(); the fix — a zero-dependency server compiled to CJS with only static imports — was hard-won and then became a feature: the whole server is one small, reviewable file.

Content at scale. Hand-writing dinners doesn't scale to 8 cuisine tracks. We built an offline generator that assembles days from real dishes, then plays every one of them through the same simulator the client uses, regenerating until each day is provably passable.

Accomplishments that we're proud of

  • Every published dinner is provably beatable. Publishing requires the solver to exhibit a 100% play — an existence proof, not a promise. No one can troll followers with an impossible level, by construction.
  • A real optimizer, invisible to players. A branch-and-bound scheduler runs interactively on phones, and players only ever feel it as fairness.
  • The full creator loop shipped. Paste a recipe → it becomes steps → the game schedules the perfect cook → pick the answer key → one tap publishes a post your followers compete on, with your credit on the verdict screen.
  • Privacy by construction. Play data never leaves Reddit — the app keeps a few anonymous counters a day, and nothing else.

What we learned

  • Platform fit beats fidelity. We first ported a full 3D kitchen; the winners on Reddit are tap-first 2D casual games, and the 2D rebuild was both more fun and dramatically more shippable. Killing the prettier version was the right call.
  • Constraints are architecture. A sandboxed webview, an allowlisted server, and a human review process pushed us toward server-side recompiles, anonymous integer counters, and privacy by construction — all things the project is better for.
  • Real math can hide in cozy games. Players never see $C_{\max}$, but the fairness they feel — "someone beat this dinner, so I can too" — is a scheduling theorem wearing an apron.
  • Creators need proof, not promises. The single most important design decision was making publishability constructive: the designer watches the 100% play exist before the post goes live. Every UGC system should ship its own existence proof.

What's next for whats4dinnergame

  • Public launch. The app is submitted for Reddit's review; once approved, we take the daily-dinner ritual and creator mode beyond the dev subreddit and into food communities.
  • The companion site and 3D prospect. whats4dinnergame.com adds creator accounts, photo uploads for dishes and eaters, and a personal chef page at whats4dinnergame.com/{username} — so an influencer's dinner has a home on and off Reddit, with shared leaderboards. It also has a 3D Kitchen edition in development.
  • Marketing and events with the food communities When it's connected to the community, led by influencers, many things can happen. Themed weeks, holiday dinners, and community recipe collections built from the best UGC designs.

Built With

Share this project:

Updates