Le modèle client/serveur

Jusqu’ici, tes scripts fonctionnaient… quand tu testais seul. Mais un jeu Roblox est multijoueur par défaut : plusieurs personnes jouent ensemble, chacune sur son appareil. Qui décide de ce qui se passe vraiment ? Qui voit quoi ? Ce module répond à ces questions, et il se termine par la sécurisation de l’Obby des Nuages. Cette première leçon pose les fondations : sans elles, impossible de protéger ton jeu.

Un serveur, plusieurs clients

Quand quelqu’un lance ton jeu, Roblox démarre un serveur : un ordinateur dans un centre de données de Roblox. Chaque joueur qui rejoint la partie s’y connecte avec son client, c’est-à-dire l’application Roblox sur son PC, son téléphone ou sa console.

• Le serveur est l’arbitre. La documentation Roblox le décrit comme « l’autorité finale » sur l’état du jeu : c’est lui qui garde tous les clients synchronisés.
• Chaque client reçoit une copie du jeu, affiche le monde en 3D, lit les touches et l’écran tactile, puis exécute les scripts prévus pour le client.

Une bonne image : un match de foot. Le serveur, c’est l’arbitre et le tableau de score officiel. Les clients, ce sont les joueurs sur le terrain. Un joueur peut crier « but ! », mais seul l’arbitre décide si le but compte.

Qui exécute quel script ?

Tu as découvert les trois types de scripts au module 3. Voici où chacun tourne :

Quelques règles à retenir :

• ServerScriptService (le service des scripts serveur) n’est jamais envoyé aux clients. C’est l’endroit idéal pour la logique du jeu : pièces, checkpoints, boutique, sauvegarde.
• ServerStorage (le stockage serveur) n’est pas envoyé aux clients non plus, mais les scripts ne s’y exécutent pas. On y range des objets et des ModuleScripts serveur.
• ReplicatedStorage (le stockage répliqué) est visible des deux côtés. On y met ce qui doit être partagé : ModuleScripts communs, RemoteEvents, catalogue de la boutique…
• Un LocalScript ne s’exécute pas depuis ReplicatedStorage ni depuis ServerScriptService.

La réplication : comment tout le monde reste synchronisé

La réplication, c’est le mécanisme qui recopie les changements d’un côté à l’autre. D’après la documentation, elle synchronise le modèle de données (les objets et leurs propriétés), la simulation physique et le chat.

Du serveur vers les clients : automatique

Quand un Script serveur crée une Part, change une couleur ou supprime un objet dans le Workspace, ce changement est envoyé automatiquement à tous les clients. C’est pour ça qu’une kill brick ou une pièce gérées côté serveur fonctionnent pour tout le monde.

Du client vers le serveur : non, en règle générale

L’inverse n’est pas vrai. La documentation de ReplicatedStorage le résume ainsi : les changements faits sur le client persistent localement mais ne sont pas répliqués au serveur, et le serveur peut les écraser à tout moment.

Concrètement, si un LocalScript :

• change la couleur d’une plateforme → seul ce joueur la voit changer ;
• crée une Part → elle n’existe que sur son écran ;
• modifie une IntValue de pièces (un objet qui stocke un nombre entier, comme le compteur de pièces que tu créeras au module 5) → le serveur garde l’ancienne valeur.

C’est une protection essentielle. Imagine le chaos si n’importe quel joueur pouvait supprimer la carte pour tout le monde !

Voici l’expérience classique pour le constater. Crée une Part ancrée nommée Plateforme dans le Workspace, puis ce LocalScript :

-- LocalScript placé dans StarterPlayer > StarterPlayerScripts (côté client)
local Workspace = game:GetService("Workspace")

-- On attend que la Part soit arrivée sur le client
local plateforme = Workspace:WaitForChild("Plateforme")

task.wait(3)
-- Ce changement n'existe QUE sur l'écran de ce joueur
plateforme.Color = Color3.fromRGB(255, 0, 0)
print("Côté client : la plateforme est rouge… pour moi seulement !")

Puis compare avec ce Script serveur :

-- Script placé dans ServerScriptService (côté serveur)
local Workspace = game:GetService("Workspace")

local plateforme = Workspace:WaitForChild("Plateforme")

task.wait(3)
-- Le serveur fait le changement : il est répliqué à TOUS les clients
plateforme.Color = Color3.fromRGB(0, 170, 255)
print("Côté serveur : la plateforme est bleue pour tout le monde")

Les exceptions : ce que le client contrôle vraiment

Si tout restait local, ton personnage ne pourrait pas bouger aux yeux des autres ! Il existe donc des exceptions importantes.

La propriété réseau (network ownership)

Roblox répartit les calculs de physique entre le serveur et les clients. Chaque Part non ancrée (Anchored décoché) a un propriétaire réseau : le serveur ou un client. Le propriétaire calcule sa physique, puis envoie sa position et son mouvement aux autres.

D’après la documentation :

• le serveur possède toujours les Parts ancrées, et on ne peut pas changer cela ;
• pour les Parts non ancrées, le moteur donne automatiquement la propriété au client dont le personnage est proche (en tenant compte de la capacité de son appareil) ;
• le joueur contrôle la physique de son propre personnage.

Pourquoi ? Pour la réactivité : ton personnage réagit instantanément à tes touches, sans attendre l’aller-retour vers le serveur.

Ce qui part donc du client

• La position et les mouvements de son personnage (marcher, sauter, tomber…). Les états du Humanoid (l’objet qui fait marcher et sauter un personnage) sont aussi communiqués au serveur.
• La physique des Parts non ancrées qu’il possède : une caisse qu’il pousse, un véhicule qu’il conduit.
• Les animations jouées sur son personnage, via l’Animator du personnage (tu verras les animations au module 5).

Le revers de la médaille

La documentation est très claire : Roblox ne peut pas vérifier les calculs de physique faits par un client. Un tricheur peut donc envoyer de fausses données : se téléporter, traverser les murs, voler, aller trop vite. Il peut même manipuler les événements Touched (contact) et les déclencher à n’importe quelle distance.

Retiens bien ceci, on s’en servira dans tout le module : la position d’un personnage et les contacts qu’il provoque ne sont pas des preuves fiables. Le serveur doit les vérifier.

Reprendre la main sur une Part importante

Pour une Part non ancrée qui compte vraiment pour le gameplay, un Script serveur peut forcer le serveur comme propriétaire avec SetNetworkOwner(nil). La documentation conseille de le faire avec modération, car la physique peut sembler saccadée pour les joueurs.

-- Script placé dans ServerScriptService (côté serveur)
local Workspace = game:GetService("Workspace")

-- Une caisse non ancrée qui sert d'obstacle important
local caisse = Workspace:WaitForChild("CaisseObstacle")

if caisse:IsA("BasePart") and not caisse.Anchored then
	-- nil = le serveur devient propriétaire : les clients ne simulent plus sa physique
	caisse:SetNetworkOwner(nil)
end

Pour l’Obby des Nuages, la règle est simple : ancre toutes tes plateformes. Elles appartiennent alors au serveur, et aucun client ne peut les déplacer pour les autres. Les plateformes mobiles du module 5 seront animées par le serveur.

Penser « serveur d’abord »

Pour chaque fonctionnalité, pose-toi deux questions :

1. Qui doit voir le résultat ? Tout le monde → le serveur fait le changement. Seulement ce joueur (un menu, un son d’interface, un effet de caméra) → le client peut le faire.
2. Est-ce que ça compte pour le jeu ? Si oui (récompense, progression, achat), le serveur décide, même si c’est le client qui en fait la demande.

Mais comment un client « demande » quelque chose au serveur, par exemple « je veux acheter cette traînée » ? Avec des RemoteEvents, le sujet de la prochaine leçon.

📌 Ce qu’il faut retenir

• Une partie Roblox = un serveur (l’arbitre, source de vérité) + un client par joueur.
• Les changements du serveur sont répliqués automatiquement à tous les clients.
• Les changements faits par un client restent locaux, sauf exceptions.
• Exceptions : le personnage du joueur, la physique des Parts non ancrées qu’il possède (network ownership) et les animations de son personnage.
• Le serveur ne peut pas vérifier la physique d’un client : positions et contacts (Touched) ne sont pas des preuves.
• La logique importante va dans ServerScriptService ; ce qui est partagé va dans ReplicatedStorage.

📚 Sources et pour aller plus loin

• Client-server runtime — documentation Roblox
• Script types and locations — documentation Roblox
• Network ownership — documentation Roblox
• Network ownership, movement validation, and physics — sécurité, documentation Roblox
• ReplicatedStorage — référence de l’API
• Workspace.FilteringEnabled — référence de l’API
• Animator — référence de l’API (réplication des animations)
• Studio testing modes — documentation Roblox
• Server authority model — documentation Roblox
• Ship Fair And Competitive Games with Server Authority — annonce officielle de Roblox sur le DevForum (9 juillet 2026)
• Security and cheat mitigation tactics — documentation Roblox (capacités d’un tricheur)