Client vs Serveur

0. Réflexe architecture avant code

Dans ce module, la question la plus importante n'est pas "quel code écrire ?" mais où exécuter ce code. Commence chaque fonctionnalité en séparant les responsabilités : affichage et input côté client, validation et données côté serveur.

Si un joueur peut tricher en modifiant son client, alors la logique est mal placée. Le serveur doit rester l'autorité finale pour les coins, XP, inventaire, dégâts et récompenses.

0.5 Décider rapidement où placer le code

Pose ce filtre simple : si la donnée influence l'équité du jeu, elle doit être validée serveur. Si la donnée concerne l'affichage local, elle peut rester côté client.

Ce choix évite deux problèmes majeurs : triche côté client et scripts trop lents côté serveur pour des effets purement visuels.

• Erreur fréquente : donner des coins depuis un LocalScript
• Erreur fréquente : déclencher un RemoteEvent sans validation
• Erreur fréquente : dupliquer la même logique des deux côtés
• Erreur fréquente : ne pas traiter les cas de désynchronisation

0.8 Parcours pédagogique section par section

Section 1 - Client vs Serveur

Définition : Deux environnements d'exécution avec rôles distincts.

Pourquoi : Séparer affichage local et autorité de jeu.

Quand l'utiliser : Sur chaque feature, décider d'abord l'emplacement logique.

Anti-pattern : Calculer des données sensibles côté client.

Exercice guidé : Classe 10 actions de jeu en client ou serveur.

Résumé : Le bon placement du code évite bugs et triche.

Section 2 - Types de scripts

Définition : Script, LocalScript et ModuleScript ont des usages complémentaires.

Pourquoi : Organiser proprement la logique et réutiliser le code.

Quand l'utiliser : Script serveur pour autorité, LocalScript pour UX, ModuleScript pour partage.

Anti-pattern : Mettre toute la logique dans un seul fichier.

Exercice guidé : Découpe une feature en 3 scripts selon les responsabilités.

Résumé : Le type de script choisi impacte sécurité et maintenabilité.

Section 3 - RemoteEvents

Définition : Message asynchrone entre client et serveur.

Pourquoi : Synchroniser l'intention joueur et la logique autorisée.

Quand l'utiliser : Actions sans retour immédiat obligatoire.

Anti-pattern : Accepter aveuglément les arguments reçus.

Exercice guidé : Crée un RemoteEvent d'achat avec validation serveur.

Résumé : Un événement réseau doit toujours être validé côté serveur.

Section 4 - RemoteFunctions

Définition : Appel réseau avec réponse attendue.

Pourquoi : Obtenir une valeur autorisée avant de poursuivre.

Quand l'utiliser : Vérification d'accès, récupération de données ponctuelles.

Anti-pattern : Appels bloquants répétés qui dégradent la fluidité.

Exercice guidé : Demande au serveur si un joueur peut ouvrir une zone premium.

Résumé : RemoteFunction est utile mais doit rester ciblée et mesurée.

1. Client vs Serveur : Qui Fait Quoi ?

Imagine ton jeu comme un restaurant. Le serveur c'est la cuisine (prépare tout), le client c'est le client du restaurant (affiche et interagit).

2. Les Types de Scripts

Roblox propose différents types de scripts selon où tu veux exécuter le code :

3. Communiquer : RemoteEvents

Les RemoteEvents sont le pont entre client et serveur. Ils permettent d'envoyer des messages dans les deux sens.

3.1 Client ? Serveur (FireServer)

Le joueur veut acheter quelque chose ? Le client envoie une demande au serveur.

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local acheterEvent = ReplicatedStorage:WaitForChild("AcheterItem")

-- Quand le joueur clique sur le bouton "Acheter"
boutonAcheter.MouseButton1Click:Connect(function()
    local itemVoulu = "Epee"
    acheterEvent:FireServer(itemVoulu)  -- Envoie au serveur
end)

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local acheterEvent = ReplicatedStorage:WaitForChild("AcheterItem")

acheterEvent.OnServerEvent:Connect(function(joueur, itemVoulu)
    print(joueur.Name .. " veut acheter : " .. itemVoulu)
    
    -- Vérifie si le joueur a assez d'argent (CÔTÉ SERVEUR !)
    if joueur.leaderstats.Coins.Value >= 100 then
        joueur.leaderstats.Coins.Value -= 100
        -- Donne l'item...
        print("Achat réussi !")
    else
        print("Pas assez de coins !")
    end
end)

3.2 Serveur ? Client (FireClient)

Le serveur veut envoyer une notification à un joueur spécifique :

local notifEvent = ReplicatedStorage:WaitForChild("Notification")

-- Envoie une notif à UN joueur
notifEvent:FireClient(joueur, "Tu as gagné 100 XP !")

-- Envoie à TOUS les joueurs
notifEvent:FireAllClients("Un boss est apparu !")

local notifEvent = ReplicatedStorage:WaitForChild("Notification")

notifEvent.OnClientEvent:Connect(function(message)
    print("Notification : " .. message)
    -- Affiche dans l'interface...
end)

4. RemoteFunctions (Appels avec Réponse)

Les RemoteFunctions permettent d'envoyer une requête ET d'attendre une réponse. Comme un appel téléphonique plutôt qu'un SMS.

-- CLIENT : Demande les stats du joueur
local getStats = ReplicatedStorage:WaitForChild("GetStats")

local mesStats = getStats:InvokeServer()  -- Attend la réponse
print("J'ai " .. mesStats.coins .. " coins")

-- SERVEUR : Répond à la demande
getStats.OnServerInvoke = function(joueur)
    return {
        coins = joueur.leaderstats.Coins.Value,
        level = joueur.leaderstats.Level.Value
    }
end