The mapping hints thread.

Now, because it's rather less fun to learn from your own mistakes than other's, do go on and share tidbits about empire mod or hammer in particular or just level design in general. Funny annectodes are welcomed.

I only made 1 map for source before(capture the flag map for fortress forever); but I've done several levels for goldsrc(HLDM, natural-selection and CS), duke3d and doom(oh these were absolute rubish, but I learned a lot).

I must have spent a good 24 hours manually aligning textures on world brushes(not in one sitting...) before I discovered that alt + right clicking a surface in the texture application tool will align the texture you click to the texture you have currently selected; which makes aligning textures at least a factor 10 faster(there are still a small number of annoying cases where you need to tinker manually to get things just right).

A perfectly symmetric map is balanced. Symmetric objects tend to be beautiful. Symmetry is easy to make. Symmetry is also bland and lacking in character. Too much symmetry makes for dull gameplay and a completely forgettable experience. Start from a rough position of symmetry, then break it, even if symmetry is just cosmetically broken with no huge gameplay difference.

 

psychology wise, I've always felt like I would never be able to finish any map whenever I thought it as a map as a whole, but soon I started just putting my mind to creating objects, which I would end up having aligned along many other objects. So instead of feeling like you are creating the whole map, feel like you are putting puzzle pieces onto a map.

To keep the map fresh you've got to put in messy detail, like hanging cables, broken walls, broken electrical components that make broken sounds, tall (and also thin) objects behind many small objects (such as electrical towers, watchtowers, telephone poles, and antennas) placed behind a series of small stores/houses, on top of high hills/mountains. also fog, it's a cheap way to optimize your map and it could add mood and theme. Also do things never done before, in every game I've played that comes with a map editor I have found many maps all look exactly the same. Yes I am talking about the canyon hills.

Before mapping walk around your neighbourhood or town and find things that catches the eye, and put it into your mental image of your map. If you live in an old town that has preserved some of it's architecture you might want to draw inspiration from that too. If you don't your map could end up like you are all boxed in, and also new ideas might not come in.

 

someone make it clear how to do resource point/prop ent-ing.

you know: so the sprites and model go away after the ref is placed etc

 

Map layout and design extremely important. Details can always be added, but if there is a glaring problem with the overall design of the map, making it pretty won't make those issues go away.

Designs need to be simple with enough variation to keep things fresh, but also keeping it simple enough to memorize the overall layout the first or second time playing the map. Complexity is your enemy in empires mapping. Everything should be visible and apparent from the minimap, and nothing should need an explanation.

That's not always true, but try and keep it as close to such as possible. Now on to some more empires specific parts:


Resource Point Setup:

Example: http://dl.dropbox.com/u/10061381/emp_artillerytest.vmf

There are 3 entities to your basic resource point in empires. First, there is the emp_resource_point. Second, the emp_resource_point_prop, and third, then env_smokestack.

First, place the resource_point entity slightly off the ground. within 16 units preferably. Not sure what the exact requirements are, but I think that on or too near the ground causes issues.

Second, give it a name.

Third, place the emp_resource_point_prop on top of this, give it a model to use, and then name it as well. Naming conventions I use are something like res_point_1 and res_point_1_prop. Set the prop to be enabled so it appears when the map loads.

next get an env_smokestack. Put this guy right over top of the res point entity as well. The smoke will originate from this entity. Name it as well, and set the to "On".

Now, when the resource_point entity is enabled, it can be built upon. When it is built upon, it is automatically disabled. This means we want to set up the logic according to this entity being enabled and disabled. Add on disable, turn off the steam and disable the prop. When it is enabled, turn on the steam and the prop.

For preplaced map refineries, there is also an example.


Might give more later.

 

Not-quite-valid brushes will often appear to be valid in the hammer editor, even if you use the "check for problems" tool.

When you save the map and reload it hammer will "fix" these invalid brushes. By fix I mean that hammer will make the brushes valid; unfortunately it will make them valid by subtly misaligning the vertices from the grid by a tiny fraction of 1 unit, giving the appearance of cracks.

This is a problem mainly with displacement surfaces, because they have to be made from quadrilaterals.

If you make some odd-angled brush and you are unsure whether it is valid, save the map and reload it.

 

That's because hammer stores the brushes by vertices, the vmf file stores them as planes (which is how the engine uses them). Annoying, but you can always use models instead.

 

If you're editing a metric shit-ton of brushes, hiding groups you don't want to edit and zooming in the views you aren't using really speeds up the rendering so you can get stuff done faster.

You wouldn't think rendering a few thousand lines would affect performance at all, but apparently it does, for some reason.

The displacement sew tool can sew toghether adjacent displacement maps even if they have a different subdivision power; the cracks are surprisingly not visible(floating point is not infinite precision, different sized triangles sharing an edge WILL have tiny cracks, but they don't appear to be perceptible). The sew tool also works when the adjecent displacement is half the size of the original as long as the smaller displacement has one of its vertices at the center point of the large displacement and the other in a corner.

 

If you don't compile and test your map frequently you will end up with a tonne of errors when you finally do compile. Don't be too discouraged. Just walk through your map and create a big list of all the errors you can find.

Some of these errors will be time consuming to fix, but many will be very easy.

Don't get trapped in the cycle of "I've learned so much and these problems ares so much work to fix, I'll just start over and get it right the next time". There's always going to be problems, you're always going to learn something; part of the problem is that when the map is feature complete you've still got 90% of the work ahead of you and much of it will be kind of tedious.

 

You can avoid a lot of problems by paying attention to what you're doing. Try using orange mapping to speed up basic design, it'll help avoid problems like leaks from happening all the time.

 

You can also compile with no vrad. This causes the map to be compiled in full bright, but you will only have to deal with the large problems first. Mostly map crashes and compile errors. Once you get these done, compile once with your vrad on fast to see basically what the lighting will look like, and then take it from there.

Errors are far easier to work with than some of the more technical stuff like lighting and optimization. Errors can be definitively fixed, as lighting is somewhat more opinionated.

 

I had this weird bug where a whole group of objects became misaligned by fraction of 1 unit. If you used ctrl+shift+B the vertices were exactly moved onto the grid; no offgrid vertices whatsoever, but as soon as you moved the group again it all became unaligned by a fraction of a unit. This persisted through saving and through ungrouping and grouping again and even happened for individual brushes with ignore group on.

The solution to this problem was ctrl+shift+b to align the brushes first. Then go into vertex editing mode with the whole group still selected. Move a single vertex and put it back again(any, it doesn't matter which).

 

Doesn't dropbox work as a version control system? If not, you can always pm me to get your personal SVN on raegquit. I actually use the domain mostly for the reason Brutos mentioned.

 

I make a new save file for every compile and every time I reopen a map in hammer and before I close it.

My mapping files for vmf's is around 5 gigs. ^_^

As well, in 2.31 I have about 100 maps compiled.

scuse me, 6 gigs


As far as map versions go, you should at least change the version for every compile you do. Whether you keep track of bugs and such you are fixing is up to you, but keeping a personal version history for bugs and fixes is very helpful, especially when you feel like you are getting nowhere. When you finally get a compile that works, just rename it as your a1 or b1 or rc1 depending on the version and be done with it.

Hell, I even do it for light testing.

 

My map was at 30 MB before it went on a diet(lowered the subdivision level on displacements where I could get away with fewer triangles; it was almost full); the current version is 20 MB. And I'm up to version 49. That's 1 map, and it's 740 MBs of .VMFs and counting.