dont let them distract you! 

If the walls aren't the same thickness at every height. You can make these transitiones in two ways - with a 'step', i.e. the wall suddenly gets X units thicker, with a perpendicular step, or with a slope. This is true of much architecture because the foundations need to be strong enough to support all of the weight above it.

Either way, it's a nice way of adding a whole other dimension to your architecture.

You could add some damage detail to the architecture too, maybe a few cracked tiles, , bricks out of place or missing etc.

Overall I think the shots look pretty awesome, just thinking of elements that you could take more advantage of. 

It doesn't require gussying up. It has a nice stark balance and subtle detailing. In the shots I've seen, I'd consider that aspect of the map 'done'. 

You realise the map is already bursting at the seams with marksurfaces? 

What you've got is good. Finish it as you see fit.

Float walls refers to not using geometry (brushes) to make the light map do the work of making a space interesting. But with all the work you've put into the light it's not a mistake you've made. Don't go into pre-release worry.

We've only seen screenshots! 

 

 

.



dont let them distract you!

Not much chance of that. The reason is because I intend to stay within the normal Quake Engine map limits.

onetruepurple is correct, the map is bursting at the seams with marksurfaces

What this means is that the geometry of the map is pretty much finished, with no chance at all of any major changes being made.
The map is currently bouncing around 32000 marksurfaces, which is what causes me the most problems. Most of the time at this point, just adding a brush or two will cause QBSP to go insane and the marksurfaces will jump by hundreds and go over the limit. I've found ways of getting around that, but sooner or later I know I'll hit a wall.
I basically have to fight tooth and nail just to make small changes to the brushwork and not go over 32767 marksurfaces.

There is also a 256 model limit. I have 255 at the moment. If I add just one more Fitzquake gives me a mean old message that 256 models exceeds the 256 model limit.

It doesn't actually, but I will keep it at 255.

As of yesterday, I still have six "place holder" func_walls in the map left to play with.

I'm still kind of struggling to understand the various comments referring to flat lighting, large flat walls, small brick textures, and so on.

It's pretty hard to move along any wall, anywhere in the map for more than 128 units without something changing.

I really appreciate these comments. I think about what you guys have said along these lines quite a bit and give these comments much consideration, but when I play the map I just don't see it.

Somehow, I think the screen shots are failing me.

And if you really think this map has a problem with large, featureless walls, covered by a small brick texture with flat lighting, I have three words for you:

"Honey by CZG".

Yes, I am just teasing you there.

Yesterday, I worked mostly on the lighting in this room. It's a fairly important area that the player will pass through more than once.

What do you think?

http://www.quaketastic.com/files/screen_shots/Wish13_e.jpg

http://www.quaketastic.com/files/screen_shots/Wish13_f.jpg 

Remember: qbsp splits large surfaces every 224 units anyway. This can be used to your advantage.

Brush models and marksurfaces: This may or may not be helpful in your situation or the context of the map, but you can 'clone' existing brush models and turn them into functional entities (provided they are on the same rotation and light level as the originals). If there are identical bmodels used on several occasions, you can make one actual brush-based template and use it elsewhere as point entities. 

The screenshots are cool. Though I think I would consider using some vertical trim with seams on the sides inside the window frames. 

I like the screenshots a lot! Being overly anal about details that no player really notices can make a map worse.

Your windows on those 2 screenshots could have a stronger light emitting from them, leaving a pattern (just a cone) on the bridge. I think it looks completely fine as it is though. 

I can see a lot of work has gone into the trims and such already, I think maybe it's the contrast between the trims and the main texture that isn't different enough.
Let's be honest, the map still looks very nice and this is purely a stylistic suggestion on my part. There's nothing wrong with saying "this is my map and I want it to look like this". 

I was just elaborating on what could be meant by 'breaking up large walls'. The map does look really nice! I love those arches, and the mood of the lighting, in the shots.

Negke is right about the marksurfaces thing, but I know what it's like to be surfing the limits, and you get the map to compile nicely, why fuck with it at that point, when it's already looking really nice.

TBH it looks pretty decent to me man, go with your heart :) 

every shot you've put up so far. 

Well they are quite flat walls. But lots of popular mappers like czg have quite plain walls. I always try to pack as much detail into walls as possible, but then I could never make any of my levels very big. That's the trade-off of putting in lots of detail. Players prefer bigger levels over lots of fine detail. 

you can make one actual brush-based template and use it elsewhere as point entities

Negke, can you (or anybody) explain how exactly to do this? It's something I could possibly use in a couple of places.

There were some brushes that absolutely had to be changed and when I fixed them it blew the marksurfaces over the limit again. 

You can first try this: open the map file in a text editor and move all recently-added brushes (the ones after which the limit was exceeded) higher up, preferably to where the older brushes in the particular area are. This can arbitrarily lower the marksurfaces again.

The template trick is essentially a modelindex hack. You can look it up in mce.map (available on my site), it's used for the light sources and ammo pickups.
The original ("template") entity is a brush-based info_notnull located at 0 0 0. While this location isn't absolutely necessary, I wouldn't put it elsewhere because then it'd make placing the clones a pain in the ass. It's also lit there. I strongly recommend moving it up in the .map so it's the very first entity after worldspawn for easier reference. To save an edict, remove it on mapstart with "think" "SUB_Remove" or killtarget.

Then you can put point info_notnulls where you want the clones to appear and give them the corresponding values of the template, e.g.

"model" "*1"
"modelindex" "2"

This will create nonsolid copies of the original brush model which do not add to the model limit but take up an edict slot. They can be rotated, too.
It's possible to further modify their 'state', so to speak. For example, you can make them solid or turn them into static entities (=no edict) by adding "think" "func_wall" or "func_illusionary" and "nextthink" "0.1". However, this will override any custom rotation! 

I tried to do a similar thing with func_doors through qc. It even worked as well, after Preach explained some of the nuances of collision generation.

Nobody cared though. 

I may have to give that a try. It's a bit more complex than I thought it would be, but it could prove to be useful. Thanks for the explanation.

As far as moving brushes in the .map file to reduce marksurfaces, I've never tried that. However, my usual trick is to copy a large group of brushes that are near each other, delete them, save the map, then paste the brushes back in. I've always assumed that this is also moving the brushes around in the .map file. At any rate, it will often reduce the marksurfaces by several hundred.

I only do this when BSP goes crazy and ups the marksurfaces by a huge amount when some insignificant change was made. I don't worry about it when the change in marksurfaces seems reasonably proportionate the whatever change I've made in the map. 

That was cool. It's also the kind of thing "external model" support in Quoth is meant to help with. Currently having an actual external file is a bit cumbersome to install (and to delete when the map is finished though), so it's a bit of a hard sell to get working.

One potential solution could be to create an "internaliser" tool, which would operate on your base bsp file. It would look for all your entities which reference an external bsp file, load that external file, and bake them into the bsp as an internal model. In effect, it's formalising negke's entity hack above, but in a way that doesn't require fiddling with brush order to get it working. Plus because you created the external model independently, you've got the freedom to light it without the rest of the map interfering, and easily set the rotation centre.

There is a second solution to the loose file difficulty, but I'm afraid I'm not yet at liberty to say...Or I'd just really like to see the internaliser become reality so I've got to sell it to someone with the bsp know-how. 

Bsp referencing compartmentalised sections of itself... 

Was just idle experimentation really. Whilst I tip my hat to those who struggle to colour within the lines of bsp1 limits, I decided not to bother with it.

The internalizer you mention in fact sounds something like the skip utility, which moved brush face around so they wouldn't be visible. 

Thank you! 

<@Bal> http://www.born-robotic.net/content/maps/balostepisode.zip
<@sock> someone should re-work them into maps with vanilla gameplay 

Too bad there aren't much monsters to fight, in these giant maps.

I guess I'll have to play them with the DMSP mod.