Map Advice?

[Motik7]

Just for some quick context, this is my first map I've made, I know it's not pretty I'm trying to focus on principles of design.

I'm mostly just looking for advice on how to continue development for my map.

It's as completed as me playing alone on the map running around looking for stuff can possibly find (except for a prop of mine being pitch black for some reason I can't figure out). I don't have any experience with setting up bots to test certain angles but just from running around as different classes I feel like I got a good thing going. That being said, I'm not so arrogant to think I nailed this first try.

Point being, any advice or criticisms of the map with what might be good to include/remove, etc. or regarding what to do next with it would be appreciated. I also don't know what the appropriate type of file to give is but since hammer opens this vmf file I guess it's the right one?

 

[Tiftid]

Hello,

Some advice I give here will be paraphrasing my KOTH guide:

Your map is rather short (one of the spawn doors is visible from the point area!)
I estimate it would take around 9 seconds for an Engineer, after spawning, to walk to the control point.
Typically in KOTH maps you aim for this value to be around 12 seconds - almost every map in the game takes this long.
Since an Engineer walks 300 hammer units per second, to add 3 extra seconds of length to your map you would need to add 900 units - or, alternatively, a nice round 1024.

The reason why a short KOTH map can cause problems is that, as the team who doesn't own the point, you can kill the entire enemy team, but have them respawn and come back before you've even finished capturing the point.
This makes the point more difficult to recapture, which is never something we want in KOTH - in my experience on hundreds of maps, the most unfun KOTH rounds are the ones where the first team to take the point holds it for three minutes.

In a similar vein, your point takes quite a while to capture, with a captime value of 12. The typical value for KOTH maps is 6.
A point that takes longer to capture will again make it possible to kill the entire enemy team, but have them come back before you've finished capturing.

The layout leading up to the cap point area is reasonably competent - a little derivative of Viaduct, but that's no great sin.
One thing I would like to point out is this building:

It falls victim to the classic "doorway problem", where if you want to go from the left route to the right one, or just go from the right route to the health pack, you have to pass this brutal sniper line.
Something I often like to do is put a little indent in the floor to fix this:

With this in place, a player can now choose whether they want to move through this room under the sniper line and safe from being headshot, or whether they want to go up to the high ground and challenge the enemy snipers.

It's also not good practice to put spawn doors directly in long sniper lines.

Because I think the layout leading into the point area is relatively competent, I think the best way to lengthen the map would be to add a little bit of extra distance here:

This would also let you reorient the spawn doors, and separate them into different areas of the map more so they're harder to spawncamp.

This health is a little too close to the point:

Typically you want to bias most of the health in the map into the "lobbies" the teams use to attack the point.
This means that the team who doesn't own the point will have quick access to health, but the team who does own the point will need to retreat all the way to their lobby area to get health, essentially giving the enemy team the point area for free.
Another mechanic that encourages rounds to be more intense and back-and-forth by making it easier for the team who doesn't own the point to capture it.

Your map is skyboxed by putting it all inside a massive box:

This is a massive no-no for various reasons:

• All faces outside your map will be rendered if not given the nodraw texture, which will reduce framerate and increase your map's filesize (because these faces have to store lighting information)
• Your map will generate a lot more "visleaves" than it should - having more visleaves makes your compile time longer, and visleaves outside the map are pointless because there isn't even anything out there to render

I typically skybox all of my maps by placing a skybox brush on top of every outer wall, and then extending it up to a given height, where I'll put one massive "top" skybox brush. Here's my newest map, ctf_bruhboulecross as an example:

This is easy to do, and perfectly ensures that all faces outside the map and on top of high-up walls are not rendered.
I also do this on walls that are partitioning different areas of my map, since this will help one area not be rendered from another.
In your map, the equivalent of this would be turning these two clipbrushes into skybox brushes:

Finally, there's a hole in your spawnroom's roof that will let players see and shoot into it:

Hope this helps!

 

[Motik7]

One thing I would like to point out is this building:

It falls victim to the classic "doorway problem", where if you want to go from the left route to the right one, or just go from the right route to the health pack, you have to pass this brutal sniper line.
Something I often like to do is put a little indent in the floor to fix this:

With this in place, a player can now choose whether they want to move through this room under the sniper line and safe from being headshot, or whether they want to go up to the high ground and challenge the enemy snipers.

It's also not good practice to put spawn doors directly in long sniper lines.

Would adding a door like the Dustbowl gate solve both of these problems, thus allowing the (in this case) red team to decide whether to engage the sniper and covering direct access to the spawn? I still want to extend back the spawn per your advice which will double solve the issue but I'm wondering if a gate would make it more difficult for the opposing team to push into the major spawn area, forcing them to go through the tall red building or use mobility to push right in the Viaduct-esque hill rise?

 

[Tiftid]

It would definitely help, but you need to be careful with one-way doors like that, since they mean nothing while they're open - they can still be moved and shot through by the enemy team.
This is the main reason why Gravelpit uses a dropdown instead, because even if an enemy soldier does get up there, it's usually not enough to hold back a flood of attackers.
You can, of course, combine a one-way door and dropdown so not even soldiers can get through unless someone holds the door open for them.

But, ultimately, people tend to not favour these one-way routes in KOTH, since once the attackers choose to go through them, it becomes impossible to retreat to cover and health.

 

[Motik7]

Apologies in advance for my poor drawings lol.

One more thing about the indent, I'm not a fan that it blocks (in the sense that you either have to go around it) off the doorway coming directly from spawn to the point. It helps deal with the two side doors but to the detriment of the middle door(s). (i.e. the red arrow is impossible I mean maybe you can jump but idk). In this case blue arrows are what you have to do which is fine, while the red arrow is something I want but that the design doesn't allow. Putting a prop to block the sightline inside the building still forces this walk around mechanic.

Instead, I'm thinking of extending the outside props. Doing so creates the following.

I wanted to make it such that the orange circle is highly open space that forces some risk from the people in the tall building who could push along the path akin to the blue arrow to the point but would have trouble getting behind the central prop cover (the leftmost gate door thing isn't originally there and makes going there through the red arrow too easy) because they'd have to push a pretty open gap. Adding more props to conceal the spawn from afar solves the initial sniper spawn problem, but it maintains the doorway problem from the green circle. Then again, it'd be pretty easy for the blue team to flank the green circle position from the sides such that it isn't that big a problem.

Basically, I don't like any solution I can think of lol. Any advice? Is the red arrow not as big a deal as I think it is?

 

[Tiftid]

Put a small bridge over it.

Hope this helps!

 

[Motik7]

Lol all my struggling just to put a bridge. Thanks.

 

[Motik7]

Also how do you get the like rendering in your hammer editor? You're somehow getting both the light and the clip box so you can't be in game and you can't be in hammer?

 

[Tiftid]

That's lighting preview, a feature of Hammer++:

Hammer++ : Home

ficool2.github.io

There really should be a button on the homepage to download Hammer++.

 

[Motik7]

I'll keep it in mind. I just tried it and I'm not getting the lighting and I'm getting a bunch of white squares on inverted alpha textures. Setting detail render distance to 0 seems to fix it but I'm not sure that's the right fix. Point being, any guides or something on effectively setting up hammer++?

 

[Tiftid]

In theory, all you need to do to install it should be to drag the exe and folder it gives you into this "bin" folder, and then run the exe.

 

[Motik7]

Yeah that's what I did like I have it up and running, it's more like using its features that aren't native to hammer. For instance I'm not getting that lighting render thing you had going.

Also whenever my render detail distance is anything above 0 I get these unknown textures only on the inverted alpha areas and the lighting still doesn't work. I assume porting a map between hammer to hammer++ has some jank associated with it so it'd be better if I start a fresh map but any knowledge of the lighting thing?

 

[Tiftid]

To use the lighting preview, you have to click on the little black box that says "camera" and choose this option:

You then need to click "Full Bake" or press L to actually get lighting.

The missing textures are grass sprites that the game automatically spawns on certain displacement textures. This is a known issue with Hammer++ where they will fail to render for one of a few reasons.
I like to just keep them off. This button is a quick shortcut to do that:

Alternatively, you can try reloading your map or restarting Hammer++ which can make them render properly, but that tends to be too much hassle for me.

 

[Motik7]

Your map is skyboxed by putting it all inside a massive box:

This is a massive no-no for various reasons:

• All faces outside your map will be rendered if not given the nodraw texture, which will reduce framerate and increase your map's filesize (because these faces have to store lighting information)
• Your map will generate a lot more "visleaves" than it should - having more visleaves makes your compile time longer, and visleaves outside the map are pointless because there isn't even anything out there to render

I typically skybox all of my maps by placing a skybox brush on top of every outer wall, and then extending it up to a given height, where I'll put one massive "top" skybox brush.

Okay so I've done this for the top and the sides, but I'm having issues applying this to the bottom. Because I have some elevation changes I'm not sure how to skybox the bottom of the map in a quick and easy way. I could manually place a skybox on the underside of all my pieces but with the elevation changes this is kind of difficult.

Because of this, I'm getting leaks. Is the only alternative to manually place skybox underneath everything. I was thinking of running a skybox on the outermost sides of my map (while also putting them on the outerwalls) and then extending those down into a lower skybox. This seems like it would work but then I'd be rendering all the bottom faces which was the issue we wanted to avoid.

Point being, is the only way to manually place skyboxes underneath my map accounting for elevation?

 

[Tiftid]

For starters, under displacements you typically wanna use nodraw instead of skybox.
I typically like to keep the nodraw sheet very close to the surface of the displacement - it may help you to know that the nodraw texture can z-fight with the displacement, and the displacement will always win in-game:

This lets me consider the nodraw as a "floor" that the map's brushes rest on, rather than extending the brushes down to a much deeper skybox.
Unfortunately, this is only really helpful if your map's buildings already had a standardised floor height to rest on.

If it helps you any, this is what this area looks like with displacements off:

You kind of just have to imagine that you're building the map with these brushes.
The most important thing to keep in mind is that the nodraw brushes have to touch the bottom face of the brushes that are actually visible to the player, because then the bottom faces of the main map brushes are culled and you don't have to worry about overdraw.

So yeah, basically, you do sort of have to do it all manually.