Sleep Space Game transforme une habitude du soir en jeu : moins on utilise son téléphone au moment de se coucher, plus la partie avance. Pas un tracker de sommeil ni une appli moralisatrice ; juste un comportement simple à mesurer, transformé en progression.
Le joueur a un vaisseau dans le système solaire. Il choisit une destination, lance le trajet en pilote automatique, et chaque session du soir raccourcit le voyage. Une session, c’est activer le mode repos et poser le téléphone ; le lendemain, le voyage a avancé. La progression vient de cette routine, pas d’un pilotage ni d’une simulation.
C’est un projet en cours, conçu et développé avec un camarade : on a pris les décisions à deux. Plusieurs parcours sont déjà jouables ; les statistiques, la validation du comportement et une partie du rendu restent à faire.
Une boucle volontairement réduite
On a d’abord refusé le jeu spatial complet. Le projet pouvait vite dériver vers du pilotage, des mini-jeux, des améliorations de vaisseau ou de la compétition. On a gardé une boucle stricte : un vaisseau, une destination, un trajet, une session du soir, un gain de temps.
Cette réduction sert le produit : pas de système complexe à apprendre. Le joueur pose son téléphone au bon moment, la session devient de la progression, l’interface la rend visible. La mécanique reste simple en façade, même si le modèle de mission est plus riche derrière.
Le social suit la même logique : pas de courses en temps réel ni de défis compétitifs. Le groupe est un soutien : rejoindre un équipage, voir la contribution récente des membres, tenir une streak de groupe qui pardonne les oublis. Le but est d’aider à garder une routine, pas de culpabiliser.
Un produit mobile en développement
L’app couvre l’authentification, l’onboarding, la home, la carte solaire, le groupe, les statistiques et les paramètres. On a séparé les écrans, l’état, les repositories, les modèles de domaine et les sources distantes : le rendu, les règles de mission et la synchro Firebase évoluent à des rythmes différents, et cette séparation permet de bouger l’un sans casser le reste.
L’onboarding règle la routine de sommeil (âge de référence, heure de coucher, heure de réveil). Les paramètres modifient ensuite le profil, la routine, le mode session du soir et les notifications. Authentification, onboarding, réglages et appartenance à un groupe passent par Firebase.
La home affiche l’état de la mission dans un HUD : destination, phase, vitesse, progression, temps restant, streak, bouton repos. La carte solaire sert à choisir une destination, voir plusieurs estimations de durée, puis lancer ou annuler une mission. Ces écrans ne sont pas des maquettes : ils sont branchés sur les repositories et les opérations serveur.
L’écran de groupe est déjà utilisable : création, code d’invitation, rejoindre, quitter, retrait d’un membre par le propriétaire, statut de contribution, streak collective. L’écran de statistiques, lui, existe mais reste minimal : c’est une des parties à finir.
Missions, sessions et cohérence serveur
Le vrai problème, c’est de relier une action courte du soir à un trajet spatial long. On a modélisé les missions avec un état de voyage, une station de départ et une de destination, une heure d’arrivée estimée (ETA), des segments, des événements, une phase en cours et une télémétrie. Le client affiche la progression en temps réel, mais les changements sensibles passent par les Cloud Functions (du code exécuté côté serveur).
Lancer une mission crée un plan avec un premier segment. Le trajet se découpe en départ, croisière et arrivée. La durée de référence dépend de la distance entre les astres, et l’interface montre plusieurs scénarios pour rendre l’effet de la routine plus concret.
Quand une session du soir se termine, le serveur calcule un score, applique un gain et replanifie la mission : le segment en cours se ferme, un nouveau s’ouvre, et l’ETA baisse selon la phase de vol. Conséquence voulue : une bonne session reste utile même en fin de trajet, pas seulement au départ.
On ne fait pas confiance aux mesures venant du téléphone pour calculer le score. Les signaux bruts sont filtrés, la durée récompensée vient de la vraie fenêtre de session, et le client n’écrit pas directement les documents de mission, de session ou de groupe. Ce sont les règles Firestore et les fonctions serveur qui tiennent cette frontière.
Un rendu spatial en construction
Le visuel s’est fait par étapes. D’abord vérifier que la home pouvait devenir une scène plein écran : un vaisseau, une caméra orbitale, un fond spatial, un HUD par-dessus. Ce prototype a validé la structure sans figer trop tôt le moteur final.
La version actuelle va plus loin : planètes texturées, atmosphères, anneaux, skybox, cache de textures, et niveau de détail ajusté selon la taille à l’écran. La scène reste centrée sur le vaisseau, et les positions des astres sont gardées en cache quinze minutes pour éviter des appels réseau inutiles.
Les positions des astres viennent de JPL Horizons, le service d’éphémérides de la NASA, complété par un catalogue local (rayons, couleurs, statut de destination, assets). Le but n’est pas une simulation astronomique exacte, juste assez de réalisme pour que le trajet ait du poids, sans sacrifier la lisibilité sur mobile.
Ce qui est construit, ce qui reste ouvert
Le socle est solide : app Android native, navigation, onboarding, authentification, repositories Firebase, carte solaire, home de mission, groupe, paramètres, modèle de trajet, fonctions serveur, règles Firestore, et des tests sur plusieurs points critiques. Le projet a dépassé le concept.
Ce qui reste : l’expérience finale. Les statistiques personnelles ne sont pas au niveau visé. La détection du comportement sur Android est plus limitée que prévu : le mode repos repose surtout sur une session lancée puis terminée, notée côté serveur sur la durée, pas sur une analyse fine de tous les signaux de la nuit. Le rendu 3D tient comme base, mais le vaisseau et le polish ne sont pas finis.
Donc : pas une appli publiée, mais un produit mobile en construction sur une base technique déjà solide. Ce qu’il montre le mieux : transformer une idée de comportement en mécanique de jeu, puis la tenir dans une architecture mobile et backend qui laisse de la place pour itérer.