Chapitre 06 · Livret Dev

06.0 Objectif du livret

Ce livret s’adresse aux développeurs et aux leads techniques. Il traduit le cahier RP en un plan d’implémentation progressif pour amener le serveur à accueillir 100+ joueurs de façon stable.

Les phases ci-dessous sont conçues pour être itératives. À chaque étape, le serveur reste jouable et on augmente le niveau de complexité et de « temporalité ».

06.1 Phase 0 · Socle technique & perfs

Objectif : avoir un squelette RedM propre, mesurable, sans systèmes complexes.

• Créer le dépôt du framework maison (serveur/client Lua), config de base RedM.
• Mettre en place la base de données (MySQL/PostgreSQL) et les migrations initiales.
• Ajouter l’outillage : logs structurés, métriques, profilage serveur (tick time, mémoire, FPS).
• Implémenter :
  • Connexion et sélection de personnage basique.
  • Spawn initial sur Guarma pour tous les nouveaux personnages.
• Définir les objectifs de perfs :
  • Nombre de joueurs visé (100+ à terme, 40–60 pour les premiers tests).
  • Valeurs cibles pour tick time, FPS, latence.

06.2 Phase 1 · Framework « vanilla » stable (avec sas Guarma)

Objectif : un serveur RP jouable sans anomalies, pour ~60 joueurs, avec un sas d’arrivée contrôlé.

• Personnages & persistance :
  • Création de personnage, slots multiples, sauvegarde DB fiable.
  • Gestion d’un champ onboarding_state (guarma / ticket_ok / mainland) pour chaque personnage.
  • Inventaire simple, chevaux, quelques métiers légaux (fermier, chasseur, commerçant) décrits dans le Chapitre 02.
• Économie de base :
  • Une seule monnaie (dollars), revenus des métiers légaux, dépenses de base.
  • Aucun fragment temporel ni artefact rare pour l’instant.
  • Activités de Guarma peu rémunératrices, pensées comme tutoriel RP.
• Habitations & camps :
  • Quelques propriétés achetables, coffres persistants, permissions minimales (côté continent).
• Outils MJ minimum :
  • TP, heal, spectate, commandes pour corriger un personnage buggué.
  • Commandes pour donner/retirer un « ticket pour l’Amérique ».
  • Journal MJ manuel (suivi simplifié avant ChronoSync).
• Tests de charge :
  • Sessions avec 40–60 joueurs pour valider la stabilité du socle.

06.3 Phase 2 · Économie avancée & réputation

Objectif : préparer la profondeur de jeu pour un grand nombre de joueurs.

• Étendre l’économie (cf. 02.5) :
  • Ajouter les fragments temporels + rumeurs comme monnaies supplémentaires.
  • Implémenter conversions contrôlées (MJ + logs) selon les règles décrites.
• Réputation & casier :
  • Stocker en base les axes de réputation et le casier judiciaire.
  • Appliquer quelques effets simples : prix, accès à des zones, réactions PNJ.
• Métiers illégaux de base :
  • Contrebandier, bandit, chasseur de primes, avec rémunération et risques cohérents.
• Outillage MJ :
  • Écrans pour voir/modifier réputations, valider transactions, consulter l’historique.
• Re-tests de charge :
  • Vérifier que l’augmentation du trafic DB (transactions, réputations) reste maîtrisée.

06.4 Phase 3 · Anomalies & missions structurées

Objectif : donner l’identité « temporelle » du serveur sans encore toucher aux buckets.

• Système d’anomalies global (cf. 03.3) :
  • Catalogue de sites (zones, coordonnées, risques).
  • Jauge d’instabilité globale liée aux événements.
  • Apparition contrôlée d’anomalies avec FX raisonnables.
• Backend de missions :
  • Implémenter la structure générique de mission (identifiant, type, localisation, factions, récompenses).
  • Développer au moins 2–3 missions vitrines : Horloger, Capsule Fantôme, Enfant prophétique.
• Outils MJ associés :
  • Déclenchement, annulation, visualisation de l’état d’une mission.
  • Intégration avec le Journal MJ et, à terme, ChronoSync.
• Tests RP/MJ :
  • Soirées d’événements avec 50–70 joueurs pour calibrer rythme et charge.

06.5 Phase 4 · Temporalité avancée (buckets & artefacts)

Objectif : introduire les mécaniques les plus lourdes une fois le reste stabilisé.

• Routing buckets & scènes instanciées (cf. 02.0, 02.15, 05.10) :
  • Gestionnaire de buckets : création, assignation, retour propre en monde principal.
  • 1–2 scénarios de flashbacks courts (durée < 15 minutes, groupes de 4–6 joueurs).
• Artefacts & gadgets temporels (cf. 02.3, 02.6) :
  • Première vague d’artefacts : balise de retour, scanner de faille, horloge éclatée.
  • Gestion des charges, cooldowns, logs MJ (utilisation, effets sur la jauge).
• ChronoSync v1 :
  • Dashboard CEF simple listant anomalies, jauge d’instabilité, quelques filtres.
  • Pas de design complexe au début, priorité au fonctionnel.
• Tests ciblés :
  • Scènes instanciées avec 4–6 joueurs pendant qu’un event global tourne ailleurs.

06.6 Phase 5 · Mise à l’échelle & contenu large

Objectif : viser durablement 100+ joueurs avec assez de choses à faire.

• Ajustements de performances :
  • Calibrer densité PNJ, fréquence des anomalies et intensité des FX.
  • Utiliser les métriques pour fixer des plafonds (PNJ par zone, anomalies actives, artefacts simultanés).
• Contenu large spectre :
  • Étendre les métiers, mini-jeux, lieux RP pour répartir 100 joueurs sur la carte.
  • Déployer plus de missions « secondaires » moins coûteuses que les anomalies.
• Outillage MJ & QA :
  • Renforcer le plan de tests du Chapitre 04 (tests hebdo ChronoSync, scènes instanciées, économie).
  • Automatiser au maximum les alertes (webhooks, dashboards).

06.7 Lien avec les autres chapitres

• Le Chapitre 01 (Lore) reste la référence pour la cohérence narrative.
• Le Chapitre 02 décrit les systèmes cibles : ce livret indique simplement dans quel ordre les aborder.
• Le Chapitre 03 fournit des exemples concrets de missions à implémenter en priorité.
• Le Chapitre 04 (Livret MJ) sert de manuel d’exploitation une fois les outils livrés.
• Le Chapitre 05 (Production) encadre l’équipe, la roadmap et les risques ; ce livret Dev en est le pendant plus opérationnel côté technique.