News | Forum | People | FAQ | Links | Search | Register | Log in
Source Mapper New To Quake Mapping
Hello! Recently I've gotten the itch to map again after a long hiatus partly due to the lack of Linux support for hammer, partly by my inability to finish what I start, and partly due to the realization that although I've been mapping for a while, I haven't really developed my level design skills. What skills I do have are generally technical, like understanding when to use func_detail and how to use hint brushes. Most of the time I've been dicking around with entities (culminating in this doohickey: However, I recently came across DaZ's map analysis videos (which are phenomenal!), and that has inspired me to start again. I want to got "back to basics," how should I start a map? Do I start with a high concept, then refine it down to parts? Or should I go with a bottom-up approach, designing set pieces to explore interactions between monsters and the environment? What kinds of problems are unique to Quake and its engine that I should be aware of? I've been lurking on this site for a few weeks, and many of you produce some real Grade-A stuff, so I'm really interested in what you have to say.
Just Go Map 
Don't overthink it.
Just build some shit, see if it leads you anywhere cool.
Don't try to make cool setpieces, events or clever scripts, Quake is not the best medium for that. 
Start Simple 
Lots of mappers (myself included) get bogged down with grandiose ideas.

Make something short and sweet.

Some people here pre-plan lots of stuff, others just go with the flow and design as they go. Use whatever works for you.

Some things to keep in mind:

In your editor use a grid and stick to it. Only deviate from it when absolutely necessary, and pretty much only for details.

The map format / compilers won't allow you to use concave brushes. In many (but not all) situations you can use the clipping tool and the triangulate tool (in vertex mode) to keep the same geometry and having it remain convex.

The format doesn't like having two brushes diverge from each other at a sliver of an angle. Keeping on grid should help with this.

Have fun! 
Lots of mappers (myself included) get bogged down with grandiose ideas.

Make something short and sweet.

This is a huge one, getting wrapped up in some grand plan can really damage your motivation to see a map to its completion.

Start with a small map and work on the fine details and use a variety of entities/brushes to get familiar with the game. 
I don't always do this, there has been an exception or two, but I like to make the start and exit first. Then I start filling in the parts between.

Often I will lay things out so that the exit is within sight of the start position. If not the exit, then at least the first key or goal can be seen from where the player starts.

But visible and quickly accessible are two different things. The actual path can be a long and winding one.

Other than that, I rarely have any actual plan on how things will get built or where the player will go during the journey. Ideas just come along the way. 
Keep It Small At First 
I strongly suggest limiting yoursef to making small snippets, even as simple as find the key, open the door, exit. Teleporting monsters in is wierd in Q1, put the monster in its own box somewhere with a trigger teleport. Give the teleport a name and a target. Target could be anything but usually it's an info_teleportdestination.

As a Hammer user you should of course download "J.A.C.K" 
Get The Main Idea 
and the main map flow and the let it expand an wind as it goes.

I watched a lot of Daz's stuff to familiarize myself with modern Quake gameplay and level design. 
Don't overthink it.
Just build some shit, see if it leads you anywhere cool.

That's probably a good idea considering I'm doing this just as a creative outlet. I had a programming project I was working on, but I have enough programming assignments this semester anyways, and I realized that I need to do something different.

Don't try to make cool setpieces, events or clever scripts, Quake is not the best medium for that.
Yeah, that's why I thought it would be a good idea to go with Quake, so I can focus on the core elements. However, I might eventually teach myself QuakeC, but that's for later.

Lots of mappers (myself included) get bogged down with grandiose ideas.

Make something short and sweet.

That's good advice. The maps in DaZ's videos look really impressive, and I've thought, "Ooh! I wanna make something like that!" but I'm sure that's biting off more than I can chew.

Start with a small map and work on the fine details and use a variety of entities/brushes to get familiar with the game. I actually want to avoid "fine details" and focus on layouts. I'm a perfectionist; if I think of something to change, I usually don't hesitate. This becomes a problem when I realize that the layout or pacing don't work right, and I need to make large changes, necessitating the removal of small details I spent a long time working on. I made some really nice looking caves with displacements in hammer, but I hit a dead end with that map. ACTUALLY scratch that, you might be on to something. I'm thinking maybe I should start with an arena, as I find them to be the parts of a level that are the most fun. Working with a single space would allow me to create a more cohesive environment, allow me to fine-tune enemy interactions, and allow me to iterate quickly without having to break the layout. Then I could extend that, even if it's just a short intro sequence to get the player settled in. Yay? Nay?

As a Hammer user you should of course download "J.A.C.K"
Maybe. I sorta passed over it because I've been moving more towards free software, but I realize how ridiculous I'm being considering the fact that I use proprietary software such as Steam and most of the games I have. Are you aware of any Linux compile tools for Source? Source SDK has tools under a "source available" license, but they would need to be ported. That, or one would have to research the Source BSP format and write new tools or adapt existing tools. Ofc, there's always Wine. 
Man, These Posts Are Much Longer Than I Had Expected 
Thanks for the advice! 
Er...I mean J.A.C.K is free and has a linux build on the download page it's basically Hammer but for Quake...for now anyway since it keeps getting new features.

Arenas are cool. Good idea. 
...and Never Watch Screenshots From MFX 
I mean J.A.C.K is free
There's a difference between "free software"* and "freeware," but that's not a discussion** I want to be having right now. Not trying to be rude, but it's a seemingly benign discussion that tends towards flame wars for some reason. Anyways, I've already highlighted my own hypocrisy. But I'm liking Trench Broom well enough already for Quake mapping. Or at least until I broke it trying to update it.

*Open source, basically, but it emphasizes freedom of owners of software
** See: GNU, Richard Stallman, Linux, FSF 
Oh, Hey 
Another thing: what tools do I have to work with in console? What ports provide the most useful features for debugging and perf optimization? Source has some commands to visualize BSP leaves, overdraw, clip brushes, network performance, entity interactions, etc. Is there anything like this for Quake? I really miss the "find" command for searching cvars/commands in Source. 
there are various cvars, one that all engines support is "r_speeds 1" (but the output varies.)

Another one in fitzquake/quakespasm is "devstats 1" 
Different Engines Have Different Cvar Features 
Darkplaces Engine has a lot of neat developer features for seeing lightmaps, leafs, tris, etc. Most engines though have stats like fps. 
Of Course 
Quakespasm 0.92 or Mark V amor Fitzquake are the best options for engines since they are more faithful to the original software engine. Don't know which has a linux build though. 
Actually I have DarkPlaces and Quakespasm installed right now. Good to know I have a reason to keep DarkPlaces around.

On a side note, I noticed that wall strafing works differently between DP an QS. In DP it's most effective when you're facing parallel to the surface you're strafing against, while in QS it's more effective when angled slightly away from the wall. Also, in both engines there's a fiend in E3M3 that has a fiend that teleports in and gets stuck in mid-air. Is this the behavior in vanilla quake? Is there some sort of "Chocolate Quake" that does for quake what Chocolate Doom does for Doom? 
I really miss the "find" command
Not sure about QS, but DP has a similar "apropos" command. Also, its readme includes an extensive list of cvars.
Note that there are 3 specific cvars that DP disables by default and that you need to re-enable:
sv_gameplayfix_droptofloorstartsolid 1
sv_gameplayfix_setmodelrealbox 1
sv_gameplayfix_upwardvelocityclearsongroundflag 1
I'm thinking maybe the first one will fix your frozen fiend issue: I've just replayed the map (on skill 2) and didn't get any stuck-in-mid-air fiend 
You'll Also 
Want to set jumpstep to 1...or maybe it was 0, always seemed backwards to me. Anyways it lets you step up 16units even while in mid-air so while you couldn't jump higher than 32units in any other engine, DP will let you go up 48. Plus it feels odd. 
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.