Large flat surfaces are cut up into chunks with a maximum size of 240x240 -- so if you have a wall that is 1200 units long, it will be divided into 6 chunks, even with the same texture on it. So you can divide it up and put alternate textures on different chunks and potentially have zero increase of polycount. 

The pair of windows in the back should each be casting a spotlight beam down the wall below, so the bright lit areas contrast with triangular shadows under the supports on that wall. The unrealistic lighting model in quake is a blessing in disguise because it's a bit like painting in soot and grime into your scene. 

also if it's quoth, using the model system would be beneficial. 

 

What you're asking, but maybe make the area more dynamic as well, in how the monsters arrive.

So having them roam along paths is a simple way of making a fight more memorable, as is having them spawn in some entertaining way - a lightning bolt and then teleport for example, or leaping through the windows into the courtyard below.

Those are pretty simplistic things that'll make the area more fun, you can probably come up with a load more. 

Ta for the suggestions guys. I'll have a fiddle and post another shot. 

.. and maybe selecting another brick texture for the walls... Maybe some like in DKT3 or Doom3, or simply make your own ;)
There are also some textures that have details variation you may use...

Anyway, it looks interesting, but indeed there's lack of details and design touch tht makes the shot sexy ;) 

ID1 works just fine. Stick with What Metl said - also, is it really that much more crazy than that seen in Tronyn maps? Those tend to look good and have high monster count and there haven't been *too* many complaints about r_speeds etc 

> Any suggestions/advice for making this not look crap but without a lot of detail? The area has a huge monster count so I want to avoid a lot of geometry detail :E

Vary the floor height. Steps, for example.

The polycount looks to be really low, so I wouldn't worry at all. 

Only 1 fullbright is part of the 12 duplicate colors. So the other 11 duplicates are a mystery. Id wouldn't waste 11 potential extra colors. There could be some undocumented code applied to them for additional effects. 

I'd like to have a reference file for the different monsters as they appear in quake 1 that has information such as their health numbers, their attacks and what kind of damage they can do, and such information.

It would also be useful to have that information for the player's weapons.

I know that this information can be had by browsing through the .qc source, but I didn't want to reinvent the wheel if there already is such a document. Is there one? 

some info about quake weapons:
http://shoresofnis.wordpress.com/2010/10/12/on-quake-weapons/ 

This is exactly what I was hoping to find, plus your conclusions from the stats. It's in my bookmarks, now. :) 

i do like that iD included a room clearing weapon without making it stupidly overpowered like Doom�s BFG.

My current playing around with slaughter maps I concluded that the main advantage of the BFG in a zerg situation is that the BFG is zero risk. The RL has a huge splash radius and is very painful. I considered giving out battlesuits like candy but it feels pretty bleh and is an invitation for the player to just rocket jump around like a lunatic which isn't what I had in mind. The BFG in Doom is like a shotgun, and at anything other than medium range the BFG is actually pretty shit, and the RL is much better. 

Oh I agree a lot on your idea of making the LG pass through enemies. It would make it the proper super weapon it should be, rather than just feeling like another nailgun with different ammo :p

<Begs for Quoth 3 lawl> 

anything other than medium range

um, anything *beyond* rather :E 

ruins has penetrating lightning. does full damage on up to 3 targets in a row. :)
also, when you get the SNG, the NG isn't selected during cycle up and cycle down and pressing 4 will select the SNG instead of the NG (pressing 4 twice gives you the NG).

and the fast zombies allows bullets and nails to penetrate as well, but nails 'start falling' after going through the first target so it ends up being maybe max of 5 or 6 zombies you can get with one nail if you aim upwards at the first zombie's head. 

also, when you get the SNG, the NG isn't selected during cycle up and cycle down and pressing 4 will select the SNG instead of the NG (pressing 4 twice gives you the NG).
And I got utterly confused and thought I had a bug.

Please do not do things like this. Some people (me) rely on weapon cycle to quickly select the weapon they want. If I know what weapons I have I can easily switch between them by using the wheel X times. 

I agree with Spirit on that one. Sometimes, believe it or not, I like to use the NG even if I do have the SNG, for weak targets or to conserve ammo. It's easier to waste ammo with the SNG by over-shooting a target. 

Just tap fire it? :E 

 

I'm not so sure myself, maybe it is OK to customise the way the weapons work in your own mod. 

that's unfortunate. :(
maybe better documentation was in order, but i like the new system too much to change it. :x

frankly, i find it far more annoying when someone makes a mod with the older progs sources (not 1.06) which don't have a cycle back impulse as i tend to use that solely for weapon selection. 

I am working on a map with some portions outside a spaceship... hence no gravity is required.
Having no gravity can be easily achieved using sv_gravity, but the player cannot move on Z-axis unfortunately... I though one moment fly mode will solve the issue but it didn't work either.

Actually I'd like to obtain equivalent behavior as noclip (in term of X-Y-Z acis move capabilities) but not passing through walls ? Is that possible ? 

i'm thinking you could do something similar to the fake water effect.

first to understand how the engine works:

quake first runs water physics on the player and only checks if the player is actually IN water afterwards.
AND
the variables that tell the engine that the player is in water can be changed via qc.

so, as long as you set the player's .waterlevel is set to 3, the engine thinks the player is swimming.

this allows you to move in all three axis. the problem is that, you also need to set the player's personal gravity (not sv_gravity) to 0 (or 0.001 since 0 defaults to 1) via the .gravity variable.
this will give you a perfect swimming physics effect. unfortunately, swimming physics has the sinking effect so you need to cancel that out somehow without stopping the player from manually swimming downwards.

note however that all this code must be done before physics are run by the engine. this means it either has to go in a touch function or in the playerPreThink function (NOT playerPostThink).

also, water physics has a lot of 'drag' on the player that causes them to stop moving quickly. so that would have to be worked around as well.