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. 

Like i said in #tf, this all sounds very rube goldberg. For all that effort it would take to add these crazy hacks, it seems like it would be better to just support detail/hint in the compiler, and use existing detail/hint support in radiant.

Furthermore, if we're not satisfied with the q1 bsp format, it seems like a lot more would be gained by supporting q3bsp in more engines. Then we get the compiler and editor for free. 

Sure. What you said. : )

As far as I understand it though (and I don't understand more than a fraction of one percent of it all), it really isn't as simple as adding Q3 style detail support to the Q1 BSP format/tools. (That's just what I got from discussing the issue with programmers at work, who understand the tools/engine reasonably well).

However, as crazy/convoluted as it may be, czg's proposed method would possibly be feasible and would allow you to achieve at least something remotely like the desired result within the current engine/tools.

Of course, I could be wrong on both counts.

By the way... Q3 source code within a week? Does that include compile utilities, or do we already have that source? *shrug* maybe it would shed some light on the situation. 

Layouts and their scales are entirely over rated. In DM they are very important--no doubt about it. But there are so many SP maps that are linear room-corridor-room layouts that it's not worth fretting about. Obviously, certain themes will not work as well with linear layouts (space ships compared with an artificial tunnel). People really don't pay much attention to the overall layout as long as navigation is straight forward and the map looks nice, and so far you're not having any sort of serious problem with your aesthetics.

The scale of the rooms and their details and their relative scale to each other--now that's important. However, to some extent it depends on your own personal style, and the style of the game--Q3 is known for very wide hallways, and Q1SP can work with either wide or narrow spaces.

I still maintain that one of the most important parts of improvement is to just release stuff. 

I have a line of torches that are in view all at once (leading away from the player). Is there a way to un-sync them as they look a little 'unreal' at the moment? I suppose this will involve setting them to begin their existance at different times to ensure they display different frames visually?

I seem to remember reading something about this but now cannot find the reference. 

flames are already set to NOT sync in the mdl file. Not sure why you're seeing them all sync up, other than bad luck. 

Thanks, yes I can see the flag now and it is set to random. The torch is ID's original but it also happens to a candle.mdl I have nicked from somewhere(?) - it is not random even though the flag is set.

Mmmm, what now? 

That is some encouraging insight that helps me see it from a different perspective. Thanks.

I think for me it's inherently challenging to create a believable environment with Quake's textures. Quake wasn't quite suited towards the little details that help make an area realistic -- the best thing you can do is work with the texture sizes as they are and really let that influence how you build. I was running through Jago's Araivo thinking about that, how the textures fit so well over practically everything. It feels so solid.

But I find so many SP maps while they play nice and look great, alot of them are just brush-spooging - while they may be touted as a particular environment, they come off more as just... cool brush work on a large scale. Maybe that's just me. My point is, trying to create something more practical/real in Quake while possible - isn't necessarily the best way to map in Quake (with default tex sets), and trying to create interesting progression from there makes it that much harder.

On the other hand I just woke up so maybe what I said isn't very coherent. 

Thanks :)