It may be for the best, because the player movement and mobility is different in Quake than it is in UT99, so a little tweaking will be needed regardless. Though even with just the rough greyboxes the map works well for sure. I drafted my brother into testing it with me and we had a blast with the gameplay.

Still deciding what theme I want to use. The easy answer would be metal, since the original Stalwart is a garage, but I have a few ideas for making it medieval themed. Trying to be creative in replacing setpieces from the original with Quake-esque replacements, instead of just trying to recreate them. 

rethinking... redoing.
I have a section I've redone 4 times now. Throwing stuff away does waste time, but often you get something even better out of it. And if not, you can just reload a backup. 

What I use when making a level... I find with singleplayer levels I just spend a disproportionate amount of time planning before actually touching an editor. Recently I also do perspective sketches of entire areas. And I try to come up with unique little setpieces.

The overall gameplay of a level usually comes pretty fast, since I like to keep that simple - there might be a destroy objective or a collect keys objective, but also lots of exploring where I don't really plan much. So my high level gameplay is usually very simple, and then I try to allow for emergent gameplay while exploring. Periodically spawning monsters that patrol etc.

Then again, parts of levels also come together while just putting blocks together in Radiant. It's really a mixture of several approaches, and then I just reiterate.

I tend to use a greyboxing approach these days, too, and start with simple blocks and placeholders. So for the multiple floors problem, yeah I would use placeholders in various places or just build it from memory (and accept the little differences that come with that). 

I used to make a lot of drawing plans for maps, but these days I flesh out a few rooms, make a bunch of geometry pieces for templates and I spend a lot of time having "inspiration sleeps"... that is I intentionally have naps and dream about mapping. It's weird but sometimes I will nap for 5-10 minutes and spend a couple of hours mapping then if I run into a wall I have another nap. 

I do my best programming after I wake up. Lots of good ideas for functions and design in those waking moments!

Speaking of that I've been meaning to give QuakeC a go. Never was very good at C, better with more modern nonsense like Java, C#, and Ruby, but it's QuakeC. Gotta be good. 

It's basically java without OO. 

"Speaking of that I've been meaning to give QuakeC a go. Never was very good at C, better with more modern nonsense like Java, C#, and Ruby, but it's QuakeC. Gotta be good."

Prepare for pain. :) 

'Quirky'

This should get you started:

http://www.inside3d.com/qcspecs/qc-menu.htm

And the main site has plenty to chew over as well:

http://www.inside3d.com/ 

I've always held that Coffee's Ai Cafe has a fantastic set of tutorials for QC.

https://www.quaddicted.com/webarchive/minion.planetquake.gamespy.com/tutorial/main.htm

Admittedly many of them centre around creating good AI for a deathmatch bot, but there's variety enough to get you exploring most of the code base. The practice with the AI is also helpful when it comes to working with the monster code in Quake, even if the tutorials rarely work directly with individual monster files (they all follow a similar pattern in the end). 

Haven't seen that before, even though I have heard of 'coffee move'. 

I've been using txqbsp for a while with no trouble, but was reading about tyr's qbsp so I figured I'd give it a show, and it is telling me I have a leak where there is none. I load up the point file, and it meanders around in the void then passes straight through a simple floor brush. I swapped back to txqbsp and it compiles with no leak, I turn on r_showtris and vis is working correctly, only what is visible is rendered, the vis is very good considering the size of the map.

What could be the trouble here? I have no entities in the void, no brush entities in the map at all, and the only texture I'm using is a greybox grid.

What gives? Tyr's light and vis are working great, qbsp is the only one acting a fool. 

I don't think tyrqbsp is based off of txqbsp, which is unfortunate as txqbsp is the best compiler out there in terms of robustness and its ability to cope with complex geometry. 

Tyranns qbsp.exe is for all intents and purposes currently broken. It wont compile anything for me so I just stick with txqbsp like I have for years. Tyrs vis and light are amazingly fast and work great though. 

Good to know. Thought it was my fault! 

Has a newer version in testing at the moment with a lot of fixes and improvements. 

are youre choice at last... 

would something like this chart and an explanation be helpful?
The rotation stuff seems under used and understood.

http://www.mediafire.com/view/57cfzc2e615m5z9/testchart.jpg 

I'm getting charty with it!

I'm starting to do some data analysis tests for Quake gameplay. I've done a first run through of one of my old favorite maps (hip2m2 if your curious) to get an idea of some basic ideas.

https://www.dropbox.com/s/c6kcbe24129idf1/BlackCathedralStats.jpg

I'm attempting to create generalizations about the basic gameplay elements over time. This is only the results from one study, but I had to pause to write the data down every interval. Also, copying the output from the console is tedious if I were to try to improve the collection method by outputting the data every 30 or 60 secs to the conole. Is there an engine that supports exporting data in this manner? Maybe in the save file?

I can make some generalizations though (still this depends on play style and it would be nice to have others input their data for this study). Kills over time is almost perfectly linear at about 12 kills per minute or 5 seconds per kill. Shells and nails maintain the same average (44 for this particular map), but nails varies much more wildly than shells (okay so I use them more but who wouldn't). Rockets maintained a very low average hovering around 10-15.

The linear kills over time is to me the most useful tidbit so far that I've learned and gives me a good idea of this maps pace, although being able to see the balance of everything over time like this makes me giddy. :D I love charts!!

Is there a better way to automate this? 

You could record yourself playing/take demos, and gather the data later. Never peeked inside a demo file before, possible it's in there and could be plucked out. 

I've created a map and everything is sealed, but for some reason when I play the map it's bright though the worldspawn brightness is set to default, which should be at 0. Can anyone help and tell me what's causing this? 

otherwise it would completely fullbright

and don't forget to run light.exe 

Use QW and then cokeman's mvdparser. You can specify what information you want in the output with templates. Should be possible to get pickups etc. from it.

https://github.com/JoakimSoderberg/mvdparser

I used it for https://www.quaddicted.com/tools/frag_heat_maps_from_mvd_demos

There are also tools for protocol 15 demos but I haven't found a user-friendly one. Will probably be investigating them later this month. The SDA guys should have stuff. Maybe http://speeddemosarchive.com/quake/qdq/tools/demtool.html 

Are you using the newest tyr tools for light and vis?

It's possible VIS broke somehow. In Quake turn "r_showtris 1" in console and just make sure that the whole level isn't being rendered at one time, which may indicate something doing wrong at compile time.

This is assuming you're running light.exe and have some lights thrown about in the map, which is what to check first. 

Ok thanks. Yea something broke and I got the idea to try different compile tools and that fixed it. 

It's like spy said. Light.exe adds the lightmap information to the compiled bsp provided there are light entities in the map.