Portal 2

Portal 2

153 ratings
Hammer for the Flustered
By The Sojourner
New to Hammer? Stuck on how to create a map for Portal 2 using Hammer? Read this guide.
   
Award
Favorite
Favorited
Unfavorite
Hammer for the flustered


So you've decided that the in-game editor, even with BEEMOD or BEE2 or any other mod, is either too limiting or too ugly (of course there's no reason it can't be both). You've decided to get the Portal 2 Authoring Tools and use Hammer to construct test chambers, but you don't have a clue on how to do anything. Well don't worry, this guide should fix you up...and hopefully also prevent lots of empty, boring, and trashy-looking Hammer-made tests already out there. This guide will teach you how to make a test from scratch, just like Cave Johnson and his forefathers recommend. That said, if you're overhauling a map from the in-game editor, I have two suggestions:

1) Follow the outline here from Step 3 onward, and make sure no one would ever be suspicious that you overhauled your test chamber from the in-game/PTI editor! Signs that give it away are:
  • The music: it should be removed.
  • The 128×128 voxel system appears present.
  • Random-ish dirty-looking texture applications with clean button bases, stairs, etc.
  • Anything else ugly-looking and inconsistent.
2) Don't use the in-game editor to begin with!

I've highlighted some other important points in bold.

!!! NEW !!!
Much MUCH more detail can be found in my newer series starting here!

Step 0: become accquainted with Hammer
Open Hammer and Start a new map (File → New or Ctrl+N). Unless you've changed the default settings, you should see four screens: a 3D view in the top-left, and three 2D views elsewhere (a "top" or xy view, a "front" or yz view, and a "side" or xz view). For clearest results:
  • Have the grid on, and have Snap to Grid enabled, and
  • Set the 3D view to 3D Textured or better.
Read the online help files (or guides such as this one), and then read them again whenever you're stuck. They really do help you figure out the program, and they also make a great reference for whenever you don't know about an entity that you would find useful. Some quick tips:
  • The [tl] and [<tl>] buttons at the top are for texture lock and scaling texture lock. Use them frequently to make sure your textures are aligned.
  • The multi-textured button on the left is the face-edit tool. Use it a lot to make your brushes have diverse textures, and also for optimization...oh, and texture alignment.
  • When you right-click on an object in Hammer, you may move, rotate it, and so on with the transform tool — another frequently used feature.
  • Right click → Tie to Entity is how brush entities are created (such as triggers, detectors, func_portal_bumper and func_detail).
Once you're confident in what the items on the toolbars (in particular the left toolbar) and in the menus do (including the right-click menus), you're ready to move onto the next step.
Step 1: design a test
It all begins with a single brush...and then six of them...and then more. First, pick a theme, as this will help the construction process flow more smoothly. The Underground themes are special enough that they'll need their own design. There you should start with a huge Nodraw box and one of those science spheres (use a prop_static and set it to one of the geodome models). If that sounds like too much work, you can use the pre-made instances located in ..\Portal 2\sdk_content\maps\instances\underground (you might still need the Nodraw box though). All other themes can get by by starting with four walls, a floor and a ceiling (no panels yet!).

Once you've decided on your theme, design your test: I recommend first creating the space, and then adding testing elements. The details of how to design a good test are beyond the scope of this guide, so if you need help, check out one of the other guides floating around here. To the right you can see the space I created for one of my tests on the outside.

And here's what it looks like inside:


Entities for standard testing elements:
  • prop_button: a pedestal button. Can be customized for time like in the puzzlemaker, only you can now go beyond 30 seconds if you want.
  • prop_floor_button (prop_floor_ball_button, prop_floor_cube_button): standard Aperture Science Heavy Duty Supercolliding Superbuttons.
  • prop_under_(floor_)button: same as above, but for the underground theme.
  • prop_weighted_cube: the Aperture Science Weighted Storage Cube. Can also be customized to be a companion or redirection cube, as well as a sphere (edgeless safety cube) or an underground cube. You can even adjust the "paint power" of the cube so that it's pre-coated in repulsion or propulsion gel.
  • → For droppers, there are pre-made instances located in ..\Portal 2\sdk_content\maps
    \instances\gameplay
    . Making one from scratch is possible too, and more information about how to do it can be found in this guide.
  • prop_monster_box: here's where you can find your old friend, the Frankenturret (a.k.a. the Frankencube). There are dropper instances for these too if you don't want to make them from scratch (though they may be buggy).
  • npc_portal_turret_floor: for turrets, with more customizable options than you would ever see in the in-game editor. Unless you have one of those story maps, please use these sparingly!
  • env_portal_laser: the Portal 2 laser.
  • prop_laser_catcher and prop_laser_relay: the laser catcher and relay. To get the catcher to look like you see it in Valve's single-player maps and also in maps made by the in-game editor, you have to use a special model: models\props\laser_catcher_center.mdl.
  • prop_wall_projector: the hard light bridge.
  • prop_tractor_beam: the excursion funnel. Set the keyvalue Linear Force to 250 to go forward and -250 to go backward. Anything else is abnormal (but under the right circumstances, can be perfectly OK).
  • info_paint_sprayer: use this little guy for gels, and don't worry about the pipes yet! To make the gels work, you'll need to:
    1) Go to Map Properties under the Map menu, and set the keyvalue "Paint in Map" to "Yes."
    2) Create some light entities (e.g. light, light_spot) so that you can see the gel.
For other standard testing elements:
  • For faith plates, a trigger_catapult (with an info_target and an accompanying overlay) is used along with an accompanying prop_dynamic. There are pre-made instances in the ..\Portal 2\sdk_content\maps\instances\gameplay directory.
  • For deadly goo, create two brushes: a trigger_hurt to kill the player, and a brush for the water (look for the textures in nature\toxicslime_...).
  • For laser fields, you'll also need two similar brushes, only instead of a water texture, you'll be using the texture effects\laserplane in a func_brush entity. Please make sure that the laser field texture is scaled correctly!! You'll also need the side models (prop_static or prop_dynamic, depending on whether or not you want to activate it). Set them to either models\props\fizzler.mdl or models\props\fizzler_dynamic.mdl, and set the skin to 2.
  • For fizzlers, create a brush with one of the fizzler textures (effects\fizzler...), and then make it a trigger_portal_cleanser. Since fizzlers flash whevener the player shoots at them, please use only one brush per fizzler!! Once again, you'll need the side models as described above, but with the skin set to 0 or 1.
  • For flip panels, a func_door_rotating is used.
  • For other panels, a func_brush is parented to a panel model (prop_dynamic). If searching for the right panel model is too much time, there are pre-made instances in the ..\Portal 2\sdk_content\maps\instances\gameplay directory.
  • For moving platforms and such, just use a func_movelinear for now (or func_tracktrain with some path_track entities if your moving platform has a more complex movement). Please do not abuse these. Portal 2 is not designed as a platformer/parkour!
  • Glass and grating (in the metal directory) have their own textures.
  • The info_placement_helper can make portals "snap" to a certain position, and even orientation! Who's seen a sideways portal on a wall before?
Tips:

  • Create some signage using the overlay tool and textures in the signage directory to mark what links to what. You can link testing elements by adding outputs at the activator to the element you're activating. Make sure you have a name on the element you're activating.
  • Create some signage to let test subjects know what does what.
  • Keep the textures aligned now so that you won't have to waste time later.



Before you test your map, make sure you have these three things within very close proximity (see above):

  • An info_player_start and a little space to start the player in.
  • A weapon_portalgun; you can adjust this to fire only blue or only orange as needed.
  • An env_soundscape. I cannot tell you how many times mapmakers have neglected to add a quality soundscape to their maps. Adding one this early will help your map now. You can set the soundscape to anything you want. I usually go with room02.start to start with, and then change this in the art design phase.

    When you're done, test your test using any compile mode you want (a fast compile is recommended; see the image on the left for what I used).


Keep in mind that this is now the ugliest stage of the test. Don't worry; once you've adjusted the proportions and debugged any obvious unintended solutions, you can move on, but not a moment before. (By the way, multiple solutions should be fine unless you want to show off a trick to your test subjects, but everything should be used.)



This is also the place to ask yourself, "where could I trap myself?" If you can find a place, figure out a way for the player to escape and get back to testing. The player should never, NEVER EVER be able to get trapped permanently!! Ever! I cannot emphasize this enough.

Step 2: tidy your test
This is the place to make your test look a bit prettier by adding indicator lights and creating spaces in the walls for:
  • Lasers, Laser catchers, and Laser relays
  • Excursion funnels
  • Fizzlers and Laser fields
  • Faith plates
  • Panels (of all types)
  • Platforms
  • Easter eggs
For creating the standard indicator lights:
  • Use the textures signage/indicator_lights/indicator_lights_floor and signage/indicator_lights/indicator_lights_corner_floor. Apply them using the overlay tool and them strech them accordingly. To make the textures show across multiple brushes, go into the properties of the info_overlay and select which brush faces to apply the textures to. Indicator lights usually require several overlays; you'll need to select all of them and name them all the same so that they'll act as a group.
  • The latter texture is used at corners and also at the activators.
  • To create a checkmark/big X, use a prop_indicator_panel (can also be used as a timer). A border prop is recommended but optional. Checks can be assigned a group of indicator lights. Checks are used primarily used at exits or at recessed elements.
  • If a check is not used, an env_texturetoggle is. Its placement doesn't have to be precise, but place it like you would place a prop_indicator_panel: nearby an element you plan to (de)activate. See the image to the right.
  • I/O: with a prop_indicator_panel, the process is automatic: Check and Uncheck. With an env_texturetoggle, on the other hand, you have to do a tiny bit of extra work: SetTextureIndex to 1 for orange lights, and SetTextureIndex to 0 for blue.
  • Timers are used nearby elements that have temporary operation (or a temporary shutdown). Dropping cubes and gels usually don't need timers.
Tips:
  • Now that you're using Hammer, you can create indicator lights using any path that you please. Try to keep the antlines as short as possible.
  • Use antlines instead of signage as much as you can. Signage should only be used:
    • If it's obvious, such as a cube dropping when the player's facing the dropper, or
    • If the testing element is too remote to be used with indicator lights (I recommend avoiding using many remote testing elements).
  • Use the tools/toolsplayerclip texture and a func_clip_vphysics to keep the player and any testing objects out of the spaces you carved out.
  • Again, keep everything aligned.
Here's what my test looks like after this step:
Step 3: art design
Many beginning test designers using Hammer are lazy, but to make a good map, it takes time. The main reason you're working in Hammer is to make tests look pretty, so DO NOT SKIP THIS STEP!!! To make a test in Hammer is to design a work of art. I've seen all too many maps out there that lack detail or are simply puzzlemaker makeovers. Either way, the effort is lacking.

With that out of the way now, let's get back to your test: it works, it has functionality and plausibility, but the map still looks pretty bland. I'll walk you through a basic process to help you keep your mind together.

After the art design is complete, compile your map using expert compile mode. Don't be fooled by the name! The "expert" part only refers to the mode used by experts; it doesn't mean you have to be an expert mapmaker in order to use it. Not only will your map look 100% better with this mode, this is also the mode that the in-game editor uses. As the screenshot shows, the mode is Full compile -both -final (slow!). Ignore the "slow" part; my map was fairly small and it only took a couple of minutes to compile and run the map — it's only slow with larger maps and/or if you have a slow computer. If you're using any custom materials, models, scripts or sounds, I recommend keeping them in their respective directories for now.

After the art design phase is complete, you'll need to embed them into the BSP using a program such as BSPZip, Pakrat, or VIDE, and then temporarily remove the files from the directories to check that the embedded files work. When they do, your map will be ready to publish.

Step 3a: props and details
The clean theme is the simplest in this department, followed by reconstructing, and then the decayed and Wheatley themes. Behind-the-scenes (bts) areas are some of the most detailed areas, but perhaps what takes the cake for difficulty are the underground cave themes. Not only are these areas fairly detailed, they also require that you know about and can work with surface displacements. For beginners, I recommend sticking to a clean or reconstructing theme.

Getting away from the basic shape
Because rectangular shapes are boring, try detailing your map with some offbeat shapes (e.g. rotate some brushes away from normal if you're working an a theme other than clean). Also, use different textures for variety. Here you can add more portalable surfaces if it doesn't ruin your solution. If a brush or group of brushes ends up being detailed enough, right-click on the group (brush) and select the Tie to Entity option and then hit Enter. Your brushes should now be a func_detail which is designed to save memory and processing power.

To create a custom block shape, first ensure that you have the Object Bar enabled (if not then go to View → Screen Elements and check Object Bar). Now whevever you use the block tool, you can create common curved shapes such as arches, cylinders, spheres and toruses. You can also create wedges and pyramids (the "spike" shape).


Props such as desks, chairs, office/factory machinery, plants, cable boxes, and some cables are created by the prop_static entity, or if there's animation, the prop_dynamic entity. In the Rattman's dens, prop_physics(_override) is also used on objects such as water jugs, coffee mugs, and empty cans of beans. This is a huge chunk of detail work, so take your time working on this.

To create a prop

1) Select the Entity tool and create a new entity in your map by hitting [Enter].
2) Using the Selection tool, right-click and select Properties.
3) Select prop_static, prop_dynamic, or prop_physics(_override) from the Class menu (under the Class Info tab).
4) Select a World Model (and maybe a skin and animation) and you have your new desk, vacuum tube, plant, exposed frame, coffee cup, etc. in your map.

When selecting a world model, try looking in the model browser in:
  • anim_wp: mainly panel-related stuff. Here you can find the panel backsides found in some bts areas and also Wheatley-themed tests. You can also find the square ceiling beams used in the decayed/reconstructing themes in the framework sub-directory here.
  • prop_cables: for cable boxes and miscellaneous cables are located here. You can also use some keyframe_rope and move_rope entities to create cables.
  • props_backstage: for the pipes seen in decayed-themed tests and bts areas
  • props_bts: for catwalks and vacuum tubes, among other things
  • props_destruction: for debris pieces
  • props_foliage: for plants
  • props_lab: for various testchamber-related items such as lights and glass wall borders
  • props_lights: for various lights for use mainly in underground-themed areas
  • props_office: for various office-related props, including wall borders
  • props_test_chamber: for various glass borders
  • props_underground: pretty self-explanatory; for use with underground-themed areas. This is also where the testing sphere models are located.
To keep things realistic, any prop which the player or object can be passed through will need a player_clip brush and/or a func_clip_vphysics (with few exceptions such as plants).

Tip: for underground gel pipes, changing the color will only change the color of the arrow. Change it to a blue for repulsion gel, orange for propulsion gel, gray for reflection gel, and cyan for water/cleansing gel (leave it white for conversion gel).
Step 3b: lights and sound
Now that you've gotten your props in, let's look at lights. For the basics, we have:
  • light: this shouldn't be the only light entity in your map. If it is, then your map will be boring and frankly, quite ugly.
  • light_spot: this entity is for creating focus areas of light, like a spotlight does.
  • beam_spotlight: creates a super-focused beam of light. Used on lamps such as the single lights seen in the underground theme.
  • env_projected texture: creates a light that casts shadows; also makes a great flashlight. Unfortunately, only one of these guys can be active in any map. Also, you'll need the global_ents instance in order to make it work since it contains a point_clientcommand entity with a command of r_flashlightbrightness 1 (default is 0.25) in order to fix the problem.
  • light_environment: use in conjunction with skyboxes (primarily the decayed and early reconstructing themes). I recommend setting the Pitch keyvalue to about -90° so that you'll see the effect.
Note: many of these light entities can have their color and appearance changed. Try something colorful if you want to give your test subjects a relief from the gray, drab environment that is the standard Aperture Laboratories complex.

For sounds, use an ambient_generic and look/listen for the game sound you want to play. One known bug is that sounds in the vo directory don't preview. Check out this page[theportalwiki.com] to find out which sound file will correspond to which line (be it from the Announcer, Cave, GLaDOS, the defective turrets, or any of the personality spheres). If you know a bit about scripting, skip the ambient_generics and use a generic_actor named @glados instead. You'll likely need a custom script.

For soundscapes, you can preview these with the playsoundscape console command. Here are some common groups of standalone soundscapes:

Recommended for decayed- or early reconstructing-themed tests:
  • Beginning with TestChamber_Destruction: used in Act 1, in decayed-themed tests.
  • TestChamber_Destruction.WindEerie_01: gently blowing wind, used in Act 1.
  • TestChamber_BTS.Drone: used just before waking up GLaDOS and just after exiting with Wheatley.
  • Beginning with Testchamber_Industrial: used towards the beginning and end of Act 1, during the container ride sequence and also in the map with the incinerator.
  • TestChamber_Vegetation.Intro_01_...
  • TestChamber_Vegetation.Insects_01/02/03
  • TestChamber_Vegetation.Elevator_01
  • TestChamber_Vegetation.Standard
Recommended for clean-, reconstructing-, or Wheatley-themed tests:
  • Beginning with Testchamber.Industrial: various clean-themed soundscapes which also sound good on later reconstructing-themed tests.
  • Testchamber_med_01 and Testchamber_med_01a: same as above.
  • Beginning with Testchamber.liquid: used nearby poison water (deadly goo).
  • TestChamber.clean_liquid_01 and TestChamber.clean_liquid_02: same as above.
  • Beginning with Turretchamber: used in Act 2, tests 13-18. You don't need turrets in your test to use these soundscapes
  • Beginning with room01-room06: used in the coop maps, these soundscapes have their mapname attached to them. These soundscapes also sound good in singleplayer maps too.
Recommended for bts areas:
  • Beginning with sab (for sabotage): used during Chapter 5.
  • Beginning with finale: used during Chapter 9.
Recommended for underground-themed areas:
  • Beginning with ug: used in Act 3.
  • Beginning with ug_sphere: specifically used inside the testing spheres.
Miscellaneous:
  • Beginning with portal: soundscapes from the original Portal. Not all sounds in certain soundscapes here are present.
  • Beginning with portal_testchmb: These soundscapes were originally context-sensitive for use inside test chambers. Best used with clean-themed tests.
  • Beginning with portal_escape: used during the post-test period. These soundscapes are mostly out of date, but if you want to use them, I recommend using them in a bts area.
  • Those at this page except as noted below.
These are utility soundscapes, not meant to be used on their own:
  • TestChamber_BTS.Comb
  • TestChamber_BTS.Crystal
  • TestChamber_BTS.Generator
  • Testchamber_Destruction.DestructionBeauty
  • Testchamber_Destruction.Grain_Click
  • TestChamber_Destruction.MetalGroan_01
  • TestChamber_Destruction.MetalPipe_01
  • TestChamber_Destruction.WaterDrip_01
  • TestChamber_Industrial.BowedMetal_01
  • TestChamber_Industrial.ScrapedMetal_01
  • TestChamber_Industrial.WarehouseImpact_01
  • TestChamber_Industrial.WarehouseImpact_02
  • TestChamber_Industrial.WarehouseImpact_03
  • TestChamber_Industrial.WarehouseWronk_01
  • TestChamber_Industrial.WarehouseWronk_02
  • Most soundscapes beginning with TestChamber_Vegetation (exceptions noted above)
  • Beginning with util or warehouse
  • utility.metal.imp.lo
SOUND TIPS:
  • For ambient_generic entities, ensure that the volume is not always all the way up to 10! I recommend (roughly):
    • ~7 for voice-over lines, including the dingon/dingoff sounds from GLaDOS and the Announcer
    • ~5 for music
    • ~4 for ambient background sounds
    • ~9-10 for explosions and destruction, but only for explosions and destruction.
  • Don't use ambient_generics in place of soundscapes, even partially!
  • Music is optional, soundscapes are a must-have.
Step 3c: adding an official entry and exit
If you don't have a custom story line, you're going to have an entry elevator and an exit elevator. To help, there are ready-made instances. Look in ..\Portal 2\sdk_content\maps\instances\
turbine_elevator
to find various elevator instances. Make sure the exit is linked to the global_pti_ents instance or the level won't end properly! With custom story lines, make sure you have some output (trigger or otherwise) to this same instance. An env_fade entity is recommended too.
Step 3: finishing up
To reiterate, you should be using "expert" compile mode (again, that's Full compile -both -final (slow!)), and then run your map using various settings (shader on high, shader on low, with good antialiasing, without antialiasing, etc.) and check to see that it still looks good, especially on lower settings (keeping the compensations in mind). When there are no problems, you can move on to the next-to-last step. Below you can see my map after this step:


Step 4: Anything else? (scripting, text, etc.)
You've worked hard and put some good hours and good effort into your map, and it's sure to get some good ratings because of it. Here are some final touches:
  • Optimization
    • Texture everything facing the void with Nodraw (see image at right for my test after doing this). Then check the inside of your test to make sure there's no Nodraw showing (it looks funky and ugly during gameplay). If you have time, redo the invisible textures in between brushes too.
    • For large areas such as Wheatley-themed tests, create some func_visclusters and use the "lod" models to save processing power.
    • Use func_areaportalwindows in doorways. They can actually be tied easily to a prop_testchamber_door.
  • Create some game_text entities to introduce your chamber and also to thank the player for testing upon leaving.
  • If you're an advanced mapmaker, put on the ultimate show with custom scripts or non-standard entities like HMW did with his Sendificator.

Step 5 (Final step): preparing to publish
To get your test ready to publish, you should do these things:
  • Create at least one high-quality screenshot of your test. Even if you have a low-end system, you can do it, as it's only for a few shots. You'll need to:
    • Type crosshair 0 into the console
    • Type r_drawviewmodel 0 into the console
    • Use noclip and get yourself into position
    • Press F12 to take your screenshot. The screenshots will then be located in C:\Program Files (x86)\Steam\userdata\<some number>\760\remote\620\screenshots.
  • Embed any custom stuff used into your map. To reiterate, you'll need to embed them into the BSP using a program such as BSPZip, Pakrat, or VIDE, and them temporarily remove the files from the directories to check that the embedded files work. When they do, your map will be ready to publish.
Publishing your map

You'll need to use the Portal 2 publishing tool, located at C:\Program Files (x86)\Steam\
SteamApps\common\Portal 2\bin\p2map_publish.exe
. Click on "Add" and fill in everything except the description (unless it's really short). When you go to view your map on the Steam workshop, you can edit the description and add additional screenshots, and even a solution video or two if you want.

Here are a couple of those high-quality screenshots I'm talking about (of my map).
Title page:



And a secondary screenshot:


You can play the finished map here.

The Playtesting Phase
Here's one of my latest maps. Play it first and observe the quality of the map...

http://steamcommunity.com/sharedfiles/filedetails/?id=307183793

...now check out these notable facts about it:
  • This map was developed from the Puzzlemaker! It doesn't initially seem like it, but I needed a quick tool to help me conceive a puzzle idea. When I felt that the puzzle was good enough, I exported it using the puzzlemaker_export <mapname> console command. The takeaway point is this: when developing puzzles, work with whatever tool makes you feel comfortable.
  • This map had about 70+ hours worth of time spent on working on it. I did this in phases: first adjust the floor, then adjust the puzzle elements, then adjust the walls in the main room, then adjust the walls in the other room, then adjust the ceiling, then make the entrance and exit areas, and finally, adjust the outside area. For the first few phases of development, I was getting rid of the voxel system and texturing everything with the nodraw texture. It is important to always think about what to do next and how to go about it. It's also important to take your time with Hammer maps, since they are meant to be works of art.
  • When I felt that this map was ready, I compiled it, fixed any problems that arose (red text; usually this is some sort of leak), and tried again. I hoped for perfection, but I got just the opposite! I knew to expect problems, and I had Notepad at my side so I could make a list of all the little bugs that needed fixing. This map went through 20+ compilations from fixing baches of easy-to-fix bugs to debugging the harder-to-fix bugs. What's the point here? Don't expect your maps to be perfect on the first compilation!
  • While I was fixing the tricker bugs, I constructed about 5 or so little "test maps" to see how various things work and to see if I can fix an issue. This worked better because the map was so big and took about 5-6 minutes to compile each time. However none of these maps got uploaded because they weren't worth uploading. If you're creating such a "test map," please keep it to yourself! You won't get much credit for creating a "test map." Just learn from it and move on.
  • Before releasing the map, I found out that there were still some unintended solutions that needed fixing, and so I added the colored fields in the upper room to fix that.
  • Finally, I embedded the custom content into the map using Pakrat so that users would not need to inconveniently download anything and put it into the correct folders or complain about "missing <insert file name nere>."
I say this because there are too many maps out there that:
  • Look like the user is inexperienced with Hammer or how anything works behind-the-scenes. Maps based on the "preview.vmf" file are not uncommon, and quite annoying since they will continually repeat themselves. Although there is an option in the entrance and exit instances to disable that continual looping, I recommend using the puzzlemaker_export <mapname> console command instead. Better yet: create your own entrance and exit systems like I did.
  • Don't deviate enough from the Puzzlemaker's voxel system, even with stuff as fancy as TeamSpen's addons for BEE2. I was aware of this and varied the world geometry somewhat to make this map say, "Made in Hammer" and not "Exported from Puzzlemaker."
  • Don't use the official Full Compile mode (let alone any better custom one).
  • Don't have the custom materials embedded. Just because it works on your own computer doesn't mean it'll work on someone else's computer.
  • Look like it was compiled once and never bug-tested offline (before anyone except maybe a select few friends/playtesters gets to see it).
  • Is one of those "test maps" I was talking about above. This also includes maps that lack detail.
  • Use a weird, inconsistent art style (e.g. random-ish texture usage). Unless you have something really good in mind, please just stick to a basic theme already seen in the main game.
  • Are essentially deficient in one or more of the following categories: puzzle (too easy usually, but it could be that it requires skills that don't fit the style of the game), sound (especially soundscapes), visuals (e.g. the highly detailed props), lighting, and functionality (e.g. do things work like they're supposed to?).

To see how you can progress as a Hammer mapper, here's one of my more recent puzzles:

http://steamcommunity.com/sharedfiles/filedetails/?id=415806041

This one didn't need nearly as many side/test maps as the other one. I was able to spot bugs earlier because I had gained experience with that Source-based 3D canvas one calls Hammer.
Conclusion
You have now been conducted through a tour of what it takes to become a Portal 2 Hammer mapmaker. We at Aperture Laboratores with you the best of luck and hope you have fun with your test design and art design.

Let me know if you have any other tips worth adding, and keep in mind that this is not a detailed guide for advanced Hammer test creation — only the basics. If you want more detail, check out my new series here.
80 Comments
InsanityWaffles Apr 19, 2019 @ 11:05am 
I cannot figure out how to make a push-door work.
The Sojourner  [author] Apr 16, 2019 @ 9:37pm 
What you're thinking of is reskinning the in-game models. That is an advanced process that's beyond the scope of this guide. It can be done though (josepezdj consistently does it to beautify his maps).
😭😭😭 Apr 13, 2019 @ 6:25pm 
im not sure if you still look at comments for this, but i have been trying to find a way to change the brush textures for things like button bases or the ceilings above droppers. i just havent been able to, and i cant find anything in this guide that even mentions it other than the top, which helps with nothing. could you maybe help me figure out how to change this.
RayOfLight Jul 18, 2018 @ 6:03pm 
Couldn't find the answer to this using Google, but I figured you might know. Is there any way to disable the cube auto grabbing that happens when you're moving at a certain speed?
InsanityWaffles Jul 2, 2018 @ 2:14pm 
Oh okay. Thanks! ;)
Solar /\/\aster Jun 30, 2018 @ 11:09am 
Nevermind, I've got it to work. Thanks anyway (=
The Sojourner  [author] Jun 30, 2018 @ 1:10am 
You need to have the emoji (and just one is enough) in your inventory. You can trade for them, find them in the community market, or craft a set of Portal 2 trading cards. It's been on Steam for a while now.

(also: the :p2cake: is...)
InsanityWaffles Jun 29, 2018 @ 11:43am 
:p2aperture:
Also, how do you get those emojis? It never works for me.
The Sojourner  [author] Jun 29, 2018 @ 8:42am 
Cube droppers can be a little tricky when first working with them. If you haven't already, check out this newer guide. Hope that helps :p2aperture:
Solar /\/\aster Jun 28, 2018 @ 7:02pm 
Thank you so much for the guide, but I'm having trouble with the droppers, because I have three droppers in one map, and each dropper seems to be spawning multiple cubes, and using dropper_multiple doesn't seem to work. Do you know how to fix this?