[WIP] de_slate (withdrawn)

far too complex in terms of layout- theme is pretty cool but you have so many redundant paths and changes in height.... reminds me of this map from goldeneye:

Your map is very complicated and confusing. I recommend trying to simplify the layout or changing the name to de_Picasso.

Quote from MaanMan

Your map is very complicated and confusing. I recommend trying to simplify the layout or changing the name to de_Picasso. de_escher

FTFY

It looks nice in the screenshots, but perhaps in the overlay you can black out any untraversable routes to make it simpler to read. Regardless, I think the layout needs to be simplified:

Too many routes = too many flanking = too many salt

I like the concept but you need hints of color to guide the player, clean up the overview and make paths work to shorten rotation time.

Maybe removing a path or too could be better also. But I'm not sure of that however.

But I want to stress the fact that it interesting visually ! It has an halo feel I guess

Better but could proabably use some more near CT spawn and between mid and A

I can't help myself, sorry :D...

[Blocked Image: http://ai-s1.infcdn.net/screenshots_siandroid/3/3362/3362989_1_2.jpg]

You've got a lot of parallel running paths, so you could easily combine most of them.

You've also got a few paths which allow for players to double back on themselves, so you might want to redirect or close those to keep the flow right. If people know the bombsite is a certain direction, to follow a path away from it to come back to it is counter-intuitive to people playing the map for the first time. You have the advantage of knowing where everything is already so it can cloud your judgement.

Before you do cut it down, please share an overview screenshot with bot_show_battlefront 1 active. I'm quite intrigued.

The base layout of this map is awesome but IT could definitely use some tweaking. In its current state, there are a few paths that are either a. redundant or b. reduce the significance of other paths. I would suggest slimming the map around the edges especially by T spawn.

I very much believe in a design philosophy of having the entire map be viable in regular play, as apposed to having dead starts (maps like Nuke or even Inferno). That being said your map seems to embody this and I would play to that. Perhaps you could remove the outward paths by t spawn and re-angle the above ones to allow for players to rotate through T spawn, but not encourage they stay there too long.

I would argue that the layout isn't particularly complicated as it is, but rather clustered with a great deal of redundant player splitting areas. Running around in game is rather overwhelming as a result of this. Some areas have far to many corners to check and should be simplified. I'd love to see where this map ends up though, you're off to an amazing start.

Looks great for an SP mini-sandbox, but every route divides in two more, if you compare to the main CS maps you get an answer for yourself.

I think the problem here is that maybe you have many great ideas for visuals, and you're trying to have players see it all?

Hey, quick question that always comes up for me when I see layouts as organic as this one: how do you keep things on-grid in Hammer? Is it through usage of func_details or how do you manage to do that?

New layout looks like a step in the right direction. Still seems extremely mazey though, like a connector hell. If I imagine myself in literally any place on your map overview, I feel I could be killed from 3-4+ angles at all times pretty much. I'd try and reduce that further. Looks very unique and interesting though!

Quote from NihiL

Hey, quick question that always comes up for me when I see layouts as organic as this one: how do you keep things on-grid in Hammer? Is it through usage of func_details or how do you manage to do that?

New layout looks like a step in the right direction. Still seems extremely mazey though, like a connector hell. If I imagine myself in literally any place on your map overview, I feel I could be killed from 3-4+ angles at all times pretty much. I'd try and reduce that further. Looks very unique and interesting though!

I think he does not keep geometry on the grid, which is probably an obligation as soon as you create something not square-ish. At least that's what I understood when he said he was keeping it off the grid geometry (in his first post).

Quote from laminutederire

I think he does not keep geometry on the grid, which is probably an obligation as soon as you create something not square-ish. At least that's what I understood when he said he was keeping it off the grid geometry (in his first post).

I'm pretty sure he meant that his layout is non-square and more organic when he said that, but you need your stuff to sort of be on grid still in Hammer - otherwise how are you going to put in func_details and props? Hence my question how he does it!

Quote from NihiL

I'm pretty sure he meant that his layout is non-square and more organic when he said that, but you need your stuff to sort of be on grid still in Hammer - otherwise how are you going to put in func_details and props? Hence my question how he does it!

why couldn't he tie off the grid geometry to func_detail ? He just have to select brushes and here you go. I do this all the time, and there is absolutely no issues with that excepting for the compiling time which is a little bit higher, a matter of a few seconds.

For props he can explain you his technique for placing them correctly but it will probably involve placing them on the 1 unit grid then adjusting off the grid. I'll let him answer that one though.

Quote from laminutederire

why couldn't he tie off the grid geometry to func_detail ? He just have to select brushes and here you go. I do this all the time, and there is absolutely no issues with that excepting for the compiling time which is a little bit higher, a matter of a few seconds.

For props he can explain you his technique for placing them correctly but it will probably involve placing them on the 1 unit grid then adjusting off the grid. I'll let him answer that one though.

I wasn't talking about issues with tying off-grid brushes to func_details, I meant placing the brushes properly in the first place. Here's what I mean:

[Blocked Image: http://i.imgur.com/OBlvLB3.jpg]

Imagine the top brush in both cases is a world brush. The first is on-grid and so it's easy to add a little extrusion detail brush to it. But the second version is not on-grid and it becomes impossible to properly/cleanly place the same detail brush.

I was asking how the maker of de_slate achieves this. I mentioned func_instances because you can use them to create off-grid 'prefabs' on-grid and then rotate them off-grid in the final map.

Ah okay, you're going for the whole ratio thing. I'll be very interested to see if/how that works for you when it comes to detailing as I've had bad experiences even if you stick to 1:2, 1:3 ratios etc with detailing and prop placements. Good luck!