Imagine visiting an arcade for a listed game only to find that a broken button prevents play. The inventory may be correct, yet the information needed for the visit is incomplete. Delta introduced text reports for cabinet problems and on-site information, displayed at the top of the arcade page until resolved. Other visitors, as well as the author, can report that normal operation has returned.
Delta interface on 2025-07-01, reproduced from the legacy Gamma-Web source with a sample report. Unresolved issues appear first, at the top of the arcade page.
An inventory count describes installed cabinets. For example, reducing the count when one screen fails would eventually make the installation information itself wrong. We needed to communicate temporary problems while retaining the underlying inventory.
The earlier miscellaneous-information input sent operators information that did not fit other fields. Operators could review and apply it, but its role in warning the next visitor was unclear. We decided to display reports on the venue page and handle their resolution there as well.
The entry points became fault reports and user reports, inviting descriptions of cabinet problems or information worth sharing with other visitors. Users explain the game and cabinet number in prose. This stage does not provide photo attachments or a form with predefined faulty parts.
Report details from the same version connect the place, author and written issue. Synthetic sample data. Captured on the English route; this version kept ticket labels in Korean.
Reports are stored in userTicket, a ticket linked to the arcade. They retain the issue separately without overwriting installed games or prices. Submission from a venue screen also reduces the operator’s work of identifying an arcade from the message alone.
The detail page reads unresolved miscellaneous tickets for that venue: type ETC with status pending. Their cards show the message and creation time at the top of the page. Visitors can see problems without searching deep in a game list or an operator’s queue.
Resolved report status, using sample data with the 2025-07-01 code. Captured on the English route; this version kept ticket status labels in Korean.
Pressing the card’s resolved button asks for confirmation and updates the ticket to solved. A successful response refreshes the screen, removing it from the unresolved list. Resolution is not restricted to the author, allowing another visitor who checks normal operation to report it immediately.
Visitors can now see reported conditions alongside inventory. Reporting a fault no longer requires removing an installed game, and resolved reports leave the active notices. The flow connects a submitted description to a public warning and later resolution.
Users still need to describe cabinet names and positions accurately. The button depends on human checks, so a mistaken judgment can dismiss a report and stale information can remain. Text alone also cannot consistently identify cabinets and faulty parts. Operation needs to establish what further information reporting and resolution require.
Reference: Fault-report introduction commit.