Access, inclusion and accessibility
The barrier we removed first was the one nobody funds: needing an account.
Screen Australia asks how a project engages underserved audiences and reflects the values of the fund. Most answers to that question are about representation in content. Ours is mostly about who can physically get into the room, because a two-player game fails its second player far more often than it fails its first.
The account is the barrier
A two-player game asks a favour of somebody who did not choose it. Every step between the link and the kitchen is a place that person leaves.
So there is no login, no email, no password, no OAuth, no age gate, no launcher, no download and no install. A callsign, and you are in. The selfie is optional, taken on device, crushed to a 120×120 JPEG before it goes anywhere, and never required — the OS avatar set is a first-class choice, not a fallback.
This is a privacy position as much as an access one: the game cannot leak what it never collects. There is no account to breach and no identity to correlate. For a game that will be played by teenagers on shared machines, that is the responsible architecture, not a shortcut.
Hardware inclusion
Static files, one modest WebGL scene, and audio synthesised on device rather than downloaded. The build targets:
- a five-year-old Android phone on a slow connection
- a school or library machine with no install rights
- an old iPad, which is the most common second device in an Australian house
- a laptop with integrated graphics and a dying battery
Every one of those is a real player who is normally excluded by a 4 GB download and a launcher update.
Accessibility commitments
These are commitments for the funded build, testable and specific.
| Area | Commitment |
|---|---|
| Input | Every action has a keyboard path. The cook's bump bar is physical keys by design; the diner's drag-and-drop has a select-then-place keyboard equivalent. |
| Motor | No action requires a sustained hold, a double-click, or precision under 44 px. The hairdryer can be toggled instead of held. |
| Colour | No state is conveyed by colour alone. Cook stages carry a name and a silhouette; the rush timer carries a numeral. Palettes checked against protanopia, deuteranopia and tritanopia. |
| Contrast | WCAG 2.2 AA contrast for all HUD text. The CRT aesthetic is achieved with scanlines and bloom, never by lowering text contrast. |
| Audio | Every sound has a visual equivalent — the ticket chime, the scatter, the timer escalation. The game is fully playable muted. |
| Motion | prefers-reduced-motion removes camera shake, the CRT flicker and the scatter's chaos (the plate still clears; it just does not fly). |
| Text | No text baked into textures. Resizable to 200% without loss of function. Deadpan comedy is short-sentence comedy, which is also screen-reader friendly. |
| Time | Timers change colour and music. They never fail you, never end the shift, and never gate content. |
| Photosensitivity | No strobe above 3 Hz. The flashing red rush state pulses at 1.5 Hz, and can be turned off. |
Content and tone
The comedy is about work, not about people. Specifically off the table: jokes whose target is a person's body, accent, disability, or the fact of them being poor. The service worker is never the butt of the joke — the franchise is. This is a game made by people who have worked those jobs.
The absurdist register is deliberately non-verbal and non-cultural: a spider on a plate is funny in every language, which is also why the game needs almost no localisation to travel.
Team and pay
The team is small, freelance, and paid at or above the relevant Australian award and standard industry day rates, including the contract artist and the contract audio designer. Fair pay is in the budget as a line item, not as an aspiration — see 08-production-plan.