Feuille de route publique

Un monde à survivre.
Une communauté pour le créer.

Faire évoluer Last Light vers une plateforme de survie communautaire : hébergez votre serveur, construisez votre carte et imaginez vos propres règles.

Inspirée par la liberté communautaire de Rust et Garry’s Mod, cette vision conserve notre identité : un jeu de survie isométrique par navigateur, accessible sur PC et mobile, avec des modes Solo et Coop préservés.

ALPHA EXPÉRIMENTALEJEU PAR NAVIGATEURFONCTIONNALITÉS PLANIFIÉES

Construire les fondations avant les extensions

Quatre phases, une progression cohérente

Chaque phase apporte une capacité vérifiable. Le moteur devient d’abord indépendant de son rendu ; les serveurs, les contenus et les modes personnalisés s’appuient ensuite sur cette même base.

Refonte du moteur & noyau partagé

Décrire le jeu par les données et séparer simulation et présentation.

Ce que cela prépare

Un même ensemble de règles pour le Solo, la Coop et les futurs serveurs dédiés.
Des définitions d’armes, véhicules, ennemis et constructions chargées depuis des données validées.
Des cartes procédurales et communautaires décrites dans un format logique commun.

Les fondations techniques

Noyau JavaScript indépendant du DOM, de l’audio et du rendu Three.js.
Simulation à pas fixe, composants d’entités et registres de définitions.
Collisions simples séparées des modèles visuels ; conservation initiale de Cannon-es.
Identifiants stables, formats versionnés et génération reproductible à partir d’une seed.

Jalon : le Solo et la Coop utilisent les systèmes extraits, avec leurs mécaniques et sauvegardes vérifiées.

Pour les développeurs : définition ou instance ?

Une définition décrit un type d’objet et ses capacités. Une instance représente un objet précis, avec sa position, sa santé, son carburant ou son inventaire. Les identifiants des contenus seront préfixés par leur pack pour éviter les conflits entre auteurs.

Three.js restera chargé des meshes, animations, lumières et effets. La simulation produira des états et des événements sans devoir créer d’objet graphique.

Serveurs dédiés autoritaires

Un monde qui continue sans navigateur hôte.

Pour les communautés

Pack serveur Node.js pour VPS ou PC local, sans Canvas ni rendu graphique.
Configuration du nom, des slots, de la seed, de la difficulté, du loot et des cycles.
Sauvegardes locales, restauration après redémarrage et outils d’administration.
Annuaire de serveurs consultable depuis le jeu.

Une autorité claire

Connexions WebSocket sécurisées en wss://.
Validation serveur des déplacements, combats, inventaires et interactions.
Prédiction locale du joueur et interpolation des entités distantes.
Simulation et réplication limitées aux secteurs pertinents autour des joueurs.
Master Server PHP/MySQL : annonces authentifiées, heartbeats et expiration des serveurs inactifs.

Jalon : une partie dédiée fonctionne sans navigateur hôte, accepte plusieurs clients et retrouve son état après redémarrage.

Pour les hébergeurs : réseau et persistance

Le gameplay circulera directement entre les joueurs et le serveur dédié. Le site sera un annuaire et un service d’identité, pas un relais permanent des paquets de jeu. PeerJS restera le transport de la Coop actuelle, derrière une interface réseau commune.

Un serveur public devra disposer d’un certificat valide et d’une adresse accessible. Sur PC domestique, le port entrant et le CGNAT peuvent nécessiter une configuration ou un relais adapté. Les sauvegardes du monde resteront sur le serveur ; aucun accès direct au MySQL du site ne sera distribué.

Workshop & contenus déclaratifs

Créer des cartes et du contenu sans reconstruire le client.

Les créations prises en charge

Maps personnalisées en JSON : terrains, bâtiments, étages, colliders, escaliers, ressources et points de spawn.
Modèles GLB pour les armes, véhicules, ennemis et décors.
Statistiques, recettes et tables de loot configurables dans des formats documentés.
Catalogue Workshop avec auteurs, versions, dépendances et contrôle de publication.

Téléchargement et performances

Manifestes listant les versions, tailles et empreintes SHA-256 des fichiers.
Assets distribués en HTTPS, séparément du flux réseau de gameplay.
Cache Storage pour les fichiers ; IndexedDB pour les manifestes et métadonnées.
Téléchargement des seuls fichiers manquants ou modifiés.
Chargement progressif, modèles de qualité adaptée au mobile et budgets graphiques contrôlés.

Jalon : un pack ajoute une carte, une arme et un véhicule utilisant les capacités existantes, sans nouvelle compilation du client web.

Pour les créateurs : modèles et limites

Chaque modèle devra respecter un contrat : unités, dimensions, orientation, animations et points d’attache. Les véhicules préciseront leurs sièges, roues et sorties ; les armes leur prise en main et leur origine de tir. Les collisions seront définies séparément, sans convertir automatiquement un modèle détaillé en collider complexe.

La publication contrôlera notamment les triangles, textures, matériaux, animations et références externes. Les lumières importées resteront soumises aux limites du moteur. Les grandes cartes seront découpées en secteurs plutôt que chargées comme un unique JSON massif.

Modding avancé & scripts

Transformer les règles du monde grâce à une API serveur.

Des modes à inventer

Survie hardcore, événements scénarisés, défis coopératifs ou modes à objectifs.
Règles de respawn, conditions de victoire, récompenses et comportements de mission.
API événementielle : arrivée d’un joueur, mort, interaction et progression d’un objectif.
Données persistantes réservées à chaque extension.

Un noyau protégé

Scripts exécutés côté serveur avec une API versionnée et des permissions explicites.
Actions demandées au noyau, puis validées et répliquées aux clients.
Isolation en processus séparés et restrictions système pour les extensions tierces.
Budgets de calcul, délais d’exécution, diagnostics et gestion des erreurs.
Aucun téléchargement de JavaScript communautaire exécuté librement dans la page du joueur.

Jalon : un moddeur crée un mode via l’API publiée, sans modifier les structures internes de la simulation.

Pour les développeurs de modes : sécurité et compatibilité

Les règles déclaratives seront proposées avant les scripts avancés. Les extensions ne disposeront pas d’un accès libre aux fichiers, au réseau ou aux identifiants du serveur. Un Worker ou node:vm ne sera pas considéré comme une frontière de sécurité suffisante.

L’ordre des événements et les versions compatibles seront définis. Si une extension critique échoue, le mode devra être suspendu ou arrêté proprement, plutôt que poursuivre une partie aux règles incohérentes.

Quatre rôles complémentaires

Comment l’ensemble communique

Le Workshop distribue les contenus, le Master Server permet de trouver une partie, le serveur dédié décide de l’état du monde et le client affiche ce monde.

Publier & distribuer
Workshop
Catalogue PHP/MySQL, versions et dépendances. Les modèles, sons et maps sont servis depuis un stockage de fichiers adapté.
Découvrir & authentifier
Master Server
Liste des serveurs actifs, capacité, compatibilité et tickets de connexion. Les annonces expirent sans heartbeat.
Simuler & sauvegarder
Serveur dédié
Node.js headless, monde autoritaire, physique, IA, extensions et sauvegardes locales.
Jouer & afficher
Client navigateur
Three.js, UI, audio, cache des mods, prédiction et interpolation. Compatible PC et mobile selon les budgets des packs.

Les flux de données prévus
Liaison	Transport	Contenu
Créateur → Workshop	HTTPS	Publication du pack, validation et métadonnées.
Workshop → Client / Serveur	HTTPS	Manifestes, définitions et fichiers requis ; le serveur n’a pas besoin des assets purement visuels.
Serveur → Master Server	HTTPS authentifié	Enregistrement, heartbeat, version et nombre de joueurs.
Client ↔ Master Server	HTTPS	Annuaire, compatibilité et ticket de connexion.
Client ↔ Serveur dédié	WebSocket sécurisé	Intentions du joueur, snapshots et événements validés.

Du pack publié à la partie

Un Workshop pensé pour les joueurs et les moddeurs

Versions reproductibles

Chaque pack possède une identité, une version, des dépendances et des empreintes de fichiers. Le serveur fixe les versions requises pour que tous les participants utilisent le même contenu.

Un cache partagé entre serveurs

Un asset identique déjà téléchargé pourra être réutilisé sur un autre serveur. Les mises à jour concernent les fichiers modifiés, sans retélécharger systématiquement tout un pack.

Des outils de création

Schémas de données, exemples, conventions de modèles et outils de validation accompagneront les formats. Les publications devront préciser leurs droits d’utilisation et leurs auteurs.

La connexion à un serveur moddé

Lire la liste des packs et vérifier les versions du moteur, du protocole et des contenus.
Comparer le manifeste au cache et afficher le volume de téléchargement manquant.
Télécharger les fichiers requis, vérifier leur intégrité et les enregistrer dans le cache.
Préparer les ressources du secteur de départ, puis charger les secteurs suivants progressivement.
Rejoindre la simulation après confirmation que les contenus indispensables sont prêts.

Les quotas du navigateur et l’espace disponible varient. Le cache peut être évincé : un téléchargement ultérieur reste parfois nécessaire. Un outil de nettoyage et la gestion des erreurs de stockage feront partie du parcours.

Ce qui guide le développement

Compatibilité, maîtrise et transparence

Préserver les modes actuels

Le Solo restera local, la Coop conservera PeerJS et le dédié utilisera WebSocket. Les nouveaux systèmes seront intégrés progressivement, avec des sauvegardes versionnées.

Respecter le mobile

Un petit fichier peut coûter cher en mémoire GPU. Le poids téléchargé, les textures, les matériaux et le coût de simulation devront tous être contrôlés. Les limites de slots seront déterminées par des mesures.

Protéger les comptes

Les serveurs communautaires ne recevront pas les mots de passe ni les accès MySQL du site. Leur progression sera séparée des statistiques officielles, sauf validation explicite d’un serveur.