Good etiquette for map designers?
The maps from Valve that came with Portal seemed to have some standards that many custom maps don't have. Is there a consensus on whether those standards should be followed in custom maps?
I have some examples:
1. In the original game, there were clues such as the chequered floor to let you know that you will probably create a portal on the floor and fall into it from a height. Or little signs that tell you to do a fling, etc.
But in custom maps should you have to provide those? That's giving things away, isn't it? By the end of the Portal game, people should know techniques for solving puzzles. So if you build a room that requires a fling, should you have to put some indicator or just let the player figure it out?
2. It seems like a companion cube (the one with the hearts on it) should be carried with you, until either an incinerator or the end of the map. The implication is that you are going to use it over the course of several rooms, so bring it with you. A standard cube, on the other hand, seems like it could be discarded as soon as it appears like the puzzle that used it is complete. But some custom maps seem to use companion cubes willy-nilly, perhaps just because they can.
So my point is, suppose you have several rooms that require the cube to solve, and the player is expected to carry it with them to do so. Should it have the heart on it to indicate carry it with you? Suppose they go from one room to another where you can't return, but they didn't bring the cube? They are effectively trapped. Is that okay to do? They may not even realise they need the cube and try vainly to solve the room. Should you always provide a way to go back and get a cube?
3. Suppose you have a hole in a ceiling, for example, and on the way down you're expected to shoot a portal into a certain spot on the wall (which you couldn't see before the fall). On the way down the first time, you don't know that. You realise it as you fall but of course you miss it. So you have you reload a saved game. Should you have to provide a way to return and try again? Isn't it unfair to expect the player to do something they can't know in advance?
I've seen on other posts where people frown on rooms where you have to die to discover something. It seems like a good portal map should be theoretically solvable the first time through without dying or being trapped. Is that a reasonable thing to expect in a good map?
Any other standards that should be adopted by custom maps? For example, I've seen some that let you shoot portals onto walls that are metal which the original game didn't let you do. And not accidentally, some of these maps do it deliberately. Custom maps should adhere to the standards in the original game, shouldn't they?
A few design standards I try to follow (I'll add more if I think of it):
Hints (signs, checkered floor, etc.)
Portal-vanilla: The game is essentially a learning experience, designed to teach the player from start to finish.
Portal-custom: The player has already been taught a large number of concepts in the original game and are generally seeking a maps that provide somewhat of a challenge. Hints should be limited to new techniques or non-puzzle elements (ie. box dropper sign).
Storage Cube vs. Companion Cube
The SC is dispensable and it's purpose is often central to a single puzzle. If it is destroyed, the dropper should should deliver a replacement. The CC is used as a companion, accompanying the player through the entirety of a map. The player should not be able to be separated from the CC or destroy it prematurely.
Progression
The player should never need to save/reload or die in order to finish or figure out a map.
Portal Placement
Portals should not be able to be placed on metallic surfaces - ever.
Don't speak for the whole player base. Personally, I prefer maps that use the same sort of highly polished techniques as the original. In short, what I'm looking for is more of the single player.
The single player works (i.e. is fun) because of the hinting and clever mapping. To ignore those things because you think your map is too good for that is to lose players like me.
Also, a great deal can be learned about these sorts of hints in the developer commentary. Things like how the Companion Cube was born out of a need to convey the message that this cube was to be taken along. The logical assumption is that any time you need to carry the cube, it should be companion, but in a way that adds cohesion throughout the level. Have a Companion Cube for two chambers out of a ten chamber map is stupid, obviously.
On the other hand, if a cube from a previous room is needed, make sure to allow for backtracking in case it was not brought.
As for the "no way out" problem, that was tackled in a map by CassataGames, with some help from the community. Essentially, through use of some entities, it is possible to detect if both portals are inside a closed space. If you have no way to escape, these entities fire off an output, which you can use to give the player another way out.
And to the core idea of the thread: use, a centralized list would be nice. A Style Guide, of sorts, I suppose. If enough content gets agreed upon, we should add it to the wiki.
I didn't ("generally"), but if you visit any forums you'll see that the issue of a maps difficulty is always brought up - players want a challenge, they just don't want to be mind (or twitch) raped.
I agree. All standards listed above need to be met for me to consider a map to be a Release rather than a Work-In-Progress. In the past there have been some WIP maps that broke some of these conventions and usually the broken standards were already a planned change or they were fixed in the course of the feedback and revision process. To me adhering to these types of notions of the community is the difference between a good map and a great map.
Here are a couple more standards that I think ought to be met for a map to be considered complete:
1)Buttons are pressed/held by boxes or the player character, not turrets or cameras.
2) Multiple instances of the same texture in your environment need to all react the same way to a portal being opened on them.
3) Emancipation Grids should either fizzle everything the player carries through or there should be signage to note a difference, like a cube friendly grid.
4)Helpful sound effects need to be triggered when you change something in the environment. For example, the press of a button opens a door in the next room which cannot be seen from the button location. (I want a sound on the button indicating open or closed and, if near enough, I want to hear the door so I know at least which direction it is in.) A really well designed map allows you to see the door you are effecting, but the sound effects are generally good enough for me.
That's all I got for now.
It's not a case of thinking it's too good, but I don't want to make it too easy and give things away. For example, I'm not keen on putting the chequered floor down where you're supposed to fling. Shouldn't the player have to figure that out?
I like the notion that the Portal game from Valve was the "training", and that custom maps put you in the "real world" where you don't get hints, but have to use what you learnt in the test chambers. For instance, players should be looking for opportunities to fling, not look for the chequered floor that tells them "fling here".
Does anyone know more about this? Or even better, how can I detect if a player went through a door (which doesn't re-open), but the cube is on the other side? I'd like the fade out to black and inform the user they can't continue without vital equipment or something like that.
I've played a few maps where this happens, and it always seems frustratingly unforgiving to me.
I don't mind it at all. However, in maps that do have that, I feel that auto save points are a must. It's not fair for the user to have to repeat the entire map just because of one slip up.
Wouldn't just adding a couple of trigger_multiples and some kind of logic_(relay?) work? One trigger with a cube-filter in the area where we can loose the cube, which activates the logic, and the other trigger in the doorway (or in the room beyond) with "clients" checked, which gives the logic an output, keeping the door open. Thus keeping the door open if the the cube is in the the wrong area and the player is in the right.
Might not work at all, haven't been using logics too much 
Triggers and logic can almost always detect if the player is seperated from thier belovd cube. The only problem is sometimes you need lots and lots of triggers detecting varoius things and logics turning things on and off to detect things only when other things are happening and it gets quite complex if you don't design your level well enough.