Catégorie : ROBLOX-NIVEAU02

Pousser un bloc sans code complexe

Ce script rend un bloc poussable par le joueur en utilisant directement le moteur physique de Roblox, sans avoir besoin de code complexe pour détecter les contacts. part.Anchored = false est la ligne essentielle : elle « détache » la Part du monde et lui permet de bouger sous l’effet de forces physiques (comme la poussée du joueur). part.CanCollide = true garantit que le joueur ne traverse pas le bloc mais rentre réellement dedans, ce qui déclenche la poussée physique naturelle.

PhysicalProperties.new(...) personnalise le comportement physique du bloc : ici, une densité basse (0.2) rend l’objet léger et facile à pousser, une friction basse (0.2) le fait glisser facilement, et une élasticité (0.5) lui donne un léger effet de rebond.

part.CustomPhysicalProperties = physicalProperties applique ces réglages personnalisés à la Part, plutôt que d’utiliser les valeurs par défaut de Roblox (qui donneraient un objet plus lourd et moins glissant).

local part = script.Parent

local physicalProperties = PhysicalProperties.new(
	0.2,  -- Density (densité, plus c'est bas plus c'est léger à pousser)
	0.2,  -- Friction
	0.5,  -- Elasticity
	1,    -- FrictionWeight
	1     -- ElasticityWeight
)

part.Anchored = false
part.CanCollide = true
part.CustomPhysicalProperties = physicalProperties

Pousser un bloc avec une impulsion

Ce script combine deux mécanismes pour rendre un bloc poussable :

1. Configuration physique de base : le bloc devient mobile (Anchored = false) et reçoit des propriétés physiques personnalisées (densité, friction, élasticité) qui définissent son comportement naturel (léger/lourd, glissant/collant, rebondissant ou non).
2. Poussée scriptée additionnelle : en plus de la physique naturelle, le script détecte quand un joueur touche le bloc et lui applique une impulsion (un « coup de pousse ») dans la direction où le joueur regarde/avance, grâce à ApplyImpulse.

Détail du fonctionnement

• humanoidRootPart.CFrame.LookVector récupère un vecteur représentant la direction vers laquelle le joueur est orienté — c’est cette direction qui détermine où le bloc va être poussé.
• part:ApplyImpulse(direction * PUSH_FORCE * part:GetMass()) calcule la force de poussée en tenant compte de la masse du bloc (GetMass()) : plus le bloc est lourd, plus il faut une impulsion importante pour le déplacer de la même façon (comme dans la vraie vie).
• part.Touched:Connect(onTouched) signifie que cette poussée se déclenche à chaque fois que quelque chose touche le bloc — donc potentiellement plusieurs fois par seconde si le joueur reste collé dessus.

Pourquoi combiner les deux mécanismes ?

La physique seule (Anchored = false + CanCollide = true) suffit déjà à rendre le bloc poussable naturellement. Mais ajouter une impulsion scriptée permet de renforcer ou contrôler cet effet — par exemple pour que la poussée soit plus franche et immédiate, même si le joueur touche le bloc à faible vitesse.

QCM pour mieux comprendre

1. Que se passe-t-il si on met part.Anchored = true dans ce script ?
A. Le bloc devient plus facile à pousser
B. Le bloc ne pourra plus bouger du tout, malgré l’impulsion appliquée
C. Le bloc disparaît
D. Rien ne change

2. Que représente humanoidRootPart.CFrame.LookVector ?
A. La vitesse du joueur
B. La direction vers laquelle le joueur regarde/avance
C. La position exacte du joueur
D. Le nom du joueur

3. Pourquoi multiplie-t-on la force par part:GetMass() ?
A. Pour que la poussée soit toujours la même, peu importe le poids du bloc
B. Pour adapter la force de poussée au poids réel du bloc (plus lourd = plus de force nécessaire)
C. Pour calculer la vitesse du joueur
D. Pour rendre le bloc invisible

4. Que fait part:ApplyImpulse(...) ?
A. Il déplace instantanément le bloc à une position précise
B. Il applique une force ponctuelle qui pousse le bloc dans une direction donnée
C. Il détruit le bloc
D. Il change la couleur du bloc

5. Quand la fonction onTouched se déclenche-t-elle ?
A. Une seule fois au démarrage du jeu
B. À chaque fois qu’un objet (joueur ou autre) touche le bloc
C. Uniquement quand le joueur saute sur le bloc
D. Toutes les 5 secondes automatiquement

6. Si on augmente la valeur de PUSH_FORCE, que se passe-t-il ?
A. Le bloc devient plus lourd visuellement
B. Le bloc sera poussé plus fort/plus loin à chaque contact
C. Le joueur devient plus rapide
D. Rien, cette variable n’est pas utilisée dans le script

7. Pourquoi le script vérifie-t-il if not humanoid or not humanoidRootPart then return end ?
A. Pour vérifier que c’est bien un joueur (ou personnage) qui touche le bloc, et pas un autre objet
B. Pour supprimer le joueur s’il n’a pas de vie
C. Pour ralentir le jeu volontairement
D. Ce n’est pas nécessaire, cette ligne ne sert à rien

local part = script.Parent

local physicalProperties = PhysicalProperties.new(
	0.5,  -- Density (densité, plus c'est bas plus c'est léger à pousser)
	0.5,  -- Friction
	0.5,  -- Elasticity
	1,    -- FrictionWeight
	1     -- ElasticityWeight
)

part.Anchored = false
part.CanCollide = true
part.CustomPhysicalProperties = physicalProperties

local PUSH_FORCE = 2 -- Intensité de la poussée

local function onTouched(hit)
	local character = hit.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	local humanoidRootPart = character and character:FindFirstChild("HumanoidRootPart")
	if not humanoid or not humanoidRootPart then return end

	-- Calcule la direction dans laquelle le joueur se déplace
	local direction = humanoidRootPart.CFrame.LookVector

	-- Applique une impulsion dans cette direction
	part:ApplyImpulse(direction * PUSH_FORCE * part:GetMass())
end

part.Touched:Connect(onTouched)

Pousser plusieurs BLOCs

local partFolder = script.Parent

local physicalProperties = PhysicalProperties.new(
	0.5,  -- Density (densité, plus c'est bas plus c'est léger à pousser)
	0.5,  -- Friction
	0.5,  -- Elasticity
	1,    -- FrictionWeight
	1     -- ElasticityWeight
)


local PUSH_FORCE = 20 -- Intensité de la poussée

local function onTouched(hit, part)
	local character = hit.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	local humanoidRootPart = character and character:FindFirstChild("HumanoidRootPart")
	if not humanoid or not humanoidRootPart then return end

	-- Calcule la direction dans laquelle le joueur se déplace
	local direction = humanoidRootPart.CFrame.LookVector

	-- Applique une impulsion dans cette direction
	part:ApplyImpulse(direction * PUSH_FORCE * part:GetMass())
end

for _, part in partFolder:GetChildren() do
	if part:IsA("BasePart") then
		
		part.Anchored = false
		part.CanCollide = true
		part.CustomPhysicalProperties = physicalProperties		
		part.Touched:Connect(onTouched, part)
	end
end

À quoi sert ce script ?

Ce script permet de créer un parcours de course :

• Des checkpoints invisibles qui font respawn le joueur au bon endroit s’il tombe ou meurt
• Un compteur de tours : combien de fois le joueur a terminé le parcours
• Un meilleur temps (record) qui s’affiche et se met à jour automatiquement

Comment l’utiliser dans votre jeu

Étape 1 : Créer les parts de checkpoint

1. Créez un dossier (Folder) nommé PartSpawnNiv dans le Workspace.
2. Créez un dossier GAME dans le Workspace qui contiendra ce dossier PartSpawnNiv.
3. Dans PartSpawnNiv, créez une Part pour chaque checkpoint de votre parcours (une au départ, une à chaque étape importante, une à l’arrivée).
4. Nommez-les avec des numéros dans l’ordre : "1", "2", "3", etc. ; c’est très important, le script trie les checkpoints selon ces numéros !

Workspace
 └── GAME
      └── PartSpawnNiv
           ├── 1  (départ)
           ├── 2
           ├── 3
           └── 4  (arrivée)

Le script rend ces parts automatiquement invisibles et traversables : pas besoin de le faire vous-même !

Étape 2 : Créer l’interface (GUI)

Dans StarterGui, créez un ScreenGui contenant :

• Un Frame nommé Counter avec un TextLabel nommé CounterLabel (nombre de tours)
• Un Frame nommé Best avec un TextLabel nommé BestLabel (meilleur temps)

Étape 3 : Placer le script

Placez ce script en tant que Script (serveur, pas LocalScript) directement dans ServerScriptService.

Comment fonctionne le script (en 6 points)

1. Au démarrage, le script range tous les checkpoints du dossier PartSpawnNiv dans l’ordre de leurs numéros, puis les rend invisibles et traversables.
2. Quand un joueur touche un checkpoint, le script vérifie qui il est, puis retient dans un tableau playersProgression : la part actuelle, le nombre de tours, l’heure de départ, et le meilleur temps.
3. Si le joueur touche le checkpoint n°1 juste après avoir touché le DERNIER checkpoint, le script comprend qu’il a terminé un tour complet : il incrémente le compteur et compare le temps réalisé au record.
4. Si le joueur meurt, l’événement CharacterAdded se déclenche : le script téléporte automatiquement le joueur au-dessus du dernier checkpoint touché (et pas au tout début du parcours !).
5. Le tableau playersProgression retient les informations de chaque joueur séparément, grâce à son UserId (un peu comme une fiche personnelle par joueur).
6. Quand un joueur quitte le jeu, ses informations sont automatiquement supprimées du tableau pour ne pas garder des données inutiles en mémoire.

Pourquoi utiliser un tableau, et que contient playersProgression ?

Pourquoi a-t-on besoin d’un tableau ici ?

Imagine que plusieurs joueurs jouent en même temps sur ton parcours. Le script doit se souvenir, pour chaque joueur individuellement :

• à quel checkpoint il en est
• depuis quand il a commencé son tour actuel
• combien de tours il a déjà faits
• son meilleur temps

Si le script utilisait une seule variable simple (par exemple local spawnActuel = ...), cette variable serait partagée par tous les joueurs — dès qu’un 2ème joueur touche un checkpoint, ça écraserait la progression du 1er joueur ! Ce serait comme si tout le monde partageait le même carnet de notes : la dernière personne qui écrit efface ce que l’autre avait noté.

Un tableau permet de créer une « fiche » séparée pour chaque joueur, un peu comme un casier avec un tiroir par élève dans une salle de classe.

Qu’est-ce qu’un tableau d’informations (une table Lua) ?

En Lua, une table peut fonctionner comme un dictionnaire : au lieu d’accéder à une information par un numéro de position (comme dans une liste), on y accède par une clé (un identifiant unique), et chaque clé pointe vers une valeur.

playersProgression = {
	[12345] = { ... },  -- clé = UserId du joueur 1
	[67890] = { ... },  -- clé = UserId du joueur 2
}

C’est comme un répertoire téléphonique : la clé, c’est le nom de la personne ; la valeur, c’est son numéro. Ici, la clé est le UserId (identifiant unique de chaque joueur sur Roblox), et la valeur est une autre table qui contient toutes les infos de progression de ce joueur précis.

Pourquoi utiliser le UserId comme clé ?

Parce que chaque joueur a un UserId unique et permanent sur Roblox — contrairement à son pseudo qui pourrait théoriquement changer, ou à sa position dans une liste qui peut varier si un joueur quitte. Utiliser le UserId garantit qu’on retrouve toujours la bonne fiche pour le bon joueur, même avec plusieurs joueurs connectés simultanément.

Le contenu détaillé de playersProgression[UserId]

Pour un joueur donné, la table stockée ressemble à ceci :

playersProgression[12345] = {
	spawn = <référence à la Part checkpoint>,
	course = 2,            -- nombre de tours réalisés
	start = 1735689042.5,  -- temps de démarrage du tour
	best = 45.32,          -- temps du meilleur parcours
}

QCM pour vérifier la compréhension

1. Pourquoi faut-il nommer les checkpoints « 1 », « 2 », « 3 »… et pas « Depart », « Milieu », « Fin » ?
A. Pour que ce soit plus joli dans l’Explorer
B. Parce que le script trie les checkpoints selon ces numéros pour connaître leur ordre
C. Ça n’a aucune importance, on peut les nommer comme on veut
D. Parce que Roblox l’exige pour toutes les Parts

2. Que se passe-t-il quand un joueur meurt en plein milieu du parcours ?
A. Il recommence tout le parcours depuis le début
B. Il respawn au dernier checkpoint qu’il a touché
C. Le jeu se ferme
D. Son compteur de tours est remis à zéro

3. Comment le script sait-il qu’un joueur a terminé un tour complet ?
A. Quand il touche n’importe quel checkpoint
B. Quand il touche le checkpoint n°1 juste après avoir touché le tout dernier checkpoint
C. Quand il appuie sur une touche spéciale
D. Automatiquement après 60 secondes

4. Pourquoi les checkpoints sont-ils rendus invisibles et traversables (CanCollide = false) ?
A. Pour que le joueur ne les voie pas et ne soit pas bloqué en les traversant
B. Pour que le jeu soit plus rapide
C. Pour économiser de la mémoire
D. Ce n’est pas obligatoire, c’est juste un choix esthétique

5. À quoi sert le UserId du joueur dans le tableau playersProgression ?
A. À afficher le nom du joueur à l’écran
B. À retenir séparément la progression de CHAQUE joueur individuellement
C. À bannir les joueurs trichent
D. À compter le nombre total de joueurs connectés

6. Que se passe-t-il si deux checkpoints ont accidentellement le même numéro (ex: deux parts nommées « 3 ») ?
A. Rien, le script gère ça automatiquement
B. Le parcours pourrait ne pas fonctionner correctement, car l’ordre ne serait plus fiable
C. Le jeu affiche une erreur et s’arrête
D. Roblox choisit au hasard laquelle utiliser

7. Pourquoi utilise-t-on un Script (serveur) et pas un LocalScript pour ce système ?
A. Parce que le compteur de tours et le meilleur temps doivent être valables pour tout le monde, gérés par un seul endroit fiable (le serveur)
B. Parce que les LocalScripts ne fonctionnent pas avec les Parts
C. Ça n’a pas d’importance, les deux marcheraient pareil
D. Parce que c’est plus rapide à écrire

-- ═══════════════════════════════════════
-- SERVICES ET RÉFÉRENCES
-- ═══════════════════════════════════════
local Players = game:GetService("Players")
local Game = workspace.GAME

local SpawnFolder = Game:WaitForChild("PartSpawnNiv", true)

local baseplate = workspace:FindFirstChild("Baseplate")
if baseplate then
	baseplate:Destroy()
end

-- Tableau des joueurs en cours de partie avec l'étape mémorisée
local playersProgression = {}

-- Tableau de toutes les étapes du jeu, triées par nom pour garantir l'ordre
local spawnsList = SpawnFolder:GetChildren()
table.sort(spawnsList, function(a, b)
	return tonumber(a.Name) < tonumber(b.Name)
end)
local lastSpawnIndex = #spawnsList

local function formatTime(t)
	local minutes = math.floor(t / 60)
	local seconds = math.floor(t % 60)
	local centiemes = math.floor((t * 100) % 100)
	return string.format("%02d:%02d.%02d", minutes, seconds, centiemes)
end

-- ═══════════════════════════════════════
-- RESPAWN AU DERNIER CHECKPOINT
-- ═══════════════════════════════════════
local function respawnAuCheckpoint(player)
	local progression = playersProgression[player.UserId]
	if not progression or not progression.spawn then return end

	local character = player.Character
	if not character then return end

	local humanoidRootPart = character:FindFirstChild("HumanoidRootPart")
	if not humanoidRootPart then return end

	local spawn = progression.spawn
	local targetPosition = spawn.Position + Vector3.new(0, (spawn.Size.Y / 2) + 2, 0)
	humanoidRootPart.CFrame = CFrame.new(targetPosition)
end

-- ═══════════════════════════════════════
-- GESTION DU CHARGEMENT DES JOUEURS
-- ═══════════════════════════════════════
local function initPlayer(player)
	player.CharacterAdded:Connect(function(character)
		character:WaitForChild("HumanoidRootPart")
		respawnAuCheckpoint(player)
	end)
end

Players.PlayerAdded:Connect(initPlayer)
Players.PlayerRemoving:Connect(function(player)
	playersProgression[player.UserId] = nil
end)

-- ═══════════════════════════════════════
-- CHARGEMENT DES ÉTAPES ET DÉTECTION DES CHECKPOINTS
-- ═══════════════════════════════════════
for index, spawn in ipairs(spawnsList) do
	if spawn:IsA("BasePart") then
		spawn.Transparency = 1
		spawn.CanCollide = false
		spawn.Anchored = true

		spawn.Touched:Connect(function(hit)
			local player = Players:GetPlayerFromCharacter(hit.Parent)
			if not player then return end

			local progression = playersProgression[player.UserId]

			-- Ignore si le joueur est déjà sur ce checkpoint
			if progression and progression.spawn == spawn then return end

			if not progression then
				playersProgression[player.UserId] = {
					spawn = spawn,
					course = 0,
					start = tick(),
					best = 0,
					counterLabel = player.PlayerGui.ScreenGui.Counter.CounterLabel,
					bestLabel = player.PlayerGui.ScreenGui.Best.BestLabel,
				}
				return
			end

			-- Tour complet détecté : dernier checkpoint -> premier checkpoint
			if index == 1 and progression.spawn == spawnsList[lastSpawnIndex] then
				progression.course += 1
				progression.counterLabel.Text = string.format("%02d", progression.course)

				local finishTime = tick() - progression.start
				if progression.best == 0 or finishTime < progression.best then
					progression.best = finishTime
				end
				progression.bestLabel.Text = formatTime(progression.best)
			end

			progression.spawn = spawn
			progression.start = tick()
		end)
	end
end

À quoi sert ce script ?

Ce script permet au joueur d’appuyer sur une touche (F) pour obtenir un boost temporaire de vitesse et de saut pendant quelques secondes, avec une énergie limitée qui se réduit à chaque utilisation, affichée sous forme de barre.

Pourquoi ce script doit être un LocalScript et pas un script serveur

1. Détection des touches du clavier

UserInputService.InputBegan (qui détecte l’appui sur F) ne fonctionne que côté client. Le serveur ne « voit » pas directement quelle touche un joueur appuie sur son clavier — seul l’ordinateur du joueur (le client) peut détecter ça. Si ce script était sur le serveur, la détection de la touche ne fonctionnerait tout simplement pas.

2. Réactivité et fluidité

Un LocalScript s’exécute directement sur l’ordinateur du joueur, sans attendre d’aller-retour réseau avec le serveur. Le chrono et le boost réagissent donc instantanément, sans latence perceptible.

3. Affichage de l’interface (GUI)

Modifier un TextLabel ou la taille d’une barre (energy.Size) dans la PlayerGui doit se faire depuis un LocalScript : c’est l’interface personnelle de ce joueur, elle ne concerne que son écran à lui.

⚠️ Attention cependant : comme ce script est entièrement côté client, un joueur malveillant pourrait potentiellement le modifier pour tricher (boost infini, énergie illimitée…). Dans un vrai jeu, il faudrait que le serveur vérifie et valide réellement les changements de vitesse/saut, plutôt que de faire une confiance totale au client. Ce script convient pour l’affichage et le confort, mais une version « anti-triche » demanderait une communication avec un script serveur.

Pourquoi utiliser des CONSTANTES

EN MAJUSCULES (TIMELAPS, SPEEDMAX, JUMPMAX…)

1. Convention de lisibilité : en programmation, écrire un nom de variable entièrement en majuscules est une convention largement utilisée pour signaler « ceci est une constante de configuration, une valeur qui ne doit jamais changer pendant l’exécution du script ». Ça permet, en un coup d’œil, de distinguer les réglages (en haut du script) des variables qui évoluent pendant le jeu (energyLevel, startime…).
2. Facilité de modification : toutes les valeurs importantes sont regroupées au même endroit, en haut du script. Si tu veux changer la durée du boost ou la touche utilisée, tu modifies une seule ligne, sans devoir chercher dans tout le code où cette valeur est utilisée.
3. Évite les « nombres magiques » : sans constante, on verrait des 50, 70, 6 disséminés dans le code sans savoir à quoi ils correspondent. Avec SPEEDMAX = 50, le nom explique immédiatement le rôle du nombre.

Pourquoi RunService.Heartbeat plutôt qu’une boucle while ... do wait() end

Le problème d’une boucle while avec wait()

-- ❌ Mauvaise pratique
while true do
	wait()
	-- code du chrono
end

1. Bloque le thread : une boucle infinie s’exécute en continu et occupe le script en permanence, même quand il n’y a rien à faire.
2. Timing imprécis : wait() ne garantit pas un délai exact — il peut varier légèrement selon la charge du jeu, ce qui rend le chrono moins précis.
3. Difficile à arrêter proprement : il faut gérer soi-même une condition de sortie, et un oubli peut bloquer le script indéfiniment.

Pourquoi Heartbeat est meilleur

1. Synchronisé avec le moteur du jeu : RunService.Heartbeat se déclenche automatiquement à chaque frame, juste après les calculs de physique — c’est le rythme naturel du jeu (environ 60 fois par seconde), donc le chrono reste fluide et précis.
2. Pas de blocage : contrairement à une boucle while, Heartbeat:Connect(...) ne bloque jamais le reste du script — le code continue de s’exécuter normalement en parallèle.
3. Gestion automatique : pas besoin de gérer soi-même l’arrêt de la boucle ; la fonction ne fait simplement rien (return immédiat) tant que startime est nil, sans gaspiller de ressources inutiles.
4. Standard de l’industrie : c’est la méthode recommandée par Roblox pour tout ce qui doit se mettre à jour en continu (chronos, animations personnalisées, barres de vie…).

QCM pour vérifier la compréhension

1. Pourquoi ce script doit-il être un LocalScript et non un script serveur ?
A. Parce que les LocalScripts sont plus rapides à écrire
B. Parce que la détection des touches du clavier (InputBegan) ne fonctionne que côté client
C. Parce que Roblox interdit les scripts serveur sur les touches
D. Ça n’a aucune importance, les deux fonctionneraient pareil

2. Que signifie écrire une variable EN MAJUSCULES comme SPEEDMAX ?
A. Que la variable est plus rapide à lire par l’ordinateur
B. Que c’est une convention indiquant qu’il s’agit d’une constante de configuration
C. Que la variable est obligatoirement un nombre
D. Que la variable est visible par tous les scripts du jeu

3. Quel est le principal problème d’une boucle while true do wait() end pour gérer un chrono ?
A. Elle ne fonctionne pas du tout sur Roblox
B. Elle est difficile à écrire
C. Son timing est moins précis et elle bloque le thread en continu
D. Elle ne peut pas afficher de texte

4. Que fait RunService.Heartbeat ?
A. Il vérifie le rythme cardiaque du joueur
B. Il exécute une fonction automatiquement à chaque frame du jeu
C. Il redémarre le script à chaque respawn
D. Il détecte les touches du clavier

5. Pourquoi regrouper tous les réglages (TIMELAPS, SPEEDMAX, JUMPMAX…) en haut du script ?
A. Pour que le script soit plus court
B. Pour faciliter la modification des paramètres à un seul endroit, sans chercher dans tout le code
C. Parce que Roblox l’exige
D. Pour que le jeu se charge plus vite

6. Quel est le risque de sécurité mentionné concernant ce LocalScript ?
A. Il pourrait faire planter le jeu
B. Un joueur malveillant pourrait le modifier pour tricher (énergie infinie, boost permanent)
C. Il consomme trop de mémoire
D. Il ne fonctionne que sur mobile

7. Que se passe-t-il concrètement si on remplace Heartbeat par une boucle while wait() do dans ce script ?
A. Rien ne change, c’est strictement identique
B. Le chrono pourrait être légèrement moins précis et le code moins optimisé, bien que fonctionnellement proche
C. Le boost ne fonctionnerait plus du tout
D. Le jeu planterait immédiatement

Crée cette structure d’UI pour la barre d’énergie et le compteur du boost :

Le ScreenGui possède une propriété ResetOnSpawn, qui vaut true par défaut. Quand elle est activée :

• À chaque respawn, Roblox détruit le ScreenGui actuel dans la PlayerGui et le recrée à neuf depuis sa version originale dans StarterGui.
• Toutes les modifications faites par script sont donc perdues, et la barre d’énergie revient à sa taille définie dans les Properties de Studio.

Solution

Dans l’Explorer, sélectionne ton ScreenGui et décoche/mets à false la propriété ResetOnSpawn :

Crée un LocalScript sous StarterPlayerScripts

Sous StarterPlayerScripts

Le script s’exécute dès la connexion du joueur, souvent avant même que le personnage n’existe dans le jeu (player.Character vaut alors nil, car le perso n’a pas encore spawn).

Sous StarterCharacterScripts

Le script est recréé et réexécuté à chaque respawn du personnage.

Dans notre cas, nous avons besoin de garder les informations sur le joueur après un respawn, crée donc un LocalScript sous StarterPlayerScripts :

-- Récupération des services
local UserInputService = game:GetService("UserInputService")
local RunService = game:GetService("RunService")
local Players = game:GetService("Players")

-- Paramètrage du service
local TIMELAPS = 6
local SPEEDMAX = 50
local JUMPMAX = 70
local TOUCHBOOST = Enum.KeyCode.F
local ENERGY_COST = 0.1

-- Récupération du player et des écrans
local player = Players.LocalPlayer

-- La PlayerGui et son contenu ne sont PAS détruits au respawn : on les récupère une seule fois
local playerGui = player:WaitForChild("PlayerGui")
local screenGui = playerGui:WaitForChild("ScreenGui")

-- Penser à modifier la propriété suivante dans ROBLOX STUDIO screenGui.ResetOnSpawn = false
local chrono = playerGui:WaitForChild("ScreenGui"):WaitForChild("Frame"):WaitForChild("ChronoBoost")
local energy = playerGui:WaitForChild("ScreenGui"):WaitForChild("Frame"):WaitForChild("Energy")
local info = energy:WaitForChild("Frame"):WaitForChild("InfoLabel")

-- Initialisation des variables au lancement du script
local humanoid, jumpHeight, walkSpeed
local energyLevel = 1
local startime = nil

-- Initialisation de l'affichage de la barre de puissance
info.Text = "Press " .. TOUCHBOOST.Name .. " to boost for 3 seconds (Energy " .. math.floor(ENERGY_COST * 100) .. "%)"
chrono.Visible = false

-- Formatage du temps restant en seconde et dixième de seconde
local function formatTime(t)
	local seconds = math.floor(t % 60)
	local tenths = math.floor((t * 10) % 10)
	return string.format("%02d.%d", seconds, tenths)
end

-- Chargement du player
local function onCharacterAdded(character)
	humanoid = character:WaitForChild("Humanoid")
	jumpHeight = humanoid.JumpHeight
	walkSpeed = humanoid.WalkSpeed
	startime = nil
end

player.CharacterAdded:Connect(onCharacterAdded)
if player.Character then
	onCharacterAdded(player.Character)
end

-- Récupération de la touche du clavier pour actionner le boost
local function onKeyPress(input, gameProcessed)
	if gameProcessed or startime or not humanoid then return end
	if input.KeyCode ~= TOUCHBOOST then return end
	if energyLevel < ENERGY_COST then return end

	humanoid.JumpHeight = JUMPMAX
	humanoid.WalkSpeed = SPEEDMAX
	--energyLevel = math.clamp(energyLevel - ENERGY_COST, 0, 1)
	startime = tick()
	--energy.Size = UDim2.new(energyLevel, 0,  energy.Size.Y.Scale, 0)
end

UserInputService.InputBegan:Connect(onKeyPress)
-- Affichage du temps restant du boost
RunService.Heartbeat:Connect(function()
	if not startime or not humanoid then return end

	local elapsed = TIMELAPS - (tick() - startime)
	if elapsed > 0 then
		chrono.Visible = true
		chrono.Text = formatTime(elapsed)
	else
		startime = nil
		humanoid.JumpHeight = jumpHeight
		humanoid.WalkSpeed = walkSpeed
		chrono.Visible = false
		energyLevel = math.clamp(energyLevel - ENERGY_COST, 0, 1)
		energy.Size = UDim2.new(energyLevel, 0,  energy.Size.Y.Scale, 0)
	end
end)

Crée quatre parts avec un pouvoir pour chaque part :

• devenir transparent
• changer de taille
• courir plus vite
• sauter plus haut

Explication des 4 boosts

Invisibilité

Quand un joueur touche une des parts du dossier, le script vérifie s’il a déjà un dossier "Transparency" sur son Humanoid.
S’il ne l’a pas, il le crée et rend transparents tous les vêtements/accessoires et le corps du joueur (Transparency = 0.9).
S’il l’a déjà, le script le supprime et redonne au joueur son apparence normale (Transparency = 0).Un système de cooldown empêche de réactiver le pouvoir immédiatement après l’avoir utilisé.
C’est donc un interrupteur (toggle) : chaque contact avec la part active ou désactive l’invisibilité.

-- Script pour rendre invisible les joueurs qui touchent la part
local TRANSPARENCE_ACTIVE = 0.9
local TRANSPARENCE_INACTIVE = 0
local COOLDOWN = 1 -- secondes avant de pouvoir re-déclencher

local cooldowns = {} -- [character] = true pendant le cooldown

local function playerTransparency(character, transparency)
	for _, chose in ipairs(character:GetChildren()) do
		if chose:IsA("Accessory") then
			-- Rend transparent les BasePart/Decal de l'accessoire
			for _, descendant in ipairs(chose:GetDescendants()) do
				if descendant:IsA("BasePart") or descendant:IsA("Decal") then
					descendant.Transparency = transparency
				end
			end
		elseif chose:IsA("MeshPart") then
			-- Le MeshPart lui-même est la part à rendre transparente
			chose.Transparency = transparency
		end
	end
end

-- Boucle sur toutes les parts du folder des parts pour rendre invisible
local part = script.Parent

part.Touched:Connect(function(hit)
	local character = hit.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	if not humanoid then return end
	if cooldowns[character] then return end

	cooldowns[character] = true

	local existingFolder = humanoid:FindFirstChild("Transparency")
	local transparency

	if existingFolder then
		existingFolder:Destroy()
		transparency = TRANSPARENCE_INACTIVE
	else
		local folder = Instance.new("Folder")
		folder.Name = "Transparency"
		folder.Parent = humanoid
		transparency = TRANSPARENCE_ACTIVE
	end

	playerTransparency(character, transparency)

	task.wait(COOLDOWN)
	cooldowns[character] = nil
end)

Taille

1. Quand le joueur touche la part, le script regarde si un dossier "Scale" existe déjà sur son Humanoid.
2. S’il n’existe pas, il sauvegarde la taille actuelle du joueur, puis l’agrandit ou le rétrécit à SCALEMAX (0.3, donc joueur miniature).
3. S’il existe déjà, le script redonne au joueur sa taille d’origine et supprime le dossier.
4. Les 4 dimensions (hauteur, largeur, profondeur, tête) sont modifiées en même temps pour un effet cohérent.
5. Comme pour l’invisibilité, c’est un toggle protégé par un cooldown.

local part = script.Parent

local SCALEMAX = 0.3

local COOLDOWN = 1 -- secondes avant de pouvoir re-déclencher
local cooldowns = {} -- [character] = true pendant le cooldown

part.Touched:Connect(function(plr)
	local character = plr.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	if not humanoid  then return end

	if cooldowns[character] then return end
	cooldowns[character] = true

	local existingFolder = humanoid:FindFirstChild("Scale")

	if existingFolder then
		humanoid.BodyHeightScale.Value = existingFolder.Value
		humanoid.BodyWidthScale.Value = existingFolder.Value		
		humanoid.BodyDepthScale.Value = existingFolder.Value	
		humanoid.HeadScale.Value = existingFolder.Value
		existingFolder:Destroy()
	else
		local folder = Instance.new("IntValue")
		folder.Name = "Scale"
		folder.Parent = humanoid
		folder.Value = humanoid.BodyHeightScale.Value
		humanoid.BodyHeightScale.Value = SCALEMAX
		humanoid.BodyWidthScale.Value = SCALEMAX		
		humanoid.BodyDepthScale.Value = SCALEMAX	
		humanoid.HeadScale.Value = SCALEMAX
	end

	task.wait(COOLDOWN)
	cooldowns[character] = nil

end)

Vitesse

1. Quand le joueur touche la part, le script vérifie si un dossier "Speed" existe sur son Humanoid.
2. S’il n’existe pas, il sauvegarde la vitesse actuelle du joueur (WalkSpeed) et la remplace par SPEEDMAX (50, donc très rapide).
3. S’il existe déjà, le script restaure la vitesse normale du joueur et supprime le dossier.
4. Cela permet au joueur de courir beaucoup plus vite qu’en temps normal.
5. Le cooldown évite d’activer/désactiver le pouvoir trop rapidement en boucle.

local part = script.Parent

local SPEEDMAX = 50

local COOLDOWN = 1 -- secondes avant de pouvoir re-déclencher
local cooldowns = {} -- [character] = true pendant le cooldown

part.Touched:Connect(function(plr)
	local character = plr.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	if not humanoid  then return end
	
	if cooldowns[character] then return end
	cooldowns[character] = true
	
	local existingFolder = humanoid:FindFirstChild("Speed")
	
	if existingFolder then
		humanoid.WalkSpeed = existingFolder.Value
		existingFolder:Destroy()
	else
		local folder = Instance.new("IntValue")
		folder.Name = "Speed"
		folder.Parent = humanoid
		folder.Value = humanoid.WalkSpeed
		humanoid.WalkSpeed = SPEEDMAX
	end
	
	task.wait(COOLDOWN)
	cooldowns[character] = nil
	
end)

Saut

1. Quand le joueur touche la part, le script vérifie si un dossier "Jump" existe sur son Humanoid.
2. S’il n’existe pas, il sauvegarde une valeur puis augmente sa hauteur de saut (JumpHeight) jusqu’à JUMPMAX (80, donc saut très haut).
3. S’il existe déjà, le script restaure la hauteur de saut d’origine et supprime le dossier.
4. Cela permet au joueur de sauter beaucoup plus haut que d’habitude.
5. Le cooldown protège contre une réactivation trop rapide du pouvoir.

local part = script.Parent

local JUMPMAX = 80
local COOLDOWN = 1 -- secondes avant de pouvoir re-déclencher
local cooldowns = {} -- [character] = true pendant le cooldown

part.Touched:Connect(function(plr)
	local character = plr.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	if not humanoid  then return end
	
	if cooldowns[character] then return end
	cooldowns[character] = true
	
	local existingFolder = humanoid:FindFirstChild("Jump")
	
	if existingFolder then
		humanoid.JumpHeight = existingFolder.Value
		existingFolder:Destroy()
	else
		local folder = Instance.new("IntValue")
		folder.Name = "Jump"
		folder.Parent = humanoid
		folder.Value = humanoid.JumpHeight
		humanoid.JumpHeight = JUMPMAX
	end
	
	task.wait(COOLDOWN)
	cooldowns[character] = nil
	
end)

Point commun aux 4 scripts : ils utilisent tous le même mécanisme (dossier-mémoire + toggle + cooldown).

QCM pour mieux comprendre

1. Que se passe-t-il si un joueur touche deux fois la part « invisibilité » (avec le cooldown écoulé entre les deux) ?
A. Rien la deuxième fois
B. Il devient invisible puis redevient visible
C. Il meurt
D. Il devient invincible

2. À quoi sert le dossier créé (ex: "Speed", "Scale", "Jump") dans chaque script ?
A. À décorer le personnage
B. À mémoriser la valeur d’origine avant modification
C. À compter le nombre de joueurs
D. À afficher un message

3. Pourquoi y a-t-il un COOLDOWN dans chaque script ?
A. Pour ralentir le jeu
B. Pour empêcher de réactiver le pouvoir trop vite d’affilée
C. Pour supprimer le joueur
D. Pour changer la couleur de la part

4. Quelle propriété du Humanoid est modifiée par le pouvoir « saut » ?
A. WalkSpeed
B. Health
C. JumpHeight
D. Transparency

5. Que modifient ENSEMBLE BodyHeightScale, BodyWidthScale, BodyDepthScale et HeadScale ?
A. La vitesse du joueur
B. La taille du joueur
C. La transparence du joueur
D. La couleur du joueur

6. Pourquoi le pouvoir « invisibilité » doit-il aussi modifier les Accessory (accessoires) du joueur ?
A. Pour que le chapeau/les cheveux etc. deviennent transparents aussi, sinon on verrait encore une partie du joueur
B. Pour supprimer les accessoires
C. Pour donner des points au joueur
D. Pour changer la forme des accessoires

Ce système affiche un chrono qui mesure le temps mis par un joueur pour aller d’un bloc de départ à un bloc d’arrivée.

Le script serveur est placé sur les blocs (départ/arrivée) : il détecte quand le joueur les touche (Touched) et décide quand le chrono doit démarrer ou s’arrêter.

Le LocalScript, lui, tourne uniquement sur l’ordinateur du joueur : il gère l’affichage du chrono à l’écran (le TextLabel).

Le serveur ne peut pas modifier directement l’écran d’un joueur : il doit envoyer un message au client via un RemoteEvent.

Le RemoteEvent fonctionne comme une messagerie entre le serveur et le client : quand le joueur touche le bloc de départ, le serveur « fire » (envoie) l’événement StartEvent.

Le LocalScript écoute cet événement avec OnClientEvent:Connect(...) et, dès qu’il le reçoit, enregistre l’heure de départ (tick()) et active running = true.

De la même façon, quand le joueur touche le bloc d’arrivée, le serveur envoie WinEvent, et le LocalScript reçoit ce signal pour arrêter le chrono (running = false).

Pendant que running est actif, la fonction RunService.Heartbeat recalcule et affiche le temps écoulé à chaque frame (60 fois par seconde environ).

La fonction formatTime transforme le nombre de secondes brut en un affichage lisible du type 01:23 (minutes:secondes).

En résumé : le serveur décide (quand démarrer/arrêter), les RemoteEvents transmettent l’info, et le LocalScript affiche le résultat à l’écran du joueur.

Petit rappel pour bien comprendre

• Script serveur : tourne sur l’ordinateur qui héberge la partie. Il contrôle les règles du jeu, mais ne peut pas modifier ce qui s’affiche à l’écran d’un joueur précis.
• LocalScript : tourne uniquement sur l’ordinateur du joueur. Il gère l’affichage (interface, sons, caméra…) mais ne peut pas être utilisé pour des règles importantes du jeu (sinon un joueur pourrait tricher).
• RemoteEvent : le « pont » entre les deux. Le serveur envoie une info avec FireClient(), et le LocalScript la reçoit avec OnClientEvent:Connect().

QCM pour bien comprendre

1. Où s’exécute un LocalScript ?
A. Sur le serveur du jeu
B. Sur l’ordinateur du joueur uniquement
C. Sur tous les ordinateurs en même temps
D. Nulle part, c’est juste un fichier texte

2. Pourquoi ne peut-on pas modifier directement le TextLabel depuis le script serveur ?
A. Parce que c’est interdit par Roblox
B. Parce que le serveur n’a pas accès à l’affichage local de chaque joueur
C. Parce que le TextLabel n’existe pas sur le serveur
D. Parce que ça coûte trop cher en mémoire

3. À quoi sert un RemoteEvent ?
A. À supprimer un joueur du jeu
B. À transmettre une information entre le serveur et un client
C. À changer la couleur d’un bloc automatiquement
D. À sauvegarder les données du joueur

4. Que fait startEvent:FireClient(player) côté serveur ?
A. Il supprime le joueur
B. Il envoie un signal au client précis pour déclencher une action
C. Il démarre le jeu pour tous les joueurs
D. Il crée un nouveau RemoteEvent

5. Que fait RunService.Heartbeat dans ce script ?
A. Il vérifie les battements de cœur du joueur
B. Il exécute du code à chaque frame, ici pour actualiser l’affichage du chrono
C. Il redémarre le serveur régulièrement
D. Il compte le nombre de joueurs connectés

6. Que se passe-t-il si running vaut false ?
A. Le chrono continue de s’incrémenter
B. Le texte du chrono arrête de se mettre à jour
C. Le joueur est téléporté au départ
D. Le RemoteEvent est détruit

Crée un part pour déterminer le départ du chrono et un part pour déterminer le stop du chrono.

Puis deux RemoteEvent pour gérer le démarrage et l’arrêt du chrono :

Puis script sur le serveur pour gérer les collisions entre le player et les parts de départ et d’arrivée :

local replicatedStorage = game:GetService("ReplicatedStorage")
local remoteEvent = replicatedStorage:WaitForChild("Coursetimecheck")

local startEvent = remoteEvent.StartEvent
local winEvent = remoteEvent.WinEvent

local start = script.Parent.StartPart
local succes = script.Parent.SuccessPart

succes.SurfaceGui.Enabled = false
succes.ParticleEmitter.Enabled = false

succes.Anchored = true
succes.CanCollide = true
succes.CanTouch = true

start.Anchored = true
start.CanCollide = false
start.CanTouch = true
start.Transparency = 1

succes.Touched:Connect(function(hit)
	local character = hit.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	if not humanoid then return end
	if succes.SurfaceGui.Enabled then return end
	
	remoteEvent.WinEvent:FireClient(game.Players:GetPlayerFromCharacter(character))

	succes.SurfaceGui.Enabled = true
	succes.ParticleEmitter.Enabled = true
end)

start.Touched:Connect(function(hit)
	local character = hit.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	if not humanoid then return end
	
	local player = game.Players:GetPlayerFromCharacter(character)
	if not player then return end -- sécurité si ce n'est pas un joueur (NPC par ex.)

	print("StartEvent déclenché pour " .. player.Name)

	startEvent:FireClient(player)
	
end)

Et également un localScript pour l’affichage du chrono pour le joueur :

-- Récupération des services
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local RunService = game:GetService("RunService")

-- Récupération du joueur actuel et de la PlayerGui
local player = Players.LocalPlayer
local playerGui = player:WaitForChild("PlayerGui")

-- Récupération de l'UI du chrono
local chrono = playerGui:WaitForChild("ScreenGui"):WaitForChild("Frame"):WaitForChild("ChronoLabel")

-- Récupération des RemoteEvents start et stop du chrono
local remoteEventsFolder = ReplicatedStorage:WaitForChild("Coursetimecheck")
local startEvent = remoteEventsFolder:WaitForChild("StartEvent")
local stopEvent = remoteEventsFolder:WaitForChild("WinEvent")

-- Fonction pour formater le temps en minutes:secondes
local function formatTime(t)
	local minutes = math.floor(t / 60)
	local seconds = math.floor(t % 60)
	return string.format("%02d:%02d", minutes, seconds)
end

-- Variables globales pour suivre le temps et l'état du chrono
local startTime = nil
chrono.Text = "00:00"
local running = false

-- Connexion des événements serveur au client
startEvent.OnClientEvent:Connect(function()
	startTime = tick()
	running = true
end)

stopEvent.OnClientEvent:Connect(function()
	running = false
end)

-- Mise à jour continue de l'affichage du chrono
RunService.Heartbeat:Connect(function()
	if not running or not startTime then return end
	chrono.Text = formatTime(tick() - startTime)
end)

Ce script est attaché à un Part (bloc) et détecte quand un joueur le touche, via l’événement Touched.

Il vérifie que c’est bien un personnage avec un Humanoid, et bloque les déclenchements répétés grâce à un système de cooldown (table cooldowns).

Si le joueur n’a pas encore été rétréci/agrandi, le script sauvegarde sa taille actuelle dans un dossier Scale, puis applique la taille SCALEMAX (0.3) à sa hauteur, largeur, profondeur et tête.

Si le joueur a déjà été modifié (le dossier Scale existe), le script lui redonne sa taille d’origine et supprime le dossier.

Autrement dit : c’est un bloc « grandir/rétrécir » qui bascule (toggle) la taille du joueur à chaque contact, avec une seconde d’attente avant de pouvoir réutiliser le bloc.

QCM : Testez votre compréhension !

1. Que fait l’événement Touched dans ce script ?
A. Il vérifie si le joueur a cliqué sur le bloc
B. Il détecte quand quelque chose touche la Part
C. Il compte le nombre de joueurs dans le jeu
D. Il détruit le bloc

2. À quoi sert la variable COOLDOWN ?
A. À changer la couleur du bloc
B. À définir la taille maximale du joueur
C. À empêcher de réutiliser le bloc trop vite
D. À supprimer le personnage

3. Que se passe-t-il si le joueur touche le bloc une deuxième fois (après le cooldown) ?
A. Rien, ça ne marche qu’une fois
B. Le joueur reprend sa taille normale
C. Le joueur devient minuscule
D. Le jeu plante

4. À quoi sert le dossier (IntValue) nommé "Scale" ?
A. À afficher un message au joueur
B. À mémoriser la taille d’origine du joueur
C. À compter le temps de cooldown
D. À stocker le nom du joueur

5. Pourquoi utilise-t-on une table cooldowns avec le character comme clé ?
A. Pour donner un nom à chaque joueur
B. Pour savoir si CE joueur précis est en cooldown
C. Pour compter les points de chaque joueur
D. Pour changer la vitesse du joueur

local part = script.Parent

local SCALEMAX = 0.3

local COOLDOWN = 1 -- secondes avant de pouvoir re-déclencher
local cooldowns = {} -- [character] = true pendant le cooldown

part.Touched:Connect(function(plr)
	local character = plr.Parent
	local humanoid = character and character:FindFirstChild("Humanoid")
	if not humanoid  then return end

	if cooldowns[character] then return end
	cooldowns[character] = true

	local existingFolder = humanoid:FindFirstChild("Scale")

	if existingFolder then
		humanoid.BodyHeightScale.Value = existingFolder.Value
		humanoid.BodyWidthScale.Value = existingFolder.Value		
		humanoid.BodyDepthScale.Value = existingFolder.Value	
		humanoid.HeadScale.Value = existingFolder.Value
		existingFolder:Destroy()
	else
		local folder = Instance.new("IntValue")
		folder.Name = "Scale"
		folder.Parent = humanoid
		folder.Value = humanoid.BodyHeightScale.Value
		humanoid.BodyHeightScale.Value = SCALEMAX
		humanoid.BodyWidthScale.Value = SCALEMAX		
		humanoid.BodyDepthScale.Value = SCALEMAX	
		humanoid.HeadScale.Value = SCALEMAX
	end

	task.wait(COOLDOWN)
	cooldowns[character] = nil

end)

Voici l’explication du code, ligne par ligne :

Les variables de départ

local teleports = script.Parent
local teleportA = teleports.TeleportA
local teleportB = teleports.TeleportB

On récupère deux objets dans le jeu Roblox : la plateforme A (celle sur laquelle on va marcher) et la plateforme B (celle où on va arriver). Ces deux plateformes sont des enfants du script dans l’arbre du jeu.

L’événement Touched

teleportA.Touched:Connect(function(hit)

Touched est un événement Roblox : il se déclenche automatiquement dès que quelque chose touche la plateforme A. Le paramètre hit contient la pièce (la partie du corps) qui l’a touchée.

La vérification du joueur

local character = hit.Parent
local humanoid = character and character:FindFirstChildOfClass("Humanoid")
if not humanoid or humanoid.Health <= 0 then return end

On remonte d’un niveau pour trouver le personnage entier (hit.Parent), puis on cherche s’il contient un Humanoid (ce qui prouve que c’est bien un joueur, pas un mur ou une balle). Si rien de valide n’est trouvé, ou si le joueur est mort (Health <= 0), on arrête tout avec return.

La téléportation

local offset = Vector3.new(0, 2, 0)
character:PivotTo(CFrame.new(teleportB.Position + offset))

Vector3.new(0, 2, 0) crée un décalage de 2 unités vers le haut pour que le joueur atterrisse au-dessus de la plateforme B et pas à l’intérieur. PivotTo est la fonction qui déplace instantanément tout le personnage à une nouvelle position — c’est ça la téléportation !

Le code complet de la téléportation

-- Configuration
local teleports = script.Parent
local teleportA = teleports.TeleportA
local teleportB = teleports.TeleportB

teleportA.Touched:Connect(function(hit)
	-- Récupération du joueur
	local character = hit.Parent
	local humanoid  = character and character:FindFirstChildOfClass("Humanoid")
	if not humanoid or humanoid.Health <= 0 then return end
	
	-- Décalage légert vers le haut pour poser le joueur sur la plateforme
	local offset = Vector3.new(0, 2, 0)
	character:PivotTo(CFrame.new(teleportB.Position + offset))

end)