This post was originally posted in the Steam Users' ForumsA great map is well-lit, clearly laid out, appropriately sized and properly tested.
The Puzzle Maker tools are awesome, but they do need to be used with some common sense! So after playing a whole bunch of custom maps recently, I just wanted to point out some things you should/shouldn't be doing, and I've split them into Map-making
.Please note that this refers primarily to Puzzle Maker maps being released to a general audience in the Steam Workshop. Therefore these are the rules and principles you should work by in order to get the best reaction from the Community as a whole.
Many of the principles, however, still apply to Hammer-enhanced/built maps and concept maps.Map-making
At Aperture Science, test subjects don't have 'Restart' buttons.
- Always have a clear entrance (obviously) and exit. Don't be too cruel.
- Light your maps. Just a simple strip light here, an observation window there...
- That said, don't over-light your maps, or they might become ugly and even harder to solve.
- Enough with the ma-hoosive empty chambers! Yes, it's impressive that you can create space now, but if you're not going to use that space for dramatic or puzzle effect, keep it smaller. Map after map of temple-sized chamber gets REALLY tedious.
There are already dozens of thousands of maps out there. If your map is no fun, people will give up and move on.
- Portal 2 has a story, a setting and characters. Whenever a player goes to the main menu, or is forced to manually restart their map, they are taken out of that story, and this ruins the experience. It's a fundamental game design basic: never force your players out of your game. It's sloppy. Kill them if you have to, but keep it within the world of the story. If you've allowed them to get stuck somewhere (see Play-testing below for how not to), then just kill them. Deadly goo is the best way.
- A player should only die because they made a mistake. Don't force them into sudden, unexpected death, expecting them to 'learn from their mistake next time'. They should be aware of the threats before having to deal with them.
REMEMBER: There's a difference between challenging and frustrating!Play-testing
- Give players a sporting chance and show them as much as possible. Avoid too many labyrinth-like corridors, unless they are entertaining in some way. Dull stretches of nothing with little visual candy are rarely appreciated.
- Don't make solutions *too* obscure. Try and at least make it that most initiators (buttons, lasers etc.) either have clear indicator lights to their target, or that you force the player to be looking in the right direction as they press a button. Pressing a button in one chamber, only for it to do something tiny four chambers away is very frustrating. Use windows to show players the results of their actions, even if you don't want to give them access to that other area just yet.
- From ddrkreature: "Having [the map] hard, confusing, big, AND labyrinth like will just frustrate and bore the player. Having a simple enough looking room where they can look around without moving and see everything but at the same time have a complex solution can keep the player's interest and persevere as they don't have to continue moving around all the time to find something they may have missed. Drive the player nuts by having the solution hidden in plain sight."
- Avoid forcing the player to use moves or techniques which don't fit with what Aperture would really be trying to test. Tricky feats like cube stacking, bunny-hopping etc. aren't a lot of fun for most people. In other words, keep it realistic - well, as much as possible anyway! Real-world physics puzzles are more satisfying than just exploiting what the Source engine can do.
- Tests should have solutions that are challenging to discover, but easy to execute. Not everyone has a nice, smooth mouse, and there's nothing worse than knowing how to complete something, but not being able to.
- Don't make players run backwards and forwards all the time; give them aerial faith plates or easy portals to transport them.
- Avoid red herrings. This isn't a guessing game! This is a game of logic and puzzle-solving. Therefore, Every testing element in your map should be relevant, so that a player looks at it and goes, 'where does that fit?' One exception to this is wall panels: by all means have lots of portalable walls that never need to be used, because otherwise you'd just be creating a puzzle 'on rails'.
- Don't create a puzzle 'on rails'. Give 'em some kind of challenge!
- Make your maps look interesting. Use portalable/un-portalable walls to create interesting, contrasting patterns. Let bits of wall stick out and others carve into themselves. Add lights as decoration. No one likes a boring box!
To record demos:
- Play-test your maps. I've played so many maps where I've ninja flipped to the end, or bypassed a whole load of puzzle elements because you forgot to check your walls for portal solutions (it's in the title, guys) or just didn't think about how you were placing your objects. I've been working on just one map so far, and I must have playtested it at least 50 times already. You wouldn't want people to ignore all your hard work, would you?
- Play-test every single scenario so that you know where a player might get stuck: what happens if the cube is destroyed? What happens if they forget to take the cube/take the cube when they shouldn't? What happens if there's nowhere to portal to? What happens if they go through the door BEFORE x, y or z?
- Play-test your own maps, but also have other people playtest them; preferably someone new for every major update. A second pair of eyes can spot SO much more than you can sometimes, and it's very beneficial!
- Playing someone else's map? Send a comment their way afterwards with constructive criticism.
- Getting other people to test your maps? Encourage them to record a .dem of their playthrough:
To play demos:
- Open the developer console;
- Type the following: record demoname (where 'demoname' is the name of the demo);
- Hit return/enter;
- That file would save as 'demoname.dem' in Steam\steamapps\common\portal 2\portal2
- Place the .dem file in Steam\steamapps\common\portal 2\portal2;
- Open the developer console;
- Type the following: playdemo demoname (where 'demo name' is the name of the demo);
- Hit return/enter
To be able to play the demo, you need to have subscribed to your map in the Workshop and have it downloaded in the game, as the demo needs this to play.And finally....
- If you've played the first Portal, you'll know all about the Companion Cube: a unique cube that the test subject becomes emotionally attached to, and keeps by their side at all times. In truth, you should avoid having more than one CC in a map; it should preferably be the only cube in the map, or the one required to exit the map, or a hidden Easter egg. Alternatively, you could use multiple CCs at once to achieve a particular effect, but make this very clear (such as having them all stand in a row). Don't insert random CCs without a reason for doing so; just use a standard/Franken cube otherwise!
- The jury's still out on CC dispensers for damaged CCs, as a CC dispenser can actually be a joke about how devious/wasteful Aperture is.
This isn't meant to be negative or snarky or anything, it's just meant to help. These tools are great, but they're just that - tools
. They need intelligence in order to be wielded properly!Additional Reading
I've started to see some great topics crop up regarding Puzzle Making, so I'll list some great ones here:
- 'Too many items' error: Unable to build your puzzle because of this error message? Catsy's come up with some great tips, including approximate values for each in-game element.
- List of Developer Console commands: you may not need all of these, but there are some (hide crosshair and portal gun, noclip) that are particularly useful for creating really clean shortcuts to upload to the Workshop.
Any other suggestions, drop 'em below!