Astro Diner Developer Journal

Design target

Astro Diner is aimed at short, readable arcade sessions. The diner should feel playful, but the core rules must stay clear: read the ticket, build the plate, serve before patience expires, and use the result screen to improve.

The design avoids making progression depend on accounts, chat, or external social systems. The current route is local, single-player, and focused on the serving loop.

Why the reference pages exist

A playable game page alone can be hard for crawlers and reviewers to understand, especially when the main client is rendered by JavaScript. The reference pages explain the game with regular HTML, stable headings, and internal links.

These pages are not filler. Each one maps to a real area of the game: worlds, recipes, aliens, scoring, upgrades, missions, saves, accessibility, and support.

Quality constraints

The site does not add ad containers inside the active game surface during recovery work. It also keeps review-only pages out of the sitemap with noindex,nofollow metadata.

Validation checks the sitemap, inventory, page metadata, canonical links, last-updated text, noindex behavior, internal links, and absence of ad slots around gameplay controls.

Current product boundary

The current public product is a browser game with released campaign shifts, a diner hub, local save portability, static reference pages, and support/trust pages. It is not a multiplayer service, account system, or ad-heavy portal.

That boundary keeps the site honest. Future changes should keep the same standard: document what actually exists, verify the game still works, and avoid pretending the product is larger than it is.

Journal review examples

The developer journal explains why the site has both a playable React game and static HTML references. The game gives the live experience; the references make mechanics inspectable for players, families, crawlers, and reviewers.

The journal also defines the product boundary. Astro Diner is currently a local-save browser arcade game with generated shifts and static support pages. Calling out that boundary is a quality choice because it prevents roadmap language from being mistaken for shipped functionality.

That is why the journal talks about validation and page design as part of the product. If the game is playable but the site cannot explain itself in crawlable HTML, families, players, and reviewers all get a weaker experience.