The series is nearing its conclusion.

This guide focuses on aspects of testing where more than one test subject is required. Often these test subjects will be robots due to a higher success rate of cooperation — approximately 6 seconds, to be precise. Valve created instances for us that can be found in the maps\instances\coop folder (you can study them if you want), but to do the Science from Scratch, read on....

To be honest, nothing much really. A button will still be a button, and a cube or gel dropper, laser, or hard light bridge will still be the testing element that it normally is. In terms of puzzle creation, there are a few differing aspects from singleplayer mode, such as:

• Both test subjects should be involved in solving the puzzle.
  
• All 4 portals should be involved in solving the puzzle.
  
• There are various coop puzzle types, such as separation, role-swapping, or "trust puzzles."
  
• Above all, it should be fun for all — one test subject shouldn't be able to monopolize the puzzle.

To prevent unintended solutions (a.k.a. exploits), glass, grating, and fizzlers are more prominent in coop maps than singleplayer maps. Cube and ball buttons are also more prominent in coop maps because one player can stand on a floor button allowing the other player to do stuff.

IMPORTANT: In order for a custom coop map to be read as a coop map, the filename must start with "mp_coop_".

If you know how to create a custom cube dropper, then it's easier than you might think to begin a coop map. Instead of the env_entity_maker, point_template and prop_weighted_cube at the top, you're going to be using an info_coop_spawn. In Hammer it looks identical to info_player_start, but it's designed to spawn specifically ATLAS (blue) or P-Body (orange) — Aperture Science's testing robots.

NOTE: although you've defined a spawn point for players, you still need an info_player_start in the map to avoid compile issues.

Some perks to differentiating a bot dropper from a cube dropper:

• The skin of the dropper model is always fixed on blue or orange — it never changes, unlike cube droppers.
  
• There are more clipping brushes than you would normally use with a cube dropper, for obvious reasons (you don't want your bots to get stuck on a ledge, now would you?).
  
• Every time the bot is about to drop out of the dropper, the logic and esthetics are slightly different:
  • The dropper should open immediately, so there is a trigger_playerteam to detect when the bot is in the dropper. The dropper opens whenever the bot is in the trigger and closes whenever the bot has left the trigger.
    
  • There is a sound that plays every time the dropper opens: an ambient_generic with sound set to World.RatMazeDownStopAir.
    
  • There is also an info_particle_system set to coop_spawntube_steam that also starts while the dropper is open and stops when the dropper closes.

The spawn room also contains the test chamber sign. Traditionally this turns on when a bot is in the room and turns off when both bots have left the room.

If all of this sounds too challenging or too much for you, there are also a couple of instances you could work into a spawn room.

Yes, these are those special doors with a camera by them, where you can taunt whatever GLaDOS is in your alternate universe. Both players need to be at the doorway for it to open, in addition to the regular stuff required for the door to open (e.g. button or laser catcher).

While you can use triggers, a couple of logic_branches and a logic_branch_listener to do the job, the preferred logic entity to use is logic_coop_manager. In essence, it does what two logic_branches and a logic_branch_listener would do, but it was specifically designed for coop. It simply manages two sets of values, so you can track the "blue" state of something and the "orange" state of something, compare the two, and send outputs based on these states.



Now let's put this into the context of a coop door. Assuming you don't have any additional inputs to the door, you'll need:

• A trigger_playerteam
  
• A logic_coop_manager (initial states are both False)
  
• Stuff for a test chamber door (re-read Guide 04 if you forgot about that) — unlike in singleplayer, it's not expected to close (but you can make it close if you really want to).
  
• An npc_security_camera, "Autostart" flag unchecked
  
• A logic_auto
  
• 4 logic_relays for organization
  
• Two env_sprites, parented to the camera (these will flash on/off to show that a bot is near the camera)
  
• Two ambient_generics, sounds set to Portal.button_down and Portal.button_up (these are the same sounds used in the prop_button, and will play as the sprites flash)
  
• Some overlays (textures set to signage/signage_coop_teamdoor_orange and signage/signage_coop_teamdoor_blue) with two env_texturetoggles that will switch the texture as the sprites flash — similar to the indicator lights checkmark in a way.
  • NB the func_brush entity can be used instead of the overlays here.
• A prop_static with model set to models/props/sign_frame02/sign_frame02.mdl is recommended but not required. In this case the overlays will be mounted on little detail brushes rather than being flush with the wall.

Everything except the camera and the logic_auto will need a name. First up: the settings for the env_sprites:



Now the I/O. The logic_auto will be sending outputs to the sprites to parent them specifically to the camera, just as panel tops are parented to their arm models:



For the trigger_playerteam:



For each of the logic_relays:







For the logic_coop_manager:



...and that's pretty much it. If you have a button or laser catcher set to open/unlock the door, you can funnel all inputs to the door through a math_counter.

From the developer commentary (credits to Garret Rickey):

“Airlocks were introduced mainly as a way to allow players to focus on individual puzzles. In some of our early investigations, areas contained puzzles that were meant to be solved as a group, as well as others that were for individual solution. But we found that if players could move freely between them, they logically assumed that the individual puzzles were part of one big puzzle. This had bad results. For clarity, we created these airlock-like spawn rooms that act as checkpoints between puzzles. Once both players enter the airlock, we lock off access.”

Airlocks are super-easy to create once you know how to create a coop door and a spawn room. They are kinda meant to replace autosaves in singleplayer mode, since coop games cannot be conveniently saved. The basic creation process:

1) Create a door-like mechanism. The classic model uses 4 panels (2 floor, 2 ceiling) that open in front and close behind (more detail for study can be found in the instance maps\instances\coop\coop_flipglass_door.vmf, but beware of excess logic entity usage). Other themes may use other doors such as heavy-duty security doors.

2) Create the stuff for a spawn room, but make sure you name the info_coop_spawns differently than in your original spawn room.

3) When both bots enter the airlock, we're not only going to do all our "open the coop door" stuff, but also switch up the spawn points. Thus you'll need an additional output to the info_coop_spawns:



4) Don't forget a fizzler somewhere in or near the airlock (either just before or just after is best)! Remember, these are the same devices originally designed to prevent test subjects from smuggling test objects between testing areas.

So now you can use to separate puzzles automatically.

...is nothing fancy. In fact, all you need are for both of your bots to reach an "end state," and then send an output to the global_pti_ents instance, just as in singleplayer.

"But what about all that disassembler stuff?" you may be wondering. Well, I've got some good news and some bad news. Good news is that you should by now be able to understand everything it consists of. Bad news: it's almost all details: sounds/music, carefully placed dynamic props, env_fades, and two point_viewcontrols. I recommend studying the included instances if you want to learn about how the disassemblers really work. This includes the underground-themed instances where the robots just drop instead of getting disassembled.

Don't have a partner to test out your cooperative creations with? There are a couple of tricks you can try via the console:

• Use the ss_map console command to load a coop map in split-screen mode. There is a menu option to control how the screen should be split.
  
• To control the second player with one set of controls, use the in_forceuser command (best when bound to a key — I use the R key for this purpose). This is a cheat command and so you will need to set sv_cheats to 1 first.

If you DO have a partner to test with, use and abuse them as much as you can — not only can they point out solving issues in your map, but they might pick up on deeper technical issues and glitches (often related to network usage) that you simply cannot test easily by yourself.

More information from the VDC Wiki:

• The old way to create a coop map (specifically the spawning room)
  
• Doors in coop mode
  
• The behind-the-scenes disc rom (mostly details)
  
• The Disassembler (also a ton of details; sorry I couldn't find the reassembler page...)
  
• Triggers for robots
  
• The trigger_ping_detector entity (for if you're somehow lacking inspiration...)
  
• The info_coop_spawn entity (remember, this does NOT quite replace info_player_start!)
  
• The logic_coop_manager entity
  
• Forever alone as a test subject?

Please note that there are still some works in progress. This section will be updated as I finish more guides for you!

You are currently viewing part 18/19 in the series.

| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 |

Previous Guide (about auto-portals and the rotating portal gun)
Next Guide (the Surprise)

Please feel free to leave a well-reasoned question or comment below. Either I or a qualified Test Chamber Associate (you'll know because they make all the good maps on the workshop) will respond. If your question or comment is not well-reasoned, I recommend reading over my guides again until you understand them 100%. No further information is required here or will be provided, and you will become an excellent Test Chamber Designer — using Hammer!