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)

Source Objectifde du jeu

données

PermettreTMDB (The Movie Database) : API gratuite avec clé, excellente couverture, simple à utiliser. ➡️ On extrait un sous-ensemble (personnes + films/séries) et on stocke en local pour éviter les limites de requêtes.

Stockage

Neo4j Community Edition : base graphe native, parfaite pour ce type de problème. ➡️ Pas besoin de surcouche relationnelle, et l’API Cypher est idéale pour trouver des joueurschemins.

Backend

Node.js (Express) : rapide à mettre en place, bonne intégration avec Neo4j via neo4j-driver. ➡️ Endpoints REST simples pour recherche et calcul de chemin.

Frontend

React + Vite : léger, moderne, parfait pour un prototype. ➡️ WebSocket pour mode temps réel (co-op, challenge).

📐 Modèle de données (fixé)

Noeuds

Person {id, name, type, popularity}

Title {id, name, year, type}

Arêtes

ACTED_IN (Person → Title)

CREWED (Person → Title)

⚙️ Algorithmes

Bidirectional BFS pour 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 licencesrapide et limitesefficace).

d'usage.
    • 

  • Stockage: graphe natif (Neo4j), base relationnelle, ou simple graphe enCache mémoire pour(simple prototypage.
    • Map 
en 


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 éviterNode.js) pour unstocker 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).
    • 

  • Cacherles résultats fréquentsrécents.

(Redis ou mémoire).
    • 

  • Limiter profondeurProfondeur 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 (éviterquivalent personnesà trop6 obscuresdegrés).
dans mode casual).
    •

5)🎮 Modes de jeu (idées)retenus)

    Classic 
  1. Classic: Trouvertrouver le chemin le plus court entre deux célébrités.

(enChallenge soloTemps ou: limite de 2 minutes pour trouver un chemin.

Co-op : 2 à plusieurs)
    2. 

  2. Challenge Temps: Trouver un chemin en X minutes.
    3. 

  3. Co-op: Équipe de 2-4 joueurs construisent le chemin ensemble.
    4. ensemble
via
WebSocket.

6)🏆 Scoring (fixé)

Quelques suggestions de formule :

  • Base points = (6 - degrees) *× 100.100

(si degree = 0..6)
  • Bonus temps : +50 points si trouvé rapidement.
    • en
  • moins de 1 minute. Bonus créativitérareté : +50 points si le chemin n'estinclut pasun trivialtitre peu populaire (par< ex.seuil utiliserTMDB despopularity). titres rares).

7)🌐 API & endpoints (prototype)fixée)

  • GET /api/people?q=search —→ recherche depersonnes

personnes.
  • GET /api/title?q=search —→ recherche de films/séries.
    • ries
  • POST /api/path —→ corpscalcule chemin { fromPersonId, toPersonId }, retourne➡️ Retourne : chemin (liste de nodesnodes/edges), longueur, score calculé.

    🏗️ Architecture finale

    Data ingestion : script Node.js qui appelle TMDB et edges)insère etdans métriques.
    • Neo4j.
Backend

8) Architecture recommandée pour production

  • Data ingestion: pipelineExpress pour+ récupérer/normaliser TMDB/Wikidata -> stockage graphe (Neo4j / Dgraph)
  • API: Node/Go service exposant endpointsNeo4j-driver + cache (Redis)
    • mémoire.
  • Frontend : React + Vite + WebSocket. Auth : simple login par pseudo (pas besoin d’OAuth pour usage privé). Analytics : log en mémoire des chemins joués (top 10 affichés en frontend).

    🚀 Prototype minimal (MVP)

    Script d’ingestion TMDB → Neo4j.

Backend Express avec 3 endpoints.

Frontend React avec :

    Formulaire pour choisir deux personnes

    Affichage du chemin (liste ou graphe visuel avec vis.js ou d3.js)

    Timer pour mode Challenge Temps

    WebSocket pour jeumode tempsCo-op
réel
  • Auth & Social: OAuth / invites
  • Analytics: suivre chemins populaires, taux de résolution
Back to top