PARALLEL — le monde réel devient un RPG

Un jeu qui demande de pointer le téléphone sur son salon devrait pouvoir fonctionner sans envoyer une seule image à un serveur. PARALLEL part de cette contrainte : le joueur cadre ce qui l'entoure, le jeu en tire une anomalie, des quêtes et une carte, et rien ne quitte l'appareil.

Ce que fait l'app

• Analyse de scène sur l'appareil : Vision sur iOS, ML Kit sur Android, avec un tracker qui stabilise les détections d'une image à l'autre.
• Génération d'une rencontre (« PARALLEL DETECTED ») à partir des objets vus : titre, texte d'ambiance, rang, énergie et trois objectifs.
• Rédaction par un modèle de langage embarqué (Foundation Models sur iOS, Gemini Nano sur Android) quand il est disponible, moteur déterministe sinon : le jeu reste toujours jouable.
• Quêtes avec objectifs variés (collecter, repérer, photographier puis confirmer), XP, inventaire et écran de fin de quête.
• Carte radar dessinée par l'application, sans tuiles ni clé d'API, avec zones procédurales sur une grille 5x5 et lieux réels en option.
• Aucune requête réseau dans la configuration par défaut, documentée dans un fichier de confidentialité.

Stack et architecture

Le dépôt contient deux applications natives (SwiftUI, environ 145 fichiers Swift ; Kotlin, environ 135 fichiers) et un socle partagé en JSON : 77 objets, 12 anomalies, 14 quêtes, schémas et fichiers golden. Un moteur de référence en Node, sans dépendance, produit les sorties attendues ; les deux cœurs, un package Swift ParallelCore et un module Kotlin, doivent les reproduire octet pour octet. Le projet Xcode est généré par xcodegen depuis un project.yml.

Ce qui a été difficile

La parité entre iOS et Android. Deux implémentations natives d'un même générateur divergent vite : ordre d'un tirage aléatoire, arrondi, choix de la couleur dominante. Le contrat est donc figé dans des fichiers golden vérifiés à chaque test, avec un générateur pseudo-aléatoire spécifié par vecteurs de contrôle et une horloge injectée pour que les sorties restent reproductibles. Plusieurs commits d'alignement du cœur (validation de la zone atteinte contre les zones fournies, un seul classement de couleurs, sauvegarde identique) viennent de cette exigence. L'autre point délicat est le modèle embarqué : le code doit tolérer son absence, un délai dépassé ou une annulation, et basculer sur le moteur déterministe sans bloquer le joueur.

État du projet

iOS est complet : cœur testé (153 tests), perception, modèle embarqué, carte et boucle de jeu, vérifiés au simulateur et installés sur un iPhone de test. Android dispose de son cœur (175 tests), de la perception, du modèle embarqué et de la carte ; l'écran de jeu reste à écrire. Le projet est en pause, non publié sur le store.