News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Well That Just Proves What I Know 
precisely dick!

Just stick with QS for your map... 
 
It's a DM map, no one uses QS there :) They use stuff like glpro, qrack, and ezquake.

I have a hard time getting my .lit file to stick already. Seems half of them have no coloured lighting. 
Layout Tools? 
Are there any good tools to be aware of outside of the usual workflow? Aside from the editor and texture utilities, what else do you leverage while you're making a map?

In particular I'm trying to think of a good way to plan maps. I was using graphing paper, but has anyone used something like google sketchup/layout, or another program? A simple way to layout a design from multiple angles would be awesome.

I was just using paper, but it's hard to keep track of the map from multiple angles, and to keep track of what line is what. 
 
Thing with planning maps... paper is fastest but lacks 3D. And if you do it in 3D you might as well do it inside the editor?

I like planning on paper, if you practice sketching straight in linear or orthogonal perspective and just do lots of little sketches it's pretty okay, you just have take peace with the fact you can't draw from all angles. 
Workflow 
dividing your time between layout and looks (dev texture etc) can be a huge save of effort. 
Prototyping 
Trenchbroom makes it very easy to bang out huge swaths of geometry with little pain, but I find that the thing I have trouble with is keeping layers matched between floor levels. Such as the first greybox rough revision I made for my remake of DM-Stalwart, there are four or so different floor heights, and they all connect via ramps and stairs, but a couple of my levels ended up uneven with each other, which didn't really matter in the rough layout, but for when I do the real-deal I need to make sure that should be square with each other are.

Is there a good technique to prevent snafus like this? Such as making floor platforms first, or placeholders? I seem to remember at one point in 2D view editors I'd setup all the floors first from the top perspective, then use a side perspective to move the layers to the heights I wanted, and work from there. 
 
there are four or so different floor heights, and they all connect via ramps and stairs

One of the strengths of Trenchbroom, I find.

Resolving height differences can be a bit of a pain, but the fact that there is height differences is a good thing for your map and is worth the trouble. 
Yeah 
Doing an accurate projection of a plan isn't as good as it might seem. As Necros says, the map will be better for the tweaks and playtesting you have to do.

When I draw a level plan I just scribble down the loops and points of interest in a flow chart style diagram of how it will play.

Orthogonal projection of architectural style plans is a pain in the arse and tends to break as soon as you put players (or even AI) in it.

A good rule of thumb; the less flat the better. Even when it means rethinking your ideas for the level.

I just hit a problem with this last night where the SP map layout I'm making isn't working with the monster I wanted to use in that section. So in order to maintain the uneven floor I'm rethinking the encounters there.

I could just fudge it, or chuck in a random horde, but solving the problem well is part of the fun. 
For The Best 
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 Dig 
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. :) 
Best Description Of Qc 
'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/ 
More Resources For Learning QC 
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). 
Cool 
Haven't seen that before, even though I have heard of 'coffee move'. 
Leaks, But No Leak 
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. 
Tyr`s Qbsp 
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! 
Tyrqbsp 
Has a newer version in testing at the moment with a lot of fixes and improvements. 
Rebb�s Jury Rigged BJP Tools 
are youre choice at last... 
Rotate Info 
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 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.