Tester avec de vrais joueurs

Tu connais ton obby par cœur : tu sais où sauter, où se cachent les pièces, comment fonctionne la boutique. C’est justement pour ça que tu es la pire personne pour juger s’il est clair. Les leçons précédentes t’ont donné des principes ; cette dernière leçon du module t’apprend à les vérifier avec de vrais joueurs, ceux qui découvrent ton jeu sans rien savoir.

Pourquoi tester avec d’autres que toi

La documentation Roblox sur le prototypage explique que le prototypage permet de détecter tôt les défauts de conception, les oublis et les besoins techniques inattendus, quand ils coûtent encore peu à corriger. Elle conseille de partager ton prototype en dehors de ton équipe (amis, famille, réseaux sociaux) pour obtenir des retours et un regard neuf, puis d’itérer jusqu’à être satisfait.

Elle cite aussi ce qu’il faut examiner de près : la core loop (leçon 1), l’interface et les contrôles (sont-ils intuitifs ?), les règles du jeu (où et quand on réapparaît…) et les cas limites : comment un joueur peut pousser ton jeu dans ses retranchements.

Organiser un playtest

Qui inviter ?

• Des personnes qui n’ont jamais vu ton jeu. Un ami qui t’a regardé le construire n’est plus un nouveau joueur.
• Des profils proches de ton public. Si ton obby vise les 10-14 ans, un petit frère ou une cousine de cet âge t’apprendra plus qu’un adulte qui ne joue jamais à Roblox.
• Peu de monde, mais souvent. Dans un article célèbre du Nielsen Norman Group (2000), spécialiste de l’ergonomie, Jakob Nielsen recommande de tester avec 5 personnes au plus et de multiplier les petites séries, en corrigeant entre chacune, plutôt qu’un seul grand test. C’est une règle empirique issue des tests d’utilisabilité de sites web, pas une loi exacte, et Nielsen précise qu’il faut davantage de testeurs si ton public réunit des groupes très différents (il cite l’exemple des enfants et de leurs parents). Elle convient très bien à un petit projet.

Comment les faire jouer ?

1. Sur ton ordinateur, dans Studio : le plus simple. Ton testeur joue avec le bouton Play pendant que tu observes derrière lui.

2. En ligne, avant le lancement public : au moment de la rédaction (octobre 2026), la documentation Roblox indique qu’un jeu nouvellement publié n’est accessible qu’à toi et aux personnes ayant les droits d’édition. Tu peux inviter jusqu’à 10 amis d’âge proche comme testeurs (early testers) depuis Studio, via File › Invite early testers.

   • Si tu ne l’as pas encore fait, Roblox te demande de passer une vérification d’âge.
   • Les testeurs de moins de 16 ans ne peuvent pas voir un jeu dont la classification dépasse ce que leurs parents autorisent.
   • Tous les testeurs voient un filigrane qui indique qu’il s’agit d’un aperçu.

   Ces options évoluent souvent : vérifie la page officielle de publication, dont on reparle au module 8.

Observer sans influencer

Penser à voix haute

Une méthode de référence en ergonomie s’appelle le think aloud (« penser à voix haute ») : on demande au testeur d’utiliser le produit en disant en continu ce qu’il pense. Jakob Nielsen (Nielsen Norman Group, 2012) la présente comme l’outil n° 1 des tests d’utilisabilité et la résume en trois étapes : recruter des utilisateurs représentatifs, leur donner des tâches représentatives, puis se taire et les laisser parler.

Pour l’Obby des Nuages, la consigne peut être : « Joue comme si tu étais chez toi, et dis-moi à voix haute ce que tu regardes, ce que tu cherches et ce que tu ressens. Ce n’est pas toi qu’on teste, c’est mon jeu. »

Ce que tu notes

• Les blocages : où le joueur hésite, tourne en rond, tombe plusieurs fois.
• Les surprises : ce qu’il essaie et que tu n’avais pas prévu (passer par-dessus un mur, sauter un checkpoint…).
• Les émotions : soupirs, rires, « ah, d’accord ! », silence ennuyé.
• Ce qu’il ne voit pas : la boutique, la pièce dorée, le message de la leçon 1.

Les questions de fin

Après la partie, pose des questions ouvertes qui n’orientent pas la réponse :

• « Qu’est-ce que tu as préféré ? Qu’est-ce qui t’a énervé ? »
• « À quoi servaient les pièces, d’après toi ? »
• « Si tu devais décrire ce jeu à un ami en une phrase, tu dirais quoi ? »
• « Est-ce que tu y rejouerais ? Pourquoi ? »

Évite les questions fermées qui suggèrent la réponse (« C’était bien, hein ? »). La question « À quoi servaient les pièces ? » est précieuse : si la réponse est « je ne sais pas », ta boucle méta (leçon 3) n’est pas comprise.

Mesurer pendant le playtest

Pendant que tu observes, un petit script peut chronométrer chaque étape à ta place. Crée un Script (côté serveur) nommé SuiviPlaytest dans ServerScriptService. Il affiche dans l’Output (la fenêtre de sortie) le temps passé et le nombre de chutes entre deux checkpoints. Pratique pour repérer un pic de difficulté (leçon 3) ou régler le délai de l’indice minuté (leçon 2). Dans ton projet Rojo, c’est le fichier src/ServerScriptService/SuiviPlaytest.server.luau, que tu peux faire écrire par Claude Code (encadré plus bas) avant de le relire.

-- Script à placer dans ServerScriptService, à n'utiliser QUE pendant tes playtests.
-- Affiche dans l'Output le temps et le nombre de chutes pour chaque étape franchie.
local Players = game:GetService("Players")

local MODE_PLAYTEST = true -- passe à false (ou supprime ce script) avant le lancement public

local function suivreJoueur(player: Player)
	local chutes = 0

	-- Compte les morts (kill bricks, chutes dans le vide…)
	local function suivrePersonnage(personnage: Model)
		local humanoid = personnage:WaitForChild("Humanoid") :: Humanoid
		humanoid.Died:Connect(function()
			chutes += 1
		end)
	end
	player.CharacterAdded:Connect(suivrePersonnage)
	if player.Character then
		suivrePersonnage(player.Character)
	end

	local etape = player:WaitForChild("leaderstats"):WaitForChild("Etape") :: IntValue
	local debutPartie = os.clock()
	local debutEtape = debutPartie

	etape.Changed:Connect(function(nouvelleEtape: number)
		local maintenant = os.clock()
		print(string.format(
			"[PLAYTEST] %s : étape %d en %d s, %d chute(s) (total : %d s)",
			player.Name,
			nouvelleEtape,
			math.floor(maintenant - debutEtape),
			chutes,
			math.floor(maintenant - debutPartie)
		))
		-- On repart de zéro pour l'étape suivante
		debutEtape = maintenant
		chutes = 0
	end)
end

if MODE_PLAYTEST then
	Players.PlayerAdded:Connect(suivreJoueur)
	-- Joueurs déjà présents si le script démarre après eux (possible en test)
	for _, player in Players:GetPlayers() do
		task.spawn(suivreJoueur, player)
	end
end

Quelques remarques :

• os.clock() renvoie un temps en secondes, idéal pour mesurer une durée (la différence entre deux appels).
• Dans Studio, les messages apparaissent dans la fenêtre Output. Dans un serveur en ligne, tu peux lire la sortie du serveur dans la Developer Console (touche F9 en jeu), si tu as les droits sur le jeu.
• Ce script est un outil de test temporaire. Pour mesurer tous tes joueurs dans la durée, tu utiliseras les entonnoirs d’AnalyticsService au module 9.

Transformer les retours en décisions

Écouter la raison, pas seulement la demande

La documentation Roblox sur les LiveOps donne un conseil précieux : plus importantes que les suggestions précises des joueurs, il y a les raisons qui se cachent derrière. « Ajoute des dragons ! » veut peut-être dire « la zone 2 est visuellement monotone ». Ajouter des dragons n’est qu’une solution parmi d’autres.

Prioriser

Classe chaque problème selon deux questions :

1. Combien de testeurs l’ont rencontré ? Un blocage vu chez 4 testeurs sur 5 passe avant une remarque isolée.
2. Est-ce qu’il fait abandonner ? Un joueur qui quitte à l’étape 4 est plus grave qu’une pièce mal placée.

La même logique sert à Roblox pour les bugs : la documentation LiveOps les classe selon leur gravité, l’effort pour les corriger et le nombre de joueurs touchés.

Itérer vite, une chose à la fois

Corrige les priorités hautes, puis reteste avec de nouvelles personnes. Si tu changes dix choses d’un coup, tu ne sauras pas laquelle a fait la différence.

Tenir un journal des changements

Note chaque modification avec sa date et sa raison, par exemple dans un simple fichier texte :

• « 24/10 : étape 4 élargie (4/5 testeurs bloqués). »
• « 26/10 : indice minuté passé de 15 à 10 s (3 testeurs perdus au départ). »

Ce journal te servira au module 9 : quand une courbe de statistiques bougera, tu sauras exactement ce qui a changé ce jour-là.

📌 Ce qu’il faut retenir

• Tu connais trop bien ton jeu pour juger s’il est clair : seuls de nouveaux joueurs peuvent te le dire.
• Teste peu de monde, mais souvent, avec des profils proches de ton public.
• Observe sans aider : fais penser à voix haute, note blocages, surprises et émotions, puis pose des questions ouvertes.
• Un petit script de playtest mesure temps et chutes par étape ; les entonnoirs du module 9 prendront le relais.
• Priorise selon le nombre de joueurs touchés et le risque d’abandon, cherche la raison derrière chaque suggestion, change une chose à la fois et tiens un journal.

📚 Sources et pour aller plus loin

• Prototyping — tester tôt et itérer (Roblox)
• Publish experiences and places — accès et testeurs invités (Roblox)
• LiveOps essentials — écouter les joueurs et prioriser les bugs (Roblox)
• Onboarding techniques — régler les indices grâce aux playtests (Roblox)
• Developer Console — lire la sortie du serveur en jeu (Roblox)
• Thinking Aloud: The #1 Usability Tool — Jakob Nielsen, Nielsen Norman Group
• Why You Only Need to Test with 5 Users — Jakob Nielsen, Nielsen Norman Group