About lighting in Quake 1.
First of all, it’s a game and your players need to see where they’re going. If they can’t, they’re going to be annoyed. It is not a painting or a movie, it’s a game that has players and hence requires a base amount of functionality. Darkness is not functional.
You want to use light to guide the player. This means that your main route should be relatively well lit, especially important doorways etc. This is again because it is for a game where the player needs to be able to see – that’s a fundamental requirement.
Your back alleys and side areas that are optional to explore can be darker.
Now Quake doesn’t have a large bandwidth between darkest and brightest. It doesn’t have a lot of headroom so to speak. There is black, and there is fullbright. The two extremes are relatively close together compared to other games. You don’t really want black (at least wherever a player sets their foot), and you don’t usually want fullbright except right where a light source is. This limits your available bandwidth even more.
And about fullbright; this is unfortunately not “white”, but only “the colour of the texture”. And here is where Quake’s palette becomes a problem, because it is overall relatively dark. Quake uses the colour of the texture for the calculation of the light value, and the texture is going to be on the dark side. So your available bandwidth is going to be extra limited.
What you are left with is something between black and dark. In other words, Quake cannot do “bright”. Even fullbright, in Quake, is not bright. It is just the colour of the texture (white would be bright).
Replacement textures can’t even change this, as long as you use q1bsp, because the light tool only knows about the low-res textures.
Now when you take all this, a game that already gives you the choice between dark and really dark, and you don’t use the full bandwidth of that but make a conscious decision to stay on the darker side, then yes, your maps are going to be too dark.
Quake is not a game that does “dark, but not really dark” very well. That’s because of the limited fidelity or bandwidth of its lighting model. It doesn’t have enough shades of dark to be able to pull this off (unlike, say, Stalker: Shadow of Chernobyl, which has indoor environments that successfully appear dark and scary without really being very dark).
What you want is maximum contrast. You want to use a realistic falloff formula for your lights (real lights adhere to the inverse square rule, this translates to delay 2 with Bengt Jardrup’s light tool) so you get some semblance of brightness at least near the light’s origin. You probably also want to make your main lights reach further than they originally do (by using something like wait 0.5) so you stand a tiny chance of getting the damn thing lit in the first place instead of being lost in blackness (be aware that delay 2 already does increase the falloff distance, which might be sufficient especially in the case of white lights – coloured lights are often better served by using the default falloff formula in combination with wait 0.5). This goes especially for maps that use larger scale geometry than original Quake (pretty much all modern maps). You need the additional reach for your main lights – the ones that do most of the work. Secondary or “fill” lights can be more dim with a smaller radius.
So you realistically want the main lights (the ones along your main route or street) to be as bright as possible (because this is Quake 1, and “bright” isn’t very bright to begin with). And remember that “bright” where lights are concerned means a light value of 255 (the maximum before clipping, which is another sad story), a proper falloff formula where it is brightest next to the light source (inverse square aka delay 2), and especially a large falloff distance (wait value around or smaller than 0.5).You can then let the outlying areas fade into blackness or just use some fill lights there, to create the impression that it is dark. The skybox will also have a huge effect: a night sky will make it appear as if it was night, despite relatively bright streetlights or torches or what-have-you.
If after doing this, certain lights seem too bright to you, reduce the falloff distance, NOT the light value (or you will go back to “your map is too dark” country). The light value does interoperate with the falloff distance, but it is also used for the color calculation so you’d best want to tweak the falloff independently.
Finally, remember that if necessary, deviate from any rules of thumb and hack things to the desired effect – place smaller, unsourced lights to get certain places lit better and so on. This technique where you just place a huge amount of unsourced fill lights wherever you want light is used everywhere in the original maps, often to the point of drowning the effect of actual light sources and thus reducing torches etc. to mere decorational purpose. Hacks will sometimes be the way to give you what you want, but it is still good to have some guidelines. Functional lighting, main lights and fill lights, and using the available contrast to its full effect, is what you want.
Remember that coloured lights are darker than white lights (white = bright, black = dark) so wherever you use coloured main lights, I recommend also using a white light with inverse square falloff to keep the impression of brightness (and increase the falloff distance of the coloured light to reinforce the impression of colour). Fill lights can be pure colour. Another thing when it comes to coloured lights is knowing the colour wheel, and knowing something about complementary colours, and colour psychology (warm vs cold colours). The Valve wiki has some good information on this, as well as on general lighting considerations (advice for Source mapping is still somewhat transferable to Quake).
Also, fog makes a map look darker, because everything will fade to the fog’s colour after some distance. Most people overuse fog, which has the side effect of messing with your map’s lighting. The fact that you can’t have volumetric fog (fog volumes) in Quake 1 doesn’t help – fog is either on or off, in the entire area, which is a large problem. You can try and use certain triggers to get better control over the fog density per-area instead of global fog, but the fundamental problem remains. The same goes for rain etc. because the rain’s colour will mess with the perception of everything else.
Fog in Quake, due to its fullscreen nature, is really more of a poor man’s depth of field effect, making everything at the fringe look sketchy and blurred.
I wrote this originally as a forum post, but it got too long. It might need correction and fine tuning in places.
Edit; here is something about using sunlight and outdoor lighting.
Use sunlight. Unless it is nighttime. Well, even then you can have moonlight – it is never 100% dark at night.
Different light tools have different implementations of this.
In Bengt Jardrup’s (aka AguirRe’s) light tool and its descendants, you put certain keys into worldspawn, the most important one being _sunlight (this is pasted from one of my maps):
“_sun_mangle” “130 -60”
“_sunlight_color” “1 0.8 1”
I believe you can only have the colour value in newer versions (MH’s? BSP2 version? not sure). _sky loads a skybox; make sure sun_mangle is set in accordance with the actual sun in the skybox. You don’t want the sun in the east with the sunlight coming from the west…
In hmap2, place a point light to serve as the sun (or several), target it at an info_null (like a spotlight) and then set delay 4 to tell the light tool to treat it as sunlight. Using several suns at slightly different angles will give you softer shadows.
Edit; the bit about functional lighting still applies, even in an outdoor setting. Light should still guide the player. See here:
Not always easy to do. If you can’t use light to mark important spots, then you’ll have to make do with ambient sounds, silhouette, or the good old minimap.