Où vit chaque chose
Un dossier au nom du jeu dans chaque service, et une responsabilité par module. C'est ce qui permet d'ajouter un système sans relire les autres.
- ReplicatedStorage : la configuration, les remotes nommés par intention, les types partagés, les utilitaires.
- ServerScriptService : un script d'amorçage qui charge des services — joueur, sauvegarde, économie, et un par système.
- StarterPlayerScripts : des contrôleurs clients fins, qui écoutent et animent.
- StarterGui : l'interface construite par un script client, jamais de logique de jeu.
Le serveur est la seule autorité
Monnaie, inventaire, progression, dégâts, achats : le client demande, le serveur décide et renvoie l'état. C'est la règle qui sépare un jeu qui survit à son succès d'un jeu dupliqué en une semaine.
Chaque remote vérifie le type de chaque argument, les bornes, l'existence de la cible, le droit du joueur, la distance quand c'est physique, et limite la fréquence d'appel par joueur. Refuser en silence suffit.
Relier le monde au code
Les positions et les prix ne vivent pas dans le code : ils vivent sur les objets, en attributs, et les scripts retrouvent ces objets par leurs tags avec CollectionService.
L'avantage se voit au premier équilibrage : régler un prix devient une modification dans Studio, pas une relecture de script.
Questions fréquentes
Un seul gros script, c'est vraiment un problème ?
Au-delà de quelques centaines de lignes, oui : Luau limite aussi le nombre de variables locales par script, et surtout une modification y devient risquée parce que tout est lié.