Every Game Is Connected — I Built the Graph That Proves It

Every Game Is Connected — I Built the Graph That Proves It

Recommendation engines are great at telling you what is similar to the game you just played. They are terrible at telling you why two games are connected — especially when the connection runs across studios, decades, and genres.

That "why" bothered me, because it isn't really a fact about either game. Elden Ring and Stardew Valley share almost nothing you'd put in a database row. But there are real paths between them — through other games, through the people and companies who made them, through lineages of remakes and expansions. The connection is a property of the paths, and paths are what graphs are for.

So for Graph Hacks (WeMakeDevs × FalkorDB), I built the Gaming Multiverse Reasoner: pick any 2–4 games, and it traverses a FalkorDB graph of 50,217 games, 84,296 nodes, and 1,023,292 relationships to find the hidden paths between them — then an AI narrates the result, with every claim verifiable by clicking it.

• Try it live: https://multiverse.2fy1rnikhcll.us-south.codeengine.appdomain.cloud
• Code: https://github.com/Mike-Demo/gaming-multiverse-reasoner
• Demo video (2:55):

What it finds

Ask about Elden Ring, Hades, Stardew Valley, and Baldur's Gate III and you get 24 paths in about 2 seconds. Five kinds:

• Direct lineage — remakes, remasters, DLC, expansions, versions, shared collection/franchise parents
• Company bridges — a studio or publisher whose other games join the pair
• Similar-game chains — shortest paths over IGDB's similarity graph
• Common neighbours — games IGDB lists as similar to both
• Shared threads — a genre, theme, or engine both games genuinely share

Click any path card — or any sentence of the narration, or any node in the graph — and that exact path lights up. There's also a "Surprise me" slot machine that picks four random games, because a system tuned to one lucky demo set is a magic trick, not a product.

The core Cypher is almost disappointingly small. Similar-game chains are one shortestPath:

MATCH (a:Game {igdb_id:$a}), (b:Game {igdb_id:$b})
WITH shortestPath((a)-[:SIMILAR_TO*..4]-(b)) AS p
UNWIND nodes(p) AS n RETURN n.igdb_id, n.name

Every path card in the UI shows the actual query that produced it. If the graph did the work, you should be able to see the work.

Learning 1: Your biggest nodes are lying to you

The first version of this gave worthless answers, and the reason was hubs. Nearly every game in the catalogue is on "PC," and a huge share of them are tagged "Adventure." Route paths through those nodes and everything connects to everything in two hops — technically true, completely meaningless.

So the Reasoner suppresses hubs, mechanically:

• Platforms and game modes never appear in paths
• Any genre, theme, or engine shared by more than 12,000 games is suppressed ("Indie" and "Adventure" fail this test; "RPG" and "Fantasy" pass it)

The rule is printed in the app header. I think that's the important part: a suppression rule you hide is cherry-picking; a suppression rule you publish is a methodology.

Learning 2: A silent limit will quietly poison your results

Mid-build, I computed game communities — clusters from weighted label propagation over the similarity graph — and the numbers looked off. They were. FalkorDB caps any result set at 10,000 rows, and it does so silently. My first community computation ran on a truncated projection of the graph and I only caught it by counting rows by hand. (My first fix then collapsed the whole graph into one 27,403-member monster community, which is its own lesson: unweighted label propagation over a dense similarity graph needs weights and a size cap. The shipped version weights mutual links ×2, caps communities at 1,500 members, and found 6,234 communities — Elden Ring lands in an 8-game soulslike cluster, which feels right.)

The fix for the cap was paging the projection by ID ranges. The lesson I'm keeping: verify counts against an independent total before you build anything on a query result. A limit that doesn't announce itself isn't a bug exactly, but it is a trap — and it's the first piece of feedback I'd hand the FalkorDB team, along with two smaller things: typed-union relationship patterns ([r:T1|T2|…]) were surprisingly slow on our graph, and the ACL ergonomics around SETUSER could use clearer error messages. None of it stopped the build, and the parts that matter — traversal speed, shortestPath, read-only GRAPH.RO_QUERY with ACL users for a public demo — were genuinely good.

Learning 3: Don't make the AI trustworthy — make it checkable

The narration is IBM watsonx (Granite), and it has exactly one job: explain paths the graph already found. It never picks games, never writes queries, never invents facts. It returns claims as structured JSON, and here's the part I care about: every claim must cite the IDs of the paths it describes. Code validates each citation against the paths FalkorDB actually returned. A claim that cites nothing real is dropped before you ever see it.

And because claims carry path IDs, clicking a claim highlights the path in the graph. The AI doesn't ask you to trust it — it hands you the receipt. If watsonx is down, the app falls back to template explanations built from the same paths and labels them template, because the badge should always say which source you're reading.

Same honesty rule everywhere else: search results are never cached (the millisecond readout in the UI is the server's own measurement for that run — I like watching it), communities are precomputed and labeled precomputed, and SIMILAR_TO edges are IGDB's own data, credited as such. I refused to add invented "inspired by" edges even though they'd have looked great in the demo. An invented edge would have poisoned the whole grounding story.

The rest of the stack, briefly

FalkorDB runs in Docker on a single IBM VPC virtual server (bx2-4x16, us-south). The app is a single-file Python 3.12 program using only the standard library — zero third-party packages — speaking RESP to FalkorDB directly, hosted on IBM Code Engine with min-scale 1 so the demo URL is never cold. The IGDB snapshot (frozen 14 Oct 2026) sits in Cloud Object Storage; the catalogue started as IGDB's entire rated population and grew through critic-only, hyped, newest, and similarity-frontier tiers, plus the full QueerCade catalogue merged in.

The app is also an agent surface, because the track is Agents That Act on Connected Data: it hosts an MCP server with five tools (resolve_game, find_paths, random_games, game_community, narrate), so other agents can reason over the same graph. It scored 18/30 on a Silicon Friendly agent-readiness audit and 100/100 on a Lighthouse accessibility audit — both reports are public in the repo, fails included.

Try it

Bring your own four games — ideally four you think have nothing to do with each other. Those are the fun ones.

Live: https://multiverse.2fy1rnikhcll.us-south.codeengine.appdomain.cloud

Built solo by Mike "Demo" Demopoulos for Graph Hacks 2026 (Track 1 — Agents That Act on Connected Data). Project code is MIT licensed. Disclosure: the application code was written with an AI coding agent under my direction, with every subsystem verified live; narration at runtime is IBM watsonx; the demo video was produced with Pexo from real captures of the live app. Game data is IGDB's; this is a fan/hackathon project, not affiliated with IGDB or any publisher.