Imagine visiting an arcade with a friend. One person wants a particular game and the other wants something else. Finding a venue with both requires checking game lists, then comparing addresses and travel distances. Searching for familiar venue names alone does not answer the question.

Musecat starts with this search problem. I plan to collect Korean arcade locations and installed games in one place, creating a website where choosing games leads to possible places to visit.

Information sources and comparison work

Wikis and official websites contain useful information, but their formats and update times differ. Checking games on one page, finding an address elsewhere and comparing distance on a map makes the visitor assemble the information themselves.

Conditions involving several games require repeating that work for each venue. Moving material onto one page is only part of the task. Places need to answer comparable questions before the service can reduce the comparison itself.

flowchart TD
    accTitle: The cost of comparing scattered information
    accDescr: Games and locations must be collected from multiple sources before comparing venues to visit.
    A["Wikis and official sites"] --> B
    B["Collect games and locations"] --> C
    C["Compare matching venues"]

Discovery organized around games

Game-based discovery starts with what someone wants to play instead of a venue already chosen. Two friends could select their games, inspect places meeting those conditions and choose one they can reach.

The first goal is to order matching arcades by distance. Starting in Korea should also provide a manageable area in which to check and improve the information directly.

flowchart TD
    accTitle: Starting from game requirements
    accDescr: The intended flow starts with choosing games, then compares candidate venues and distance.
    A["Choose wanted games"] --> B
    B["Arcades meeting the conditions"] --> C
    C["Candidates ordered by distance"]

Place and game data for comparison

Searching by game requires knowing which arcade has each game. A name and location identify the venue; its game list determines whether it is a candidate. Location also provides the basis for comparing distances.

Without these relationships, visitors would still have to match addresses to game lists themselves. Before expanding the interface, I plan to build an initial comparable list, entering confirmed information rather than filling gaps with assumptions.

flowchart TD
    accTitle: Preparing the first service
    accDescr: Prepare comparable data and a correction channel before considering the initial release.
    A["Organize arcade and game data"] --> B
    B["Channel for correcting errors"] --> C
    C["Prepare the initial release scope"]

Preparing the first list and correction channel

Collecting venue information once does not keep it accurate indefinitely. Games move and operating information changes, affecting results. A way for users to report mistakes needs to accompany the initial data.

The immediate work is to prepare a small usable scope in Korea and a process for applying correction requests. There are no release outcomes or user responses to report yet. First, the list needs to help people choose an actual place to visit.

Reference: Musecat engineering history.