These notes document the decisions behind shipped cabinets and shared game technology. They are based on Dingcade's live rules and project records, not generic arcade articles.
Published by EFANCY LLC. Dates mark the documented release or the publication of the engineering note.
Authored Astral Atlas backglass artwork; live condition lamps render separately in the cabinet.
Machine design
Astral Atlas separates physical coverage from its condition table
The observatory cabinet asks players to read two related but different displays across one sixteen-ball session.
Astral Atlas begins by revealing one or two numbered slot lamps and one separate First Light target. Every ball still uses the shared manual plunger. As the sixteen balls land, the physical slot bank records which lanes have been covered; a repeat remains a real landing but does not create a new covered slot.
The 4×4 panel on the backglass is intentionally not a map of those lanes. It is a condition table evaluated after the session, while First Light can be completed only by the first ball. Keeping physical evidence, condition progress, and the one-ball target visually distinct was the central information-design problem for this cabinet.
Authored Tidal Twins backglass artwork for the Abyss Glow cabinet identity.
Machine design
Tidal Twins turns eight launches into one readable collection story
A server-selected opening pattern and two mascot tracks make a longer session legible without hiding the physical landings.
START selects three to five unique cells before the first pearl is armed. Those lamps are visible immediately and already count toward the collection. The player then launches eight pearls manually; several can be moving at once, but the slot each pearl visibly enters remains its recorded physical result.
Odd-numbered cells belong to Moon Jelly and even-numbered cells to Sun Ray. New cells advance their corresponding tracks, while repeats stay visible in the physical count without pretending to add collection progress. That split lets the cabinet communicate start state, eight live launches, two goals, and a final result within one persistent hardware language.
Authored Studio Neon backglass artwork representing one layer of the browser-rendered cabinet.
Browser engineering
Why Dingcade keeps Full and Lite rendering paths
A browser cabinet needs a graceful quality ladder because visual capability and stable play are not the same thing.
Dingcade renders a 3D cabinet, moving marble bodies, authored materials, lighting, particles, audio, and machine-specific hardware in the browser. Devices vary widely, and a successful WebGL start does not guarantee that every visual layer will remain smooth through a long multi-ball session.
The shared player therefore owns a Full/Lite quality ladder and recovery notices rather than letting each machine invent its own fallback. Lite reduces presentation cost while preserving the cabinet rules and visible result path. The design priority is continuity and honest feedback: a quality change should protect the session, not silently replace the game with unrelated content.
