Skip to main content

Six Degrees of Kevin Bacon

Six Degrees — Analyse & Prototype

Ce document rassemble l'analyse, le design, le modèle de données et un prototype minimal (backend + frontend) pour un jeu en ligne entre potes inspiré du principe des Six Degrees of Kevin Bacon.

1) Objectif du jeu

Permettre à des joueurs de trouver le chemin le plus court entre deux personnes publiques (acteurs, réalisateurs, etc.) via des films/séries communs. Variante sociale pour un usage entre amis (ex. lier des amis à des célébrités, ou lier deux amis via événements/jeux communs).

Contraintes / décisions à prendre plus tard

  • Quelle source de données utiliser (IMDb, TMDB, Wikidata...) — attention aux licences et limites d'usage.
  • Stockage: graphe natif (Neo4j), base relationnelle, ou simple graphe en mémoire pour prototypage.

2) Données et licences

Options courantes :

  • TMDB (The Movie Database): API gratuite (avec clé), bonne couverture, terms of use à respecter.
  • IMDb: données propriétaires — usage restreint ; meilleure éviter pour un projet public sans licence.
  • Wikidata: open data, moins "prête à l'emploi" mais très flexible.

Pour un prototype entre potes, on peut démarrer avec un petit jeu de données JSON extrait manuellement ou via TMDB.

3) Modèle conceptuel (graphe)

Noeuds:

  • Person (id, name, type: actor/director, known_for...)
  • Title (id, name, year, type: movie/series)

Arêtes:

  • ACTED_IN / CREWED (Person — Title)

Chemin entre deux personnes = alternance Person → Title → Person → Title → ...

4) Algorithmes

4.1 Trouver le chemin le plus court

  • BFS (Breadth-First Search) sur le graphe non orienté (ou bi-partite Person<->Title). Retourne le plus court chemin en nombre de sauts.
  • Pour graphe très large, utiliser bidirectional BFS (départ des deux extrémités), bien plus rapide.

4.2 Optimisations

  • Indexer par personId → list(titleId) et titleId → list(personId).
  • Cacher résultats fréquents (Redis ou mémoire).
  • Limiter profondeur max (ex: 6*2 sauts = 12 traversées si on compte Person+Title).

4.3 Mesures additionnelles

  • Centralité (degène / betweenness) pour proposer des personnes "faciles".
  • Popularité pour choisir des cibles (éviter personnes trop obscures dans mode casual).

5) Modes de jeu (idées)

  1. Classic: Trouver le chemin le plus court entre deux célébrités. (en solo ou à plusieurs)
  2. Challenge Temps: Trouver un chemin en X minutes.
  3. Co-op: Équipe de 2-4 joueurs construisent le chemin ensemble.

6) Scoring

Quelques suggestions de formule :

  • Base points = (6 - degrees) * 100. (si degree = 0..6)
  • Bonus temps si trouvé rapidement.
  • Bonus créativité si le chemin n'est pas trivial (par ex. utiliser des titres rares).

7) API & endpoints (prototype)

  • GET /api/people?q=search — recherche de personnes.
  • GET /api/title?q=search — recherche de films/séries.
  • POST /api/path — corps { fromPersonId, toPersonId }, retourne chemin (liste de nodes et edges) et métriques.

8) Architecture recommandée pour production

  • Data ingestion: pipeline pour récupérer/normaliser TMDB/Wikidata -> stockage graphe (Neo4j / Dgraph)
  • API: Node/Go service exposant endpoints + cache (Redis)
  • Frontend: React + WebSocket pour jeu temps réel
  • Auth & Social: OAuth / invites
  • Analytics: suivre chemins populaires, taux de résolution
Back to top