Un vaisseau à remettre sur pied. Des lieux qui appellent. Et le plaisir de revenir plus capable qu’au départ.
Explorer librement des lieux mystérieux, suivre des signaux, récolter de façon tangible et préparer ses expéditions. Le crash d’un unique vaisseau habitable et modulaire amorce l’aventure : le réparer donne accès à des voyages automatisés vers d’autres régions ou planètes. Le vaisseau devient un foyer et un outil de progression, tandis que le personnage gagne lui aussi en capacité, en efficacité et en précision.
Pilotage manuel, combat spatial, génération procédurale, grands arbres de talents et donjons ne sont pas des décisions acquises.
Provenance : demande du 13 novembre 2026 + conversation « Motivation de jeu vidéo » (identifiant 6af74287-349c-83e9-8d33-61d8ea7db9ca). La lecture disponible contient cinq échanges récents et des réponses assistant tronquées. Les propositions antérieures de l’assistant ne constituent pas à elles seules une approbation utilisateur. Les éléments absents de ces extraits mais explicitement demandés aujourd’hui sont retenus au titre de la demande actuelle.
Un signal, une silhouette ou une anomalie doit donner envie de faire un détour. L’exploration reste libre : préparer une expédition offre des intentions, pas un couloir.
Test proposé : le joueur explique ce qui l’a attiré sans qu’on lui impose son trajet.
Un outil futuriste doit communiquer un contact, une résistance et un résultat : son, animation, fissure, détachement. Une technologie supérieure enrichit le geste.
Test proposé : comparer deux récoltes à rendement égal ; observer laquelle donne envie de recommencer.
La limite du sac crée un arbitrage compréhensible entre besoins et découvertes. Le joueur doit savoir pourquoi il revient et ce qu’il a choisi de laisser.
Garde-fou proposé : montrer les besoins du projet suivi ; éviter les trajets sans nouvelle décision.
Le tir doit être agréable avant les récompenses RPG. Lisibilité des réactions, recul, sons et déplacements priment sur le nombre d’armes.
Test proposé : une arène sans butin doit déjà donner envie de rejouer.
Porter davantage, mieux maîtriser son arme, extraire une nouvelle matière ou débloquer une destination doit modifier une possibilité concrète.
Garde-fou proposé : comparer une même expédition avant et après une amélioration.
Les sorties nourrissent les réparations ; les réparations ouvrent l’exploration. Les avant-postes répondent à une distance ou une contrainte logistique réelle.
Garde-fou proposé : chaque installation répond à un usage observable.
Inspirations, selon le joueur : de Valheim, retenir la récolte, l’exploration et la préparation logistique ; de Destiny, les armes satisfaisantes, la présence en vue subjective, les boss, l’univers et la progression RPG. Ces préférences ne prescrivent ni une économie de service en ligne, ni un volume de contenu comparable.
Secondes : viser un point exploitable → agir → percevoir l’impact → récupérer. En combat : repérer → viser → tirer → lire la réaction → se repositionner.
Minutes : choisir un objectif → emporter les outils utiles → arbitrer les ressources → déposer ou revenir → achever un projet.
Sessions : restaurer le vaisseau → améliorer ses capacités → accéder à un nouveau lieu → découvrir un nouveau besoin.
Un signal éloigné encourage la préparation. Une matière lourde rend le dépôt utile. Un ennemi dangereux donne du sens à l’amélioration du personnage. Une réparation du vaisseau donne une destination aux ressources.
Hypothèse : un boss protège une découverte ou un accès, sans imposer que chaque voyage soit verrouillé par un boss.
| Système | Règle de travail — hypothèse | Frontière à vérifier |
|---|---|---|
| Récolte | Gisement à états : intact, endommagé, épuisé. Chaque coup valide produit une réponse ; rendement configurable. | Changer de cible ou interrompre l’action ne donne aucun gain fantôme. Commencer par états visuels, avant destruction libre. |
| Inventaire | Poids = somme des masses ; volume = somme des volumes abstraits. Ce n’est pas encore un puzzle 3D de rangement. | À une limite exactement, la prise reste valide ; au-delà, refus explicite. Aucun objet perdu silencieusement. |
| Transfert | Vérifier place et quantité avant de retirer de la source ; confirmer l’ajout et le retrait ensemble. | Sac plein, transfert partiel, quantité zéro, objet retiré entre sélection et action. |
| Projet suivi | Une recette visible expose coût, stock disponible et manque. Le choix de réserver les ressources reste ouvert. | Stock du sac et du vaisseau clairement distingués ; progression visuelle actualisée au dépôt. |
| Avant-poste | Un dépôt persistant placé sur sol valide, utile avant toute chaîne de production. | Collision, pente, coût, récupération et risque de bloquer un accès. |
| Échec | Prototype : retour au vaisseau et cargaison récupérable à un point sûr ; équipement de base conservé. | Pas de blocage sans outil ni de disparition définitive des composants critiques. Pénalité finale non décidée. |
| Voyage | Destination sélectionnée → contrôle de réparation → transition → apparition au point sûr avec le même état du vaisseau. | Chargement interrompu, sauvegarde avant départ, maintien des stocks et modules, voyage répété. |
Les durées ci-dessous sont des repères de conception, pas des engagements. Aucun nom de planète, ressource, faction ou personnage n’est fixé.
Se réveiller après le crash, reconnaître l’intérieur habitable, voir une panne concrète et un projet de réparation. Sortir, repérer un relief intrigant et percevoir un premier signal. Le crash peut être raconté par le décor plutôt qu’une cinématique coûteuse.
Tester un outil sur une matière proche, voir son action produire un changement. Trouver une seconde ressource ; faire un choix de chargement avant d’avoir tout ramassé. Le projet suivi explique le besoin immédiat.
Suivre le signal vers un petit lieu mystérieux, avec un trajet alternatif. Rencontrer un ennemi lisible, essayer le tir et comprendre les réactions. Une retraite reste possible ; une victoire n’est pas le seul résultat acceptable.
Déposer, réparer un sous-système puis choisir une amélioration simple. Le vaisseau manifeste la réparation ; un signal plus lointain donne envie de repartir. Le décollage complet peut attendre plusieurs sorties.
Revisiter un lieu avec une amélioration de portage ou d’outil. Comprendre un nouvel arbitrage. Installer un premier dépôt si la distance lui donne une vraie utilité.
Découvrir un site plus dangereux ; affronter un boss simple dont les attaques sont télégraphiées. Obtenir une découverte ou un composant utile, sans fixer encore une progression obligatoire par boss.
Finaliser une réparation majeure et choisir une destination. Voyage automatisé vers un nouvel environnement ; même vaisseau, mêmes stocks, nouveaux problèmes à résoudre.
Simulé : réparation par changement d’état ; destinations montrées mais voyage désactivé. Le dépôt peut d’abord être préplacé pour mesurer son utilité.
Hors périmètre : boss complet, vol, planète entière, procédural, coop, découpe libre, fabrication complexe et assemblage libre du vaisseau.
Critère de sortie : montrer du crash au prochain départ une expérience cohérente ; mesurer le coût réel d’un lieu, d’un ennemi et d’un module.
Une slice démontre aussi la méthode de production. Elle ne valide pas la quantité de contenu du jeu final.
Faire jouer idéalement 3 à 5 personnes correspondant aux amateurs d’exploration, sans leur expliquer le trajet. Ce petit échantillon sert à détecter des problèmes, pas à prouver un succès commercial. Fixer les seuils avant les sessions.
| Hypothèse | Observation / seuil initial proposé | Si cela échoue |
|---|---|---|
| La curiosité suffit | Au moins 3 personnes sur 5 trouvent le lieu et expliquent ce qui les a attirées sans aide. | Revoir repères, contraste et signal avant d’ajouter une carte. |
| Récolter est plaisant | Au moins 3/5 préfèrent une variante de feedback et peuvent dire pourquoi ; observer une envie de réessayer sans récompense supplémentaire. | Revoir contact, rythme, son et détachement ; ne pas augmenter le rendement pour masquer le problème. |
| Le poids crée un choix | Au moins 3/5 expliquent ce qu’elles laissent et pourquoi ; noter chaque trajet jugé inutile. | Ajuster coûts, distances et capacité ; tester le poids seul avant de cumuler les contraintes. |
| La boucle se ferme | Au moins 4/5 terminent une réparation et identifient une raison de repartir sans indication orale. | Revoir l’objectif, les besoins et le résultat visible. |
| Le tir tient seul | Au moins 3/5 souhaitent rejouer une rencontre sans butin et comprennent pourquoi elles ont subi des dégâts. | Revoir réaction, visée, télégraphes et temps de réponse avant les statistiques RPG. |
Ces critères ne sont pas encore mesurés. Aucun prototype UE5, test joueur ou résultat de performance n’est livré avec ce document.
Plan proposé P0 : boucle minimale. P1 : slice représentative. P2 : extension ultérieure. L’effort relatif reste indicatif : M = mécanique locale ; L = plusieurs systèmes ; XL = risque transversal. Aucune durée de production n’est estimée sans équipe, version UE5 et audit du projet.
But : démarrer sans imposer une architecture inconnue. Dépendances : aucune.
UE5 : fixer version, cible PC proposée, entrées et budget matériel ; examiner RxFramework, plugins et conventions si les fichiers deviennent disponibles. Créer une carte de test, Enhanced Input et paramètres exposés.
Acceptation : lancement autonome du projet, déplacement/regard utilisables, action d’interaction réaffectable ; journal des versions et licences. Choix provisoire clavier/souris, manette à arbitrer.
But : viser, comprendre et agir. Dépendances : B00.
UE5 : trace de visée, interface d’interaction, composants réutilisables ; Data Assets pour identifiant, masse, volume, catégorie et présentation ; UMG pour l’invite.
Acceptation : une seule action vise une seule cible valide ; sortir de portée ou détruire la cible annule proprement l’action ; invite mise à jour sans cible fantôme.
But : éprouver le geste avant l’économie. Dépendances : B01.
UE5 : outil à impact, animation et retour audio/VFX, gisement à états ; morceaux prédéfinis avant toute expérimentation Chaos. Données de rendement séparées du visuel.
Acceptation : chaque impact valide a une réponse perceptible ; un gisement épuisé ne donne plus rien ; interrompre et reprendre ne multiplie pas le rendement ; deux variantes comparables à rendement égal.
But : rendre les choix de transport lisibles. Dépendances : B01 ; intégration avec B02.
UE5 : composant inventaire, quantités et limites issues des données, affichage UMG ; opération de transfert validée avant mutation des stocks. Le calcul métier reste indépendant du widget.
Acceptation : objet acceptant exactement la capacité maximale ; refus au-delà avec motif poids ou volume ; dépôts partiels corrects ; somme des quantités conservée entre deux conteneurs ; aucun doublon à clic répété.
But : susciter un détour volontaire. Dépendances : B01.
UE5 : acteur émetteur à identifiant, intensité/direction paramétrées, indice sonore doublé d’un indice visuel, état découvert. Petit relief avec deux approches.
Acceptation : on peut localiser le site sans explication orale ; le signal ne traverse pas toutes les étapes de mystère d’un seul coup ; la découverte n’est accordée qu’une fois ; audio non indispensable à la compréhension.
But : tester le plaisir du combat sans arsenal. Dépendances : B00, B01.
UE5 : une arme hitscan proposée ; composants arme/dégâts, animation, recul réglable, réactions ; AIController et NavMesh avec quelques états explicites. Point de comparaison GAS à B09.
Acceptation : aucun tir à travers un obstacle bloquant ; cadence et recharge cohérentes ; ennemi signale son attaque, réagit au coup et cesse d’agir à sa mort ; option pour réduire le mouvement de caméra.
But : fermer la boucle expédition → changement durable. Dépendances : B02, B03.
UE5 : acteur vaisseau persistant par identifiant ; recette en Data Asset, conditions de panne, interface des besoins ; stockage lié par référence explicite.
Acceptation : coût retiré une seule fois, réparation impossible si stock insuffisant ; résultat audible/visible ; projet mis à jour au transfert ; une réparation terminée reste terminée.
But : rendre l’investissement fiable. Dépendances : B03, B04, B05, B06 ; prévoir les identifiants dès B01.
UE5 : SaveGame versionné : identifiants, stocks, ressources épuisées, réparations, progression et position sûre. Sauvegarder les données utiles, reconstruire les acteurs au chargement.
Acceptation : quitter/reprendre conserve quantités et états sans recréer une ressource déjà prise ; chargement d’une sauvegarde absente ou invalide donne un message et un démarrage sûr ; mourir ne bloque pas la réparation. Étendre les données avec chaque B08–B12.
But : vérifier une différence tangible. Dépendances : B03, B05, B06, B07.
UE5 : amélioration de portage ou maîtrise d’arme configurable ; comparaison avant/après ; coût et effet stockés séparément. Évaluer la frontière GAS avec B09 sans bloquer le test simple.
Acceptation : amélioration acquise une seule fois, effet visible dans l’usage, effet identique après rechargement ; pas d’accumulation du bonus à chaque chargement. L’amélioration d’outil doit conserver le contact et le feedback.
But : choisir une base adaptée aux effets RPG. Dépendances : B00, B05, B08.
UE5 : mini-comparatif composants simples / GAS sur santé, dégâts et un bonus temporaire. Si GAS retenu : ASC sur le personnage pour le prototype, AttributeSet, Gameplay Effects et Gameplay Tags ; réexaminer PlayerState lors d’une étude multijoueur.
Acceptation : coût d’intégration documenté ; effet réversible sans double application ; dégâts, bonus et sauvegarde passent par une seule source de vérité. Décision conservée avec justification.
But : réduire une friction logistique mesurée. Dépendances : B03, B06, B07.
UE5 : aperçu de placement, trace au sol, validation collision/pente, coût ; réutiliser le composant de stockage. Ajouter identifiant et transform à SaveGame.
Acceptation : pose invalide refusée sans coût ; pose valide coûte une seule fois ; dépôt retrouvé avec son contenu après chargement ; démontage ne duplique pas les ressources. Mesurer les trajets évités.
But : vérifier une rencontre mémorable avec peu de règles. Dépendances : B05, B07 ; B09 si GAS adopté.
UE5 : réutiliser dégâts et IA ; une attaque télégraphiée, une ouverture, une récompense de découverte. Éviter plusieurs phases avant validation.
Acceptation : le joueur identifie le danger et l’ouverture ; mort/reprise réinitialise la rencontre ; récompense persistante unique ; victoire possible avec l’équipement prévu sans exploitation de collision.
But : démontrer la promesse du même foyer dans un autre lieu. Dépendances : B06, B07 ; B11 seulement si son verrou est choisi.
UE5 : module sur socket prédéfini ; catalogue de destinations ; transfert d’état via données persistantes et transition de carte, sans simulation de vol. Nouvelle entrée SaveGame pour région et modules.
Acceptation : voyage bloqué tant que les conditions affichées manquent ; après transition, même inventaire et module ; aller-retour sans duplication ; point d’arrivée dégagé ; relancer après sauvegarde avant/après transition restaure un état cohérent.
But : étudier l’aventure partagée après validation solo. Dépendances : B00–B12 validés et décision explicite de poursuivre.
UE5 : prototype séparé à deux joueurs ; autorité serveur sur inventaires, dégâts, récolte et progression ; examiner propriété du vaisseau et sauvegarde de l’hôte. GAS facilite certains échanges mais ne résout pas l’inventaire ni les sessions.
Acceptation proposée : deux joueurs ne récupèrent pas la même ressource deux fois ; réparation simultanée consomme une fois ; déconnexion/reconnexion conserve l’état ; tester latence, arrivée tardive et transition. Nombre de joueurs, hébergement et progression partagée restent ouverts.
Chemin recommandé : B00 → B01 → B02/B03 → B06 → B07 → B08, avec B04 et B05 intégrés avant le test de boucle. Décider ensuite B09, puis B10/B11/B12 pour la slice. Commencer par la salle de récolte et l’arène de tir avant de produire un grand environnement.
GAS structure attributs, capacités et effets. Il devient intéressant si santé, résistances, coûts, bonus temporaires et capacités se multiplient. Il ne remplace ni le système d’inventaire, ni la construction, ni la persistance du monde.
Proposition : tester une attaque, la santé et un effet temporaire. Garder les définitions d’objets et de recettes en données. Les animations, sons et VFX restent des travaux nécessaires, quelle que soit l’architecture.
Si le prototype ne nécessite que quelques interactions et statistiques, des composants simples peuvent suffire. Éviter deux systèmes concurrents de dégâts ou de progression.
Documentation Epic : GAS →Aucun dépôt, numéro de version ou document technique RxFramework n’a été fourni. Aucune compatibilité UE5/GAS, licence ou capacité réseau n’est donc présumée.
Aucun lien RxFramework n’est ajouté : une recherche publique n’a pas permis d’identifier une référence officielle certaine correspondant au projet.
Les définitions d’objets, recettes et modules sont des données stables. L’inventaire détient les quantités ; le vaisseau détient ses réparations et modules ; le personnage détient ses capacités ; la sauvegarde capture ces états par identifiants. L’interface observe les changements, puis demande une action validée par le système propriétaire. En coop éventuelle, cette validation devra être portée par le serveur.
Blueprints pour itérer ; C++ si une fondation réutilisable ou une complexité mesurée le justifie. Ne pas imposer World Partition ni du streaming planétaire à une petite zone de test. Les pages Epic évoluent : choisir leur version correspondant au projet avant toute intégration.
| Risque | Signal d’alerte | Réponse proposée |
|---|---|---|
| Deux jeux ambitieux réunis | Ni récolte ni FPS n’est agréable sans récompense. | Deux tests de sensations courts, puis une boucle complète. Différer le volume de contenu. |
| Physique trop coûteuse | La destruction libre monopolise le travail ou rend la récolte instable. | Gisements à états et morceaux préparés ; comparer le résultat avant Chaos ou découpe libre. |
| Logistique fastidieuse | Retours fréquents sans choix ni découverte. | Revoir distances et capacité ; projet suivi ; dépôt utile ; tester poids seul contre poids + volume. |
| FPS et économie déséquilibrés | Le joueur évite tous les combats pour conserver ses ressources. | Coût de munitions paramétrable ; retrait possible ; vérifier qu’un échec n’enferme pas la progression. |
| Exploration vide | Le terrain augmente plus vite que les rencontres intéressantes. | Une petite région dense avant plusieurs planètes ; mesurer le coût d’un lieu fini. |
| Vaisseau modulaire complexe | Chaque module impose de nouvelles collisions ou une navigation intérieure fragile. | Points d’attache prédéfinis et peu de modules ; conserver un accès sûr après toute configuration. |
| Coop trop tardive | Les widgets modifient directement les stocks et états du monde. | Isoler les mutations dès le solo ; faire un test réseau limité si la coop devient une priorité réelle. |
| Données perdues / dupliquées | Rechargement qui régénère les gains ou double les bonus. | Identifiants stables, transferts validés et tests de reprise dès B07. |
| Framework mal adapté | RxFramework impose un second modèle de données ou une version incompatible. | Audit B00 et essai d’intégration borné ; préférer un périmètre simple si l’adaptation dépasse le bénéfice. |
| Décision | Point de départ proposé | Quand trancher |
|---|---|---|
| Équipe, temps disponible, cible et version UE5 | Petit prototype solo PC, clavier/souris ; capacité de production inconnue. | Avant B00 ; aucune date de sortie. |
| Origine des signaux, ton, place du récit | Mystère environnemental, sans réponse narrative définitive. | Avant l’habillage du premier lieu. |
| Carte, scanner ou repères naturels | Signal directionnel + paysage ; pas de scanner complexe requis. | Test B04. |
| Poids, volume et surcharge | Deux budgets abstraits ; refus explicite à capacité dépassée. | Comparatif B03 avec une seule contrainte. |
| Mort, perte et récupération | Cargaison récupérable, outil de base préservé. | Avant B07. |
| Survie : faim, oxygène, énergie | Ne rien ajouter au MVP sans objectif de design démontré. | Après test de boucle ; aucune de ces jauges n’est confirmée. |
| Progression : niveaux, compétences, équipement | Une amélioration concrète acquise par un projet. | B08/B09 ; éviter de fixer un arbre avant le test. |
| Boss et accès aux destinations | Boss utile à une découverte ; verrou obligatoire non retenu. | Avant B11/B12. |
| Voyage : coût, durée, retour | Transition courte et retour permis dans la slice. | Avant B12 ; carburant et carte stellaire non décidés. |
| Modularité intérieure/extérieure | Un module sur point d’attache. | Avant B12 ; assemblage libre non décidé. |
| Coop : joueurs, hôte et progression | Étude à deux joueurs, hors MVP. | Après validation solo, avant production réseau. |
Liens consultés ou identifiés le 13 novembre 2026. Les observations à faire ci-dessous sont des pistes de travail pour Last Signal ; elles ne sont pas des affirmations sur les techniques internes des studios.
La FAQ officielle présente la collecte, les avant-postes et les monstres comme parties de l’aventure, jouable en solo ou en coopération.
À observer : réaction de la matière, préparation d’une sortie, moment où la capacité de transport change la décision. Rejouer un trajet et noter ce que le dépôt apporte.
FAQ officielle Iron Gate →Référence exprimée par le joueur : armes, boss, exploration, univers et vue subjective. Il n’a pas demandé de reproduire les donjons ni un grand arsenal.
À observer : séparer les couches de feedback d’un tir, comparer une cible mobile et fixe, relever ce qui rend une ouverture de boss compréhensible.
Présentation officielle Bungie →Page identifiée, mais contenu non récupéré lors de la vérification (expiration du délai). Aucune affirmation technique n’en est déduite ; les préférences ci-dessus proviennent de la conversation.
Référence technique officielle pour structurer capacités et attributs. Elle guide l’essai B09, sans rendre GAS obligatoire.
Exercice : un dégât et un bonus temporaire réversible ; compter les points d’intégration et comparer la lisibilité.
Epic · vue d’ensemble GAS →Exemple officiel d’utilisation de capacités dans UE5 ; utile pour examiner une organisation existante, sans transposer toute son architecture au prototype.
Exercice : tracer un seul chemin entrée → capacité → effet → feedback, puis ne retenir que les parties pertinentes.
Epic · capacités dans Lyra →Le système officiel s’appuie sur des classes SaveGame contenant les informations à conserver. Last Signal doit définir lui-même les états nécessaires.
Exercice : sauvegarder après transfert, quitter, reprendre et vérifier stocks, gisement et réparation.
Epic · sauvegarder et charger →Pour chaque inspiration : noter une action, un feedback, un choix et une conséquence. Reproduire l’intention dans une scène minimale, puis observer les joueurs.
Les jeux servent de références sensibles, les documents Epic de références techniques. Aucun comportement propriétaire de Destiny ou Valheim n’est présumé disponible dans UE5.
Le contenu de référence se modifie dans le fichier HTML. Le journal ci-dessous permet de préparer les prochaines révisions. Les notes locales dépendent de ce navigateur et de l’emplacement du fichier ; elles ne constituent pas une synchronisation et peuvent être indisponibles selon les réglages.
L’export HTML embarque le journal dans une zone cachée, lisible par le script et par une future conversation. En cas de transfert à un autre appareil, utilisez cet export ou joignez le fichier de notes Markdown. Aucun envoi réseau n’est effectué.
Joindre ce HTML et, si nécessaire, le README compagnon et les notes exportées. Demander une révision précise en conservant les statuts. Une observation de test peut justifier une recommandation ; seul un arbitrage explicite transforme une hypothèse en décision confirmée.