How I Kept Two Different Fish Sort Games Out of One Guide

When a game title is generic, the hardest part of building a useful guide is often not writing the walkthrough. It is proving that every walkthrough belongs to the exact game and level the player has open.

I ran into this problem while organizing Fish Sort Puzzle material. The name is used by more than one game. A browser version can have different boards and numbering from a mobile app with a similar title. If those sources are merged into one library, a page can look complete while sending players to an incompatible solution.

Treat the game identity as data

The first step is to store the source game alongside every guide. A practical record can be as small as:

{
  "game": "Shycheese Android app",
  "level": 170,
  "videoId": "verified YouTube id",
  "visibleTitle": "Fish Sort Puzzle Level 170",
  "sourceChecked": true
}

The important field is not the level number. It is the combination of game identity, visible level title, and source identifier. Level 170 from one app is not automatically Level 170 from another.

For the browser game, the safest approach is to label it separately and say who distributes it. That prevents visitors from assuming that the mobile walkthrough library matches the playable web build.

Validate the mapping before publishing

For each walkthrough, I use a short checklist:

1. Confirm the level number appears in the source title.
2. Save the source video ID, not only the full URL.
3. Compare the opening board or visible landmarks when they are available.
4. Keep the game or package identity with the record.
5. Reject duplicate level numbers inside the same game library.

This catches the most damaging content errors: shifted numbering, duplicate videos, missing levels, and guides copied from the wrong game.

Make uncertainty visible

A guide should distinguish facts from advice. A verified source mapping is a fact about the page. A suggested opening order is strategy. Event rewards and economy values may change by version, so they need dates or version notes.

That distinction also improves maintenance. When a source changes, the affected pages can be found and reviewed without rewriting every strategy article.

Help the player verify the page

The page itself should give the player enough information to reject a mismatch quickly. Useful signals include:

• the exact level number;
• the game or app version covered;
• a visible opening-board description;
• the source video title and ID;
• a warning when the browser and mobile games differ.

The player should compare the first screen before copying any move. If the container count, top colors, or blocked stacks differ, the walkthrough is for another board.

Apply the same rule to downloads

Generic game names also create download risk. A guide should link to the official store or developer page and identify the developer or package. Hosting copied APK files would remove the source information that players need to verify what they are installing.

I used these rules while organizing Fish Sort Wiki, which keeps the playable YIGOT browser game separate from 156 walkthroughs mapped to the Shycheese mobile version. The useful part of the model is not the number of pages. It is the boundary that stops two similarly named games from becoming one unreliable dataset.

If you are building guides for a game with clones, regional editions, or frequent updates, store the identity and evidence first. The walkthrough text is much easier to maintain once every page can answer: “Which exact game and source does this belong to?”