Tester une map GMod avec des joueurs : un playtest en cinq étapes
Tester une map GMod avant sa mise en ligne : cinq étapes, du passage solo à la partie avec joueurs, avec commandes console, checklist et règles de feedback.
Teste une map GMod en cinq étapes : compilation finale, passage en solo avec la console développeur, test sur un client vierge sans ton contenu, test sur un serveur dédié et, pour finir, une partie avec de vrais joueurs. Seul sur ta propre machine, tu es à la fois serveur et client et tu as chaque fichier en local. Le contenu manquant, les ascenseurs saccadés, les spawns trop peu nombreux et les chutes de performances avec beaucoup d’entités n’apparaissent donc que dans les étapes suivantes.
Pourquoi tester seul ne suffit pas
- Tu es à la fois serveur et client. En solo, le client saute la prédiction. Sur un serveur, chaque client prédit son propre déplacement, et le serveur le corrige quand il arrive à un résultat différent. C’est sur les plateformes mobiles que cela se voit le plus : en multijoueur, les plateformes qui se déplacent verticalement paraissent saccadées aux joueurs qui se trouvent dessus.
- Ta machine a tout le contenu. Les textures, les modèles et les sons se trouvent dans ton dossier de jeu, et les jeux montés s’y ajoutent. Un testeur n’a que ce qui se trouve dans le BSP ou ce que le serveur distribue.
- Un serveur tourne sans cheats. Beaucoup de commandes de diagnostic nécessitent
sv_cheats 1, et sur un serveur la valeur est à 0 par défaut. Tu fais l’analyse en local et tu te sers du serveur pour observer. - Plus de joueurs, c’est plus d’entités. Chaque joueur, chaque arme et chaque prop spawné est une entité. Les spawns, les portes, le framerate et la limite d’edicts ne sont testés que sous charge.
Le plan de test en cinq étapes
- Compilation finale. Ne teste que le fichier que tu vas publier : VVIS complet, VRAD avec
-final, cubemaps générées, contenu packé. La vérification du fichier lui-même est décrite dans vérifier un BSP avant publication. Donne à chaque version de test son propre nom de fichier, car le serveur refuse les clients dont le BSP diffère (Your map [...] differs from the server's.). - Passage en solo. Charge la map en local, active
developer 1et parcours-la en entier : chaque porte, chaque bouton, chaque ascenseur, chaque échelle. Lis ensuite la console. Lance après cela une partie avec plusieurs slots et remplis-les avecbot. Tu vois ainsi si les points de spawn suffisent. - Client vierge. Les options de lancement
-noworkshopet-noaddonsdésactivent temporairement les addons du Workshop et les addons en dossier. Les fichiers en vrac dans le dossier de jeu et les jeux montés restent toutefois en place. Une deuxième machine ou un testeur qui n’a jamais eu ton contenu est plus fiable. - Serveur dédié. Charge la map sur un serveur dédié et connecte-toi. Lis la console du serveur au démarrage de la map, vérifie que la map et le contenu arrivent bien chez le client (voir FastDL et Workshop) et emprunte chaque ascenseur avec un vrai ping.
- De vrais joueurs. Joue la map dans le mode de jeu pour lequel elle est faite, avec autant de joueurs que possible. Tu observes et tu prends des notes, tu n’expliques rien.
Commandes console pour les étapes 2 à 4
| Commande | Ce qu’elle montre | Nécessite sv_cheats 1 |
|---|---|---|
developer 1 | des messages supplémentaires dans la console et en haut à gauche de l’écran | non |
cl_showfps 1 | le framerate | non |
net_graph 1 | le framerate, la latence et les données de paquets | non |
cl_showpos 1 | la position actuelle | non |
getpos | écrit la position et les angles de vue dans la console | non |
status | la map, les joueurs et les connexions | non |
report_entities | les entités comptées par classe, plus le total avec les edicts | non, mais seulement pour l’hôte ou dans la console du serveur |
+showbudget | le temps par image, par système du moteur | non dans GMod (l’obligation de cheats indiquée dans le wiki de Valve concerne d’autres jeux Source) |
mat_wireframe 1 | tout ce qui est dessiné, en fil de fer | oui |
mat_leafvis 1, r_DrawPortals 1 | le visleaf actuel et les areaportals | oui |
r_drawclipbrushes 1, vcollide_wireframe 1 | les clip brushes et les modèles de collision | oui |
showtriggers_toggle | les brushes de trigger | oui |
nav_edit 1, ai_nodes | le navmesh et les AI nodes | oui |
soundscape_debug 1 | des lignes vers chaque env_soundscape, celui qui est actif en vert | oui |
Un bon point de départ pour le passage en solo :
sv_cheats 1
developer 1
cl_showfps 1
cl_showpos 1
report_entitiesNote le total de report_entities sur la map vide. C’est ta valeur de référence avant que les joueurs et les props ne s’ajoutent. Dans la console d’un serveur dédié, stats affiche en plus des valeurs de performance du serveur. La façon de trouver les causes avec mat_wireframe et +showbudget est expliquée dans optimiser les performances d’une map GMod.
Checklist pour le test
| Point à vérifier | Ce qu’il faut regarder | Étape |
|---|---|---|
| Spawns | tout le monde spawne dans un espace libre, personne ne meurt au spawn, assez de points pour un serveur plein | 2 avec des bots, 5 |
| Endroits où l’on reste coincé | coins, interstices entre les props, zones derrière les portes : un joueur peut-il en ressortir sans noclip ? | 2, 5 |
| Hors limites | toits, sommets des murs, bord de la skybox : qu’est-ce que les joueurs atteignent en sautant et en empilant des props, et que voient-ils de là ? | 5 |
| Éclairage et cubemaps | parcourir la map une fois avec mat_hdr_level 0 et une fois avec mat_hdr_level 2, vérifier les reflets | 2, 3 |
| Son | les soundscapes changent aux bons endroits, la console ne signale aucun son manquant | 2, 3 |
| Performances | framerate le plus bas à l’endroit où la vue porte le plus loin, pendant que tous les testeurs s’y trouvent | 2, 5 |
| Portes et ascenseurs | plusieurs joueurs bloquent la porte, montent ensemble, sautent pendant le trajet | 4, 5 |
| Navigation | les NPC et les Nextbots atteignent toutes les zones, voir navmesh et AI nodes | 2 |
| Contenu manquant | aucune surface rose et noire, aucun modèle ERROR sur le client vierge | 3 |
Si le client vierge affiche des erreurs, corriger les textures manquantes et les modèles ERROR t’aidera. Ce qu’il faut garder en tête quand tu construis des ascenseurs est expliqué dans ascenseurs et trains.
Recueillir le feedback et le hiérarchiser
Un constat sans emplacement ne peut pas être corrigé. Décide donc avant le test de la façon dont les choses sont signalées :
- Un seul canal, un message par constat.
- Chaque signalement contient le nom de fichier de la map, la position donnée par
getposou une capture d’écran aveccl_showpos 1, le mode de jeu, le nombre de joueurs et ce que le testeur était en train de faire à ce moment-là. - Demande aux testeurs de lancer GMod avec
-condebug. La console se retrouve alors dans le fichierconsole.log, qu’ils peuvent t’envoyer. - Observe au lieu de seulement poser des questions : où les joueurs se perdent-ils, quelles zones restent vides, où tout le monde se rassemble-t-il ?
Trie ensuite en trois classes et traite-les dans cet ordre :
- Bloquants : crash, pas de spawn, endroit où l’on reste coincé sans issue, contenu manquant, un chemin pour sortir de la map.
- Déroulement du jeu : chutes de framerate, positions déloyales, portes et ascenseurs qui se coincent, parcours peu clairs.
- Aspect visuel : raccords d’éclairage visibles, textures mal alignées, props qui flottent.
Ne change rien pendant un test. Collecte, corrige tout un lot, compile, attribue un nouveau nom de fichier et teste de nouveau. Note les questions de goût dès que plusieurs testeurs disent la même chose indépendamment les uns des autres.
Quand la map est prête
La map est prête quand les cinq étapes ont toutes été effectuées avec exactement le fichier que tu publies et qu’aucun bloquant n’est ouvert. Concrètement : le client vierge n’affiche aucun contenu manquant, la console du serveur reste sans erreur au démarrage de la map, la dernière partie avec des joueurs n’a fait apparaître aucun nouveau bloquant, et tu connais le framerate au pire endroit avec des joueurs.
Chaque modification du BSP crée un nouveau fichier. Après une dernière correction, tu répètes donc au moins les étapes 2 à 4. Pour finir, vérifie le fichier avec le Map Scanner. Il contrôle la structure du BSP, signale les entités à risque, vérifie la présence d’un spawnpoint et liste les fichiers du pakfile.
Questions fréquentes
De combien de testeurs ai-je besoin ?
Il n’y a pas de nombre fixe. Un seul testeur avec un client vierge suffit pour trouver le contenu manquant. Pour les spawns, les portes et les performances, ce qui compte, c’est le nombre de joueurs que le serveur aura réellement par la suite.
Puis-je tester avec des bots à la place des joueurs ?
En partie. bot ajoute un bot sur un serveur qui a un slot libre. En solo, GMod refuse avec Cannot create a player bot in singleplayer!. La commande ne nécessite pas sv_cheats 1, mais, comme report_entities, elle ne fonctionne que pour l’hôte ou dans la console du serveur. Les bots occupent des slots et des points de spawn. Ils ne remplacent pas des joueurs qui cherchent des chemins, bloquent des portes et spawnent des props.
Pourquoi mat_wireframe ne fonctionne-t-il pas sur le serveur ?
La commande est marquée comme cheat et ne fonctionne qu’avec sv_cheats 1. Sur un serveur en production, cela reste désactivé. Utilise là-bas cl_showfps, net_graph et status, et refais le test de cet endroit en local avec les cheats.