I usually do both layout and detail at the same time (per room or area) as they influence each other. Not always the best method. Blocking out the entire layout first works for some people, but can also be somewhat restrictive.

I guess in modern games, and probably for dm levels, it's pretty much mandatory to get layout and gameplay/flow right beforehand. Quake's monsters, however, are so versatile (or simple) that you usually don't need much pre-structuring to make them work.

It's good to have some ideas before starting the map, how rooms are supposed to look and connect to others, what puzzles and gameplay situations might be interesting in them, and so on, but quite often the map just evolves dynamically depending on what's already there, so to speak. After a while, one gets a feeling for it.

Perhaps try drawing some layout ideas on a grid paper and see how you can expand them. Keeping the principles of deathmatch levels in mind while coming up with a layout can help. Floors at multiple height levels that interconnect or meet in open areas/atriums maybe. Of course you could also create a room and just add a bridge somewhere above, or two doorways - something that forces you to connect other areas to, and eventually it may come together as a proper layout.

If you lack general inspiration, just play a few custom levels and examine how it's done there (noclip around on and look from the outside). Or check the inspiration&reference thread. 

There is a thread about the design process, might be helpful to you, though it's more about overall methodology than specific gameplay design.

http://www.celephais.net/board/view_thread.php?id=60554 

Blocking out the whole layout before detailing can be boring, but tends to make the creation of the map happen much faster, since you waste less time detailing areas you later redesign or throw away. Coming up with a theme idea before that is a good idea though, since the setting might well influence the design and architecture quite a lot - even at the rough stage.

I think adding a few monsters during the block out phase, even if it's not final gameplay, is very important, since you need to test how they handle the geometry and for ogres in particular, how effective they are. Ogres can be UTTERLY ineffective if placed too high or low, and whilst their presence alone and rain of grenades might make the player twitchy, if they realise all the grenades are missing the combat loses its urgency. Basically, if you build some ledge somewhere with the intent to populate it later and have monsters attack the player from it, just test a couple of different monsters to make sure it works. You can always adjust later, but it's easier to try and get right first time.

Layouts where the route goes through an area multiple times from different angles is something I love about Quake maps. It's not neccessary to do this, but it's fun to revisit areas sometimes. CZG tends to do this really well in his maps, so have a look at them (esp. honey!).

One thing I'm not sure I gave much though to before recently is the way you introduce the player to keys and key doors. Generally you want to block the player's path with a locked door, then send them on a trip to get the key, which may be located tantalisingly near to the door and in plain sight but unreachable. Don't give them the key before they get to the door (this could happen in a very non-linear map by accident I guess) because there is no point otherwise. Sorry if this point is crazy obvious :) 

Good Tips, already helped!

The CZG (especialy honey) maps where btw the reason i wanted to make a q1 map, their just gorgeous and interesting to play.
But realy realy hard to imagine how to build something like this, at least for me ^^ 

Than - good points.
I agree with Sock that I'd love to see more mappers doing blogs detailing work in progress, mapping styles, etcetera etcetera.
I'd love to see a video of Negke, among others, making a speedmap, for example. 

Is there any reason why Imps do not follow path_corners apart from the fact that they are little imps? 

Drew:
so people really want blogging on that stuff? i started with some doom mapping but figured no one really cared as it ended up not really being all that interesting to read. "i put in a room today... also, i textured stuff" etc...

Mike:
imps?
i'm going to guess you are talking about the flying imps from Hx2 that kinn ported over?
if so, then your question is actually related to flying monsters not following paths.

essentially, a monster won't move up or down unless it has the target as an enemy.
there's some code stuff but essentially, you can haxor it in yourself by doing this: http://celephais.net/board/view_thread.php?id=60097&start=601&end=601

ALSO what's not mentioned in that post is that the path_corners must have a movetype other than MOVETYPE_NONE (which is 0, so any entity that DOESN'T set a movetype has MOVETYPE_NONE).

so in your path_corner spawn functions, add in a self.movetype = MOVETYPE_NOCLIP;. 

A bug in Qouth code where the monster will not use the path if positioned directly above the path_corner. Apprently this bug was inherited from elsewhere.

Could well be fixed in latest version, or just not be the problem - but worth bearing in mind. 

As I remember it was if the monster shared its starting position with its first path_corner.

As Necros mentions vertical position is irrelevant for Quake Ai, apart from fliers and swimmers wanting to stay above their chosen enemy. 

the bug to which you are referring to was introduced by me.

it was so 'wait' keys on path_corners would allow monsters to stand around for a few seconds before moving on, and the way i checked if the monster had 'arrived' was by measuring the flattened distance to the corner to see if it was less than 4 units.
unfortunately, as you pointed out, it has the side effect of making monsters not register anything if they start on the corner. :( 

I typically like it.

haven't looked at this in depth but it might be cool, for example: http://www.rockpapershotgun.com/tag/level-with-me/ 

i guess.
whatever. 

Learn something new every day. Think I saw this in Quoth2 content. 

Having monsters patrol a bit better is always good. 

Thanks again for your help necros.

It seems as though every time I want to 'tidy up' a map, there's some kind of jiggery-pokery to do. I think I'll leave it as it is and just make do. Otherwise this will go on forever and as Jimbo says, "...and forever is a very, VERY long time, Geoffrey". 

As title says.
My map is tightly sealed, no leak, no pts file, prt and vis files are generated.
Still i'm able to look through the whole level with r_showtris in Fitzquake.
The map layout is suited for vis to work, still it doesnt.
Any ideas on this? 

are you doing -level 4?
-quick is almost always useless

are you noclipped outside the map?
vis data is ignored when you are outside of the map. 

Radiants build menu caused the fail.
Before every compiling stage it did automaticaly bsp again, so when i lightet the map, it "forgot" that vis was already done.
Rewrote the build menu, now it works.

Thanks necros, i now use -level 4, works like a charm. 

i hope you don't mean you always use -level 4.
i was only saying that it was possible you might not see much with -fast, but -fast is sometimes all you need for testing.

in some ways, using -fast will show how much a vis blocking tunnel or wall will help.

if the area is disappearing with just -fast, you have a great vis blocker and your -level 4 vis time will probably be really fast.
if it's NOT disppearing, -level 4 will catch all (or most) of the stuff -fast misses, but at the expense of a lot of calculations. (this is where you hear about those 3 week long vis sessions) 

Previously i used just vis without any switches.
I often used fastvis for my q3 maps, but my current machine handles normal vis in a few seconds (for now at least), so i tend to use it until it takes too long for fast test's.

Btw, just took a look into ne_ruins.
Great map, i especialy liked all those cool stuff like breaking vases, the coins inside, the swinging silver key door (amazing!)
Is this all added through QuakeC?
I guess i should take a look into the coding section too then! 

oh ok. -level 1-3 vises are not logical though, i mean, it's not like 1 is faster than 2 is faster than 3. in fact, some tests indicated that level 1 is vastly slower than 4 as well as much less effective.

and yes, ruins stuff is all quakec. qc is very powerful :) 

do func_train entities have a maximum distance in units they can travel? in my map, the train disappears or goes invisible after travelling about 3,520 units. i am still standing on it and it keeps moving, but i cannot see it. the train goes back and forth between a destination. on the way back, the train reappears and becomes visible again. i think this is happening when the train crosses the origin 0,0 of the map. my map is within the 4096 unit limit. 

All brush models start with their origin at the centre of the map, which can come as a surprise because usually the origin of an entity is close to its centre of mass. If the initial path corner was far enough to the left of the map, then as a train travelled left to right its origin could leave the map on the right just after the brushes went past the half way mark.

As a test of this hypothesis, try moving the entire brush model for the train to the origin of the map (the path corners should work identically, the only issue will be lighting on the train). Then recompile and see if this fixes it. 

thanks, moving the train to the origin fixes the visibility problem!

i had the train positioned at the south most part of the map heading to the north most part of the map so if the train's actual brush model origin was 0,0, then i guess the game believed the brush went outside the map after reaching it's halfway mark. 

Sounds cool.