Playtest a GMod map: testing with players in five stages
Playtest a GMod map before it goes live: five stages from the solo pass to a round with players, with console commands, a checklist and feedback rules.
Test a GMod map in five stages: final compile, a solo pass with the developer console, a test on a clean client without your content, a test on a dedicated server and finally a round with real players. Alone on your own machine you are server and client at once and have every file locally. Missing content, jerky elevators, too few spawns and drops with many entities therefore only show up in the later stages.
Why testing alone is not enough
- You are server and client at once. In single player the client skips prediction. On a server every client predicts its own movement, and the server corrects it when it arrives at a different result. This is most obvious on moving platforms: vertically moving platforms look jerky to the players riding them in multiplayer.
- Your machine has every piece of content. Textures, models and sounds sit in your game folder, plus any mounted games. A tester only has what is inside the BSP or what the server delivers.
- A server runs without cheats. Many diagnostic commands need
sv_cheats 1, and on a server the value is 0 by default. You do the analysis locally and use the server for observing. - More players mean more entities. Every player, every weapon and every spawned prop is an entity. Spawns, doors, frame rate and the edict limit are only tested under load.
The test plan in five stages
- Final compile. Only test the file you will publish: full VVIS, VRAD with
-final, cubemaps built, content packed. The check of the file itself is described in check a BSP before release. Give every test version its own file name, because the server turns away clients with a different BSP (Your map [...] differs from the server's.). - Solo pass. Load the map locally, enable
developer 1and walk through all of it: every door, every button, every elevator, every ladder. Read the console afterwards. Then start a game with several slots and fill them withbot. That shows you whether the spawn points are enough. - Clean client. The launch options
-noworkshopand-noaddonstemporarily disable Workshop and folder addons. Loose files in the game folder and mounted games stay in place, though. A second machine or a tester who never had your content is more reliable. - Dedicated server. Load the map on a dedicated server and connect. Read the server console at map start, check that map and content reach the client (see FastDL and Workshop), and ride every elevator with real ping.
- Real players. Play the map in the gamemode it is made for, with as many players as possible. You observe and take notes, you explain nothing.
Console commands for stages 2 to 4
| Command | Shows | Needs sv_cheats 1 |
|---|---|---|
developer 1 | additional messages in the console and at the top left of the screen | no |
cl_showfps 1 | frame rate | no |
net_graph 1 | frame rate, latency and packet data | no |
cl_showpos 1 | current position | no |
getpos | writes position and view angles to the console | no |
status | map, players and connections | no |
report_entities | entities counted by class, plus the total with edicts | no, but only for the host or in the server console |
+showbudget | time per frame by engine system | no in GMod (the cheat requirement in the Valve wiki applies to other Source games) |
mat_wireframe 1 | everything drawn as wireframe | yes |
mat_leafvis 1, r_DrawPortals 1 | current visleaf and areaportals | yes |
r_drawclipbrushes 1, vcollide_wireframe 1 | clip brushes and collision models | yes |
showtriggers_toggle | trigger brushes | yes |
nav_edit 1, ai_nodes | nav mesh and AI nodes | yes |
soundscape_debug 1 | lines to every env_soundscape, the active one in green | yes |
A sensible start for the solo pass:
sv_cheats 1
developer 1
cl_showfps 1
cl_showpos 1
report_entitiesNote the total from report_entities on the empty map. It is your baseline before players and props are added. In the console of a dedicated server, stats also prints performance values of the server. How to find causes with mat_wireframe and +showbudget is covered in optimizing GMod map performance.
Checklist for the test
| Check | What to look for | Stage |
|---|---|---|
| Spawns | everyone spawns free, nobody dies at the spawn, enough points for a full server | 2 with bots, 5 |
| Stuck spots | corners, gaps between props, areas behind doors: can a player get out again without noclip? | 2, 5 |
| Out of bounds | roofs, wall tops, the edge of the skybox: what do players reach by jumping and stacking props, and what do they see there? | 5 |
| Lighting and cubemaps | walk through once with mat_hdr_level 0 and once with mat_hdr_level 2, check reflections | 2, 3 |
| Sound | soundscapes change in the right places, the console reports no missing sounds | 2, 3 |
| Performance | lowest frame rate at the point with the longest view while all testers stand there | 2, 5 |
| Doors and elevators | several players block the door, ride together, jump during the ride | 4, 5 |
| Navigation | NPCs and Nextbots reach all areas, see navmesh and AI nodes | 2 |
| Missing content | no pink and black surfaces, no ERROR models on the clean client | 3 |
If the clean client shows errors, fixing missing textures and ERROR models helps. What to keep in mind when building elevators is covered in elevators and trains.
Collecting and prioritizing feedback
A finding without a location cannot be fixed. So decide before the test how things are reported:
- One channel, one message per finding.
- Every report contains the file name of the map, the position from
getposor a screenshot withcl_showpos 1, the gamemode, the player count and what the tester was doing at the time. - Ask the testers to start GMod with
-condebug. The console then ends up in the fileconsole.log, which they can send you. - Observe instead of only asking: where do players get lost, which areas stay empty, where does everyone gather?
Then sort into three classes and work through them in this order:
- Blockers: crash, no spawn, stuck spot with no way out, missing content, a way out of the map.
- Game flow: frame rate drops, unfair positions, jamming doors and elevators, unclear routes.
- Looks: lighting seams, misaligned textures, floating props.
Change nothing during a test. Collect, fix a whole batch, compile, assign a new file name and test again. Note matters of taste once several testers say the same thing independently of each other.
When the map is ready
The map is ready when all five stages have been run with exactly the file you publish and no blocker is open. In concrete terms: the clean client shows no missing content, the server console stays free of errors at map start, the last round with players produced no new blocker, and you know the frame rate at the worst spot with players.
Every change to the BSP creates a new file. After a last fix you therefore repeat at least stages 2 to 4. At the end, check the file with the Map Scanner. It verifies the structure of the BSP, reports risky entities, checks whether a spawnpoint is present and lists the files in the pakfile.
FAQ
How many testers do I need?
There is no fixed number. A single tester with a clean client is enough to find missing content. For spawns, doors and performance, what counts is the number of players the server will actually have later.
Can I test with bots instead of players?
Partly. bot adds a bot on a server with a free slot. In single player GMod refuses with Cannot create a player bot in singleplayer!. The command does not need sv_cheats 1, but like report_entities it only works for the host or in the server console. Bots occupy slots and spawn points. They do not replace players who look for routes, block doors and spawn props.
Why does mat_wireframe not work on the server?
The command is flagged as a cheat and only works with sv_cheats 1. On a live server that stays off. Use cl_showfps, net_graph and status there, and repeat the spot locally with cheats.