half life 1 mapping hints and tips Created 19 years ago2005-09-13 14:52:57 UTC by killer1102

to help all make better maps i think if it would be a good idea if we make a list of hints and tips here(makeing good trains , makeing. I may also put some on my site.

When making terrain don't clip the squares till you make a turn! Now you can decide if you want to clip in the turns direction(creating a smooth angle) or aginst(creating a sharp angle)

there were a lot threads like that.

Tons

There's a load of topics that can be covered - this subject is just too broad.

Are you seeking technical tips, or gameplay/design ones?

Also, consider that there's a lot of tutorials on several sites already. You don't have to rewrite stuff that already exists.

Nice thought though,

1st. mayby this should be pinned then so it`s "visble" to mappers in mounths to come.
I want a serlection of hints and tips for the web page i`m makeing(give me time to make it. takes time to learn html)

while you're at it, learn jscript. you can do cool stuff easily with it.

you want tips for your web page, pm me and i'll send them to you

mapping tips to put on my web page as wel. I think i`ll master html before learning j script.

1. Do not fill rooms with crates

2. Do not ph33r the vertex tool

3. Spend as much time as possible on Architecture but don't go mad.

4. Place objects in convincing places (e.g. No Super Egon weapons in an office and random clips of ammo in a corridor.)

5. Make it possible to move through levels without getting stuck on signs sticking out of walls by 1 unit.

I can't think of any more now.

Don't use to many prefabs!

Plan out a level first, sketch it out on paper. This helps a lot of people pinpoint problem area's quickly so you're not wasting time mapping parts that never fit together.
With a layout in mind, throw in a basic architecture, just some plainly textured boxes that compose the very basic of your maps layout. Put in some lights and go playtest the map (lighting is not final, but you'll need lights as full-bright maps are really hard to get a good impression of). This gets you a feeling for what the map will flow like in the end. If some parts didn't feel right or problems happened (hard navigation, sloppy movement), fix them now. It'll save you time in the end.
Also playtest with weapons in place to decide on their placement. Ideally, you would want to think of weapon placement while sketching your map already.

With a layout and gameplay set, it's time to deal with the looks and ambience of it. I think we're all quite familiar with this, but if you aren't and you're stuck for idea's, search for reference pictures to see what would fit in such an environment. Early playtests should tell you where you still have enough polygons left to spare on detail, and what area's shouldn't be too detailed to avoid a bad performance.
Don't forget the ambience, some sounds and little twinkles and nice touches are noticed by players, either directly or at a lower level.

Oh, and during the layout stage, you can plan in visual assets and ambience as tricks. Shadowed area's for example are nice for ambushes. Rooms that have windows to corridors provide a tactical advantage if those windows are hard to spot from outsite. Sounds can give off warning signals to other players, allowing them to set up a trap or otherwise gain an advantage.

Most people benefit from a similar workflow. I thought I didn't had much use for sketching out a layout at first, but now that I've been mapping for some years I see the use of it.
Feel free to put this, or a similar article, up on your site. I could rehash it and write a more comprehendable article if you want when I get some spare time to polish it up (might make for a nice article for my portfolio, anyway). Good luck with it.

Need any help with html ?

The most important thing I could think of to add, is something that will save you lots of compile time, and something I've only just started doing myself.

While your developing your map, run CSG, RAD, and BSP, but not VIS untill the final stages, and then run with full VIS.

If you don't know what this stuff means, check out Atom's tutorial, here.

For example, here are compile times for a map I'm currently workning on:

csg...6 seconds
vis....16 minutes
rad...23 seconds
bsp...3 seconds

As you can see, If I run VIS everytime, I have to wait almost 18 minutes to check between compiles, which for a highly impatient person like myself, is simply unacceptable.

By skipping VIS, 'till the end, you will save oodles of time, and be able to more easily remember what you've changed between compiles.

That's bad design there, then, rowley... shouldn't take that long.

@Seventh: VIS is notorious for long compile times, regardless of optimization or not. Surface Tension for Source takes near a day and a half. It's open, yes, but there are no BSP splits to calculate save for what the engine does - Everything's a func_detail. I'd attribute this to the fact the area is large and outdoors, and granted it is different as it's Source, but you get the idea. VIS is just a bitch.

While your developing your map, run CSG, RAD, and BSP, but not VIS untill the final stages, and then run with full VIS.

Don't. VIS is important in earlier stages as well. You don't want to find out parts of your map are unplayable because you put in too much detail and stuff. Checking early on what area's can still run well with extra detail and what area's you need to be carefull with will save you much more time than not running VIS untill the end.
Better would be, when detailing area's, to use the Cordon Compile tool. It lets you compile only a part of the map. It might be wise to make a backup of your map now and then too. Should a map ever get corrupt, you won't loose too much work, and it allows you to see how the map evolved. Might be nice to learn a thing or two from.

Also, during compiles, that can often take long, do something else. Waiting in front of the screen is tempting, but taking a drink and cookie or drawing some idea's out is more usefull. It's also more relaxing...

an alternative could be fast vis

as i am doing certain things in combinations for the 1st time(like stuff the scientists do around the labs) i only do vis in final version and after i added new areas but not when i`m doing things so the scientist does stuff around the lab as i am oftern testing every few min there.
on my current single player map even fast vis takes some time.

when people are doing large tips (like captain p) it would be nice if they put the basic html code in ( <p>,</p> and <br>) but i`ll do the links and fonts and stuff.
(captain p don`t rewrite your tips as i am already adding the needed html)

i done the needed codeing for captain P`s post.
http://uk.geocities.com/wjnewbery@btinternet.com/halflife/hintntips.html

I usually don't run vis or rad when i'm just making basic architecture, and I almost never run vis until i'm done

...and then you find you done something in your map vis doen`t like and don`t know where to start looking...

hasn't happened yet! (but i'm sure it will, and then i will realize the error of my ways ) so running vis with the -fast option (zoner's tools) is probably a good idea in any case.

And if you have areas that the player cannot go into in the normal course of the game, put clip brushes there. (I read it in the tutorials)

VIS is just a bitch.

Yeah, but twenty-three minutes when everything is down below thirty seconds? Fifty times longer than RAD?

Xen isn`t logical.
it has some gravertiy. yet the platforms don`t all get pulled together but hover.

looking at the tips...
whats the mean?
Do not ph33r the vertex tool

people tend to dislike the vertex tool because you can totally screw over a brush by using it. But with it, you can make brushes that you cannot make any other way. So use vm, experiment with it, learn from it!

I'm actually having problems with VVIS taking too long, or rather getting stuck on the 6th step of the Portal Flow Process...

i use vm tons in the map i`m makeing. (makeing details, non staright corridors, corners, ramps and don`t have too many problems)
I surpose if you use it a lot you learn to avoid the problem befor it happens.

I surpose if you use it a lot you learn to avoid the problem befor it happens.

yes! I use it all of the time, because it is "safe" as compared to carving. ex: every time I carve with a cylinder, I get sub-unit leaks!

The vertex tool is just a tool. You don't need to master it to be a 'good' mapper. Use another editor than Hammer for my part, as long as the results are good.

But, when talking about tools, I find copying, clipping and flipping brushes quite usefull. Saves me the time to create new brushes each time. Vertex manipulation is also handy, also when working with multiple brushes. But, everyone has to find his own style at that, and if you can create great maps with hollowing and carving... do so. I wouldn't recommend it because it's easy to nail performance, but if you're skilled in that, go ahead. After all, that's really not what mapping is all about. It's the result that counts.

For details, it might be nice to learn modelling. No sub-unit problems, only somewhat difficult to insert as a prop in plain HL (you can use the cycler to avoid the standard collision box problem, though cyclers sometimes crash Hammer 3.5 if I'm not mistaken - might require some fgd changes).

Also, if you want to create unique or distinct maps, trying to create some textures is a good idea. Even if you're terrible at them, after some time you'll improve. It will get you at least some insight in what it takes to be a texture artist...

by details in that case i ment pipes and cables and stuff.(i even made a hanging cable in the my store room)
Captain p. have you looked at my 2 custom wads on the download page?

I've just taken a look at them now (bytheway, add links to your home page on the other sites of your site - right now navigation next to is impossible).

halflifeB.wad contains some colored textures, where I'd say those large versions could easily be made smaller ones as there's not much extra detail to them. Also, some of them (if not all) have odd dimensions. Stick to powers of 2 (16, 32, 64, 128, 256, 512). Those are easier to handle, otherwise you may get some strange artifacts.
The powerwarn texture looks bad. Leaving a white background often ends up pretty bad. I liked the tapA_top texture most, though it's not really round enough and well, could use some work. It's supposed to be a wheel button or such?

trains.wad looks better, you used a glue texture (or fill, as you call it) and those walls look ok. They still need work (it's a plaster wall but that bleu line doesn't isn't applied very well. It's the color blending between the line and the wall that makes it look bad). The trains end texture is way too undetailed, the train wheel as well. The signs could do with a more metallic look (adding noise isn't the right tool for every surface) and some edges (e.g. left and top sides are brighter, right and bottom sides darker to give it a relief look). The door textures look stretched. I'm also not too fond of that dark line around them and the miss a door handle.

All in all, you're getting started and that's good. But you've got things to improve on. Don't worry, you don't want to see my first textures...

the plaster wall is being remade.
it`s surposed to be metal for a train but doesn`t look right.
the train doors miss a door handle because as on many trains there will be a button to the left or right of the door.
what of my signal lights?
and the track_mono

i am more happy with the halflifeb.wad as the textures don`t look wrong when used in maps.

EDIT:the power warn was not surrposed to be in my wads at all.
2nd EDIT:bottom left.home page

Whoa, rowleybob! Thats very weird...
Vis, Csg, Bsp run for ~5 mins together! And rad usually takes like 10-30 mins.

That's bad design there, then, rowley... shouldn't take that long.

If by bad design you mean a large oudoor map, then you are correct. Unfortuantely, these are the only type of map I seem to have any interest in making.

My brushwork for this map is impeccable, in terms of always being on-vertex, no clipping, etc. In other words, clean, so I don't think there are any problems there.

Better would be, when detailing area's, to use the Cordon Compile tool.

Though I think your being just a little dramatic about skipping VIS during the early stages of the map, your advice is sound just the same.

I guess the bigger and more 'open' your map is , the more relevant skipping VIS is in terms of time-saving in the early stages, imo.

I always thought VIS/RAD didn't run when using Cordon, but I just found out how wrong I was!

Though I think your being just a little dramatic about skipping VIS during the early stages of the map

Depends on the way you're mapping. If you lay out the basic layout first, then it's good to check with full VIS and all to see what area's can take a lot of detail, and what area's are already rendered slower. Now you can easily change the layout to make your map better playable without having to throw away a month of detailing work.
That's why I'm so keen on performance testing right at the start.

Yeah I suppose my method is backwards compared to yours.

I add all the details, and then remove what I have to at the end. My real problem though, Is that I'm not so willing to change the layout. I guess I want to see what the map 'looks' like complete, before I chop it up for performance reasons.

After I become more experienced, and have a better idea about what can and can't be done, I'm sure I'll map more like you!

My real problem though, Is that I'm not so willing to change the layout.

Exactly what caused me to abandon so many promising maps. It is a pain to change a layout once all detail is already in place.

Perhaps it's good to create a small map first that sets the style and theme you're aiming for, and then start playing with layouts. Once you decided a layout, fill it up like you did with the testmap.

But well, maybe it's something to grow into. I've read several articles that recommended exactly what I do now, but at that time it didn't really work for me. I think I lacked the insight I have now. I don't know exactly, it's hard to point out.
Anyway, good luck with it...

Bahh...vis is problemtic with cliff maps. My compo entery took three and a half hours!

I did a search for 'Mapping tips' and came up with no less than 5 really good threads on this subject.

Maybe we should congeal them into one contiguous list/tutorial or something, perhaps in sections like:

General Beginner
...............
.......
..............
General Advanced
..........
..............
......
Style
............
............
............
Optimization
............
......
.................

The Beginner tutorials basically do this already, but I'm talking about just a big list of the best ones, for those of us with short attention spans...

I'd like to do an FAQ at some point when TWHL3 is around. I'll start a thread for suggestions later sometime.

Yeah FAQ will be great!

Exp:

Q: Why does my hammer freeze when I'm compiling?
A: It doesn't it's just working very hard.

That would be only good for source!

Q: Why does my hammer freeze when I'm compiling?
A: It doesn't it's just working very hard.

That's a really good one! I always thought my OS was crahsing!

no, hammer is supposed to freeze

You're kidding for sure!!

elon your avatar looks like shit : (weird)

Should I change it? : Or that seventh's transperty looks like shit?

It looks great... you're not using NS4 or IE or something, SpaG?