Game releases and on-site information

News of a game update does not immediately reveal where it can be played. Information at remote or less-visited arcades could remain outdated, and official sites did not always identify a location’s current installation version. Filling that gap became a priority for Musecat.

The earlier version-check screen allows confirming the installed version or reverting it to the previous value. Original English capture.

Operators cannot visit every location. For example, a visitor checking a machine still listed under an older version should be able to contribute what they found without a separate report later being copied into the document.

Version transitions therefore became campaigns with defined periods and targets. Contributors check installations that still need confirmation, reporting whether the old version remains or the update is installed. XP rewards participation, adding on-site verification to the existing level system.

flowchart TD
    accTitle: Deriving targets and rechecking on submission
    accDescr: Apply version and cabinet-country scope to current public installations and recheck eligibility when confirming.
    C["Version transition and scope"] --> T["Find targets in current public games"]
    T --> U["User checks current conditions"]
    U --> V{"Still eligible on submission"}
    V -->|"Yes"| S["Process confirmation"]
    V -->|"No"| E["Conflict or no eligible target"]

Campaign scope and submission checks

A campaign specifies a version transition and cabinet and country scope. Targets come from current installations at public, operating arcades, rather than a fixed list of business names. Compatibility with the next version is checked too.

sequenceDiagram
    accTitle: Atomic update confirmation
    accDescr: After target and visit checks commit game changes confirmation and XP in one transaction.
    participant U as Confirming user
    participant A as Campaign API
    participant D as Database
    U->>A: Confirm update
    A->>D: Begin transaction and recheck target
    A->>D: Check visit conditions
    A->>D: Create next game state and history if needed
    A->>D: Commit confirmation and XP together
    A-->>U: Current state and contribution feedback

A target may change while a visitor has the screen open. The campaign might end or the installation might be removed. On submission, the server rechecks the campaign period, installation existence and arcade and cabinet scope, returning a conflict or missing-target response when appropriate.

On-site checks and installation updates

A verified visit on the same day is the normal trust signal. Authorized roles may have a location exception, but campaign and target validation still apply. Confirming the old version adds a confirmation; finding the update creates a game state with that installation moved to the next version.

flowchart TD
    accTitle: Preventing duplicate campaign rewards
    accDescr: Check the award kind for the user and campaign installation and update the total and ledger only for a first award.
    R["Check reward eligibility"] --> K["Determine user and award kind"]
    K --> H{"Award already recorded"}
    H -->|"Yes"| N["Keep XP total"]
    H -->|"No"| T["Save award record and total together"]
    T --> L["Calculate level and contribution feedback"]

Game state, history, confirmation and XP commit together. This avoids awarding a reward without its associated information or losing the contributor’s identity. Award types are stored for each user, campaign and installation, so repeating a confirmation does not repeatedly increase XP. Additional confirmation and additional reward are evaluated separately.

Campaign progress and further verification

Once confirmations update game state, visitors can find updated installations and operators can identify unchecked targets. Progress and confirmation history can be reviewed without reconciling a separate report list against documents.

This does not guarantee every location is current. Incorrect checks require corrections and further evidence; campaign expiry and location changes still affect eligibility. Rewards encourage participation while retaining the checks and editing paths needed to revise a finding.

Related articles and sources: level system · Musecat engineering notes