Check out my Q1 ToolTips, section Portal Problems. 

What if you could compile multiple .maps of increasing complexity into one .bsp?

Say you have a large map with much detail.
Separate the largest chunks (major walls and boundaries) of the map into a separate map file. Compile a bsp from this map first. This would provide a rough and easy to handle bsp tree for vis to get a good foundation on. Then compile 'into' it the rest of the map, splitting up the nice and chunky nodes of the tree further into the final tree.

Entities could either be kept only from the last map or they could be merged. Light- and vis-data would be discarded.

The effect of this would be quite similar to that which you get from using hint brushes in Q2/Q3 maps. The mapper gets to control where in the map major bsp splits occur, and if he's clever he can reduce vis time (guess by quite a lot) by making sure the larger parts of the map can't see eachother in the 'chunky' map file.

This could be taken further by the mapper separating the map into more .maps with increasing detail, so you could have the equivalent of Q2 detail brushes, that only split up the actual node the brush is in, and not any further.

There could perhaps be some difficulty for mappers in working with this in the editor, since it would be impossible to maintain several different, overlapping map files at once*, and also a hassle to separate out all the brushes at various detail levels for each compile. Perhaps this could only be a usable option for the final compile before release.

Thoughts, please?
Also, implementation... �_�


* Doesn't GTKR support instancing of .map files into the current map via some sort of mapmodel entity? 

I've been thinking about layout issues and what constitutes a good layout that provides fun gameplay.

http://www.phait-accompli.com/q/s4/devlog.txt

I feel like I'm in a rut when it comes to that, and I need some inspiration... so if anyone has some insight I'd love to hear it. 

you are familar with Boroque technique, right? Inverting a theme, playing it backwards, concetating the beginning and end of the riff, shortening and expanding the meter that it is played, and that sort of thing?

Very artificial approach to creativity, but in the hands of a master it can work beautifully. The same approach can be applied to level design.

When I created BloodGates for the Norway pack, I was in a bit of a rut too, so I looked to some of my favorite levels for inspiration. One of the levels that impressed me the most from the original Id pack was the secret level of episode 3 the Haunted Halls because, despite being short of monsters, the action is quick, the set ups are thorough, and the level is complete in and of its self.

I played it several times and redrew the level on graph paper, and then I remapped it a few times more with a number of variations in the design each time. When I had a design I liked, I created Blood Gates with it.

Process sounds a bit mechanical, but if
you have played the map, does anything about BloodGates remind you of Haunted Halls? 

I'll look for it though. I can't say I'm familiar with the Boroque technique, as I don't really consider myself a musician (nor am I educated as one). So, I don't understand your point too well. :( 

There could perhaps be some difficulty for mappers in working with this in the editor, since it would be impossible to maintain several different, overlapping map files at once*, and also a hassle to separate out all the brushes at various detail levels for each compile. Perhaps this could only be a usable option for the final compile before release.

if you use Hammer (or WC even, I think), this should be a non-issue, as you just keep the various LODs in their own Visgroups, and hide which ones you want at compile time. 

That was why I was thinking about it since I use WC myself. I was just expressing pity-support for the rest of the rabble. 

Lunaran has some articles on his site about organizing levels but I think they are oriented towards death match.

This is one way to approach map organization, and this occurs with a lot of Half Life maps in the original game, is build a central confrontation or obstruction in your map and develop the rest of the level as a hub around it. 

This is one way to approach map organization, and this occurs with a lot of Half Life maps in the original game, is build a central confrontation or obstruction in your map and develop the rest of the level as a hub around it.

This works, definitely but I think level-after-level it would seem obvious or gimmicky. Generally I try to make each room memorable, and put in interesting designs (I mean I've spent how many hours on the tower-hub area, I should be beyond that now). But I'm finding my layouts just lack good scale, and it's not easy to just says "well I'll build bigger!" -- it needs to be thought out well. Everytime I play someone's SP map I think about the little things that contribute to the layout and just how things come together to where - it's not really room/corridor/room to the eye - but essentially parts of it may be just that, but disguised in a nicely flowing layout. 

But I'm finding my layouts just lack good scale, and it's not easy to just says "well I'll build bigger!" -- it needs to be thought out well.

I'm sure you know this already, but I find that good scale is a very elusive concept, and it's never just about building bigger. Most times you can achieve a good scale by expanding the space in just one or two dimensions, not in all three. Or exaggerating one of them. 

to be a little more careful with the z scale (top down for Id game maps) than the x and y because it is easy to screw up your step placement, like in all of my speed maps, even the one I actually like. 

<quote>step placement</quote>
As in "stairs"?

(cause that kinda goes without saying. I was talking more about the space itself, not the features in the space. although of course, they too can be exaggerated in one or more dimensions, should the need arise.) 

fuck 

Isn't that forward/backward or "through"? In Worldcraft in the viewpoints, XY is it top, YZ is side, and XZ is front. Whatever really :P

My biggest priorities in layout is pretty much good connection and flow, with some backtracking and not-always-obvious (but not plain confusing) progression. I just can't seem to get past boring room-by-room/floor-by-floor layouts. 

about how hub design can become repetitive. If you have played Amagon, how that first episode (tech based) is organized can be beneficial to study.

The first level is devided into two sections, a hub centered around a spiral stair case that goes off in three directions at different levels for the first half, and the other is a terrain area with small buildings that eventually come back to the hub.

The second level is organized around two canals,

The third is a one level base area sorrounded by sprawling tunnels and caverns,

The last is almost entirely an over and under interior design seperated into three sections with excalating game play as you move through them.

You just need to examine packs like these and you'll be able to undestand their broader patters.

If you don't have Amagon, check out Mexx 10, Beyond Belief, and, of course, ftp://ftp.sunet.se/pub/games/PC/idgames2/partial_conversions/zerstoerer
which is the essense of smoothly developed variation. 

yeap, but I've made the mistake so often, I thought a little reminder couldn't hurt.

Using '' instead, usually works for me. 

I see what you mean. X/Y shows the top view, but the Z plane is what is extended into when you manipulate the height of the objects.

Using '' instead, usually works for me.

The '' should contain *<*i*>*. See if THAT works 

I just can't seem to get past boring room-by-room/floor-by-floor layouts.

I almost always start with exterior layout first and build the interior sections around the exterior design. Sprawling canals and canyons are
things that I like to see in both nature and level design (helps that I have a passion for hiking and live near some nice places for it).

Build what you you like to see in games and design the game play you would like to subject the player to around it.

Of course, that may be easier said than done. How good are your modeling skills? Your basic problem may not be that you are having a hard time getting out of a pattern corridor -- room -- corridor design, but you are having a hard time building the structures you have in mind

(continued) 

that is the case, then you should go back over some fundamental brush manipulation technique; here is my recommendation,

1. get some prefabs from this site: http://prefabs.gamedesign.net/

There are some nice heliocopter and tank designs that I really like here.

2. Get a bunch of the prefabs that you find most appealing, and
3. place one in your editor, seperate all of the brushes,
4. rebuild each one of the brushes from scratch.
5. put the brushes back together to reform the original design.
6. repeat, wash and rinse until you get the hang of it.

Honestly, there is no reason why you should not be able to create anything you have in mind
in your editor. 

I'm trying to convert all the McGee Alice tex into a .wad for q1 mapping purposes, but all of the .tex are in .ftk format and I cannot open them in any programs I have, including Texmex or Photoshop. I know Biff and Lun have somehow converted them into a workable format, so I'm wondering if there's a program that can open this extension or some other technique I need to do? Thx for any help. 

there are alot of awful prefabs on that site, headthump. its quite sad.
example: A lot of pipes in a room 

the quality varies greatly.

That's why I pointed to the tanks and copters, some are good, esp. the copter used in the Lazarus pack for Quake2 that came from the gamedesign site. 

The first level is devided into two sections, a hub centered around a spiral stair case that goes off in three directions at different levels for the first half

That sounds just like map 2 that I've been working on, actually - spiral staircase/hub. Except inside the column, is a plat the player will access later to another area of the map. 

regarding czg's post... there's an easier way to do it. There in fact are q1 compilers that support hint and detail:

http://quest-ed.sourceforge.net/dl/index.html
http://developer.chaoticbox.com/files/quake/equakeutils.sit

I suspect the tools as they are would not suit your purposes for various reasons (low limits on most variables, mac-only), but the code is there. 

Awesome idea with the compile stuff, dunno if its doable within the Q1 BSP framework, but it'd be sweet if you could do stuff like that.

As for editing and maintaining multiple maps... I don't see why you'd need to. If you were going to haxx0r the qbsp etc tools anyways, you could just use entities in your editor to control what was detail and what was part of the core bsp.

You could just invent a new brush entity or 2 (for example, func_detail or whatever floats your boat), tell QBSP to ignore those brushes during the first pass, and then compile them in the final stage... at least, I think that'd work.

That way, you can see every brush in the editor, and also clearly see what is base map geometry and what is detail. The brush ents (eg func_detail) could just be compiled as normal geometry on top of the core BSP, so by the time the other tools like light get a hold of the BSP, its all just standard geometry.