To answer your question about RAD quality versus performance, no, that shouldn't have any effect. The lightmap scales don't change, there's just more time put into generating them. I've never seen any difference. Of course, a fullbright map runs faster, though often the difference is pretty much insignificant.
Did you notice any difference then? How much milliseconds per frame difference?
Forum posts
Before any other suggestions float in, can you tell us what you tried already, and what error messages you got?
You have to think about more stuff.Yeah, that's true. With more possibilities, expectations are higher. Unless you go for an abstract, stripped-down style of mapping (or a sloppy style :P), HL2 maps just take more time.
Impressive stuff, especially the technical know-how behind it. 
Any chance you're gonna get some grenade machineguns in there? That has always been one of the most impressive carried weapons I've heard of.
Oh, bytheway, perhaps you can use the following model. I created it once for a mod called Starlabs, but since it died, I never did anything with it. It's a Merkava main battle tank:
Download (100 kB).
Any chance you're gonna get some grenade machineguns in there? That has always been one of the most impressive carried weapons I've heard of.
Oh, bytheway, perhaps you can use the following model. I created it once for a mod called Starlabs, but since it died, I never did anything with it. It's a Merkava main battle tank:
Prop alignment just kills me, I should not have to align each and every prop by the unit, the whole process takes FOREVER, and even then in-game things look wrong.Move them with Alt and don't bother about too precise placement. I'm happy with it when it looks fine, I do most prop placement more on feeling than on measurement. Either way, it's still a time-saver over having to create the props from brushwork in the first place. But hey, everyone his own taste.
Oh, I didn't notice that question.
That's not the problem here though, inuendocrash. spot_lights only shine in one direction, so while the floor gets lit, the lamp itself doesn't. Add another light entity, set it to a small radius (either a very large, or very small faloff value, I don't exactly remember which) and put it close to the lamps. The lamps will now be lit, which surely will look better.
Adding a env_glow or env_sprite entity close to them, to add a light halo, can further enhance the effect bytheway. It's easy to spoil this effect by overusing them though.
That's not the problem here though, inuendocrash. spot_lights only shine in one direction, so while the floor gets lit, the lamp itself doesn't. Add another light entity, set it to a small radius (either a very large, or very small faloff value, I don't exactly remember which) and put it close to the lamps. The lamps will now be lit, which surely will look better.
Adding a env_glow or env_sprite entity close to them, to add a light halo, can further enhance the effect bytheway. It's easy to spoil this effect by overusing them though.
Correction: compile-time-increasing instead of compile-speed-increasing... 
Well, I don't really find HL annoying to map for - it's pretty easy because I'm so familiar with it - but whenever I want to do anything serious, HL is too limiting for me now.
I mean, carrying around power tubes to activate traps with, that's virtually impossible in HL. And it's those kind of things that I like to try out these days. However, I've got my brother (11) mapping for HL now, which is quite fun to see.
Well, I don't really find HL annoying to map for - it's pretty easy because I'm so familiar with it - but whenever I want to do anything serious, HL is too limiting for me now.
I mean, carrying around power tubes to activate traps with, that's virtually impossible in HL. And it's those kind of things that I like to try out these days. However, I've got my brother (11) mapping for HL now, which is quite fun to see.
Personally I find the Source tools to be quite an improvement (apart from the buggy nature of the automatic updates of course). Once you get familiar with the novelties (entity I/O, dismaps, props, etc.) it's much like good old HL, in terms of stretching limits and finding new tricks.
On the other hand, it can feel pretty intimidating and alien to someone who's been mapping for HL for 4-5 years. It has taken me a while to adapt, but now that I'm used to it, it's hard to get back to the limited HL engine if I really want to express myself.
As far as props go, they're much like prefabs: it's easy to overuse them, but when used right they're a blessing. Displacement maps are a huge improvement over the old terrain techniques: they turn a time-intensive, compile-speed-increasing method into a breeze. The new entity I/O looks confusing at first, but once you understand that 'triggering' is just giving the target entity a nod, where an 'output' is sending them a comprehensive message, you'll see the benefits.
But I think there are several reasons why HL is still appealing to many. Once you're happy with something, you don't need to move on to new things for the sake of it. Everyone his own taste.
On the other hand, it can feel pretty intimidating and alien to someone who's been mapping for HL for 4-5 years. It has taken me a while to adapt, but now that I'm used to it, it's hard to get back to the limited HL engine if I really want to express myself.
As far as props go, they're much like prefabs: it's easy to overuse them, but when used right they're a blessing. Displacement maps are a huge improvement over the old terrain techniques: they turn a time-intensive, compile-speed-increasing method into a breeze. The new entity I/O looks confusing at first, but once you understand that 'triggering' is just giving the target entity a nod, where an 'output' is sending them a comprehensive message, you'll see the benefits.
But I think there are several reasons why HL is still appealing to many. Once you're happy with something, you don't need to move on to new things for the sake of it. Everyone his own taste.
That doesn't mean that crossfire wouldn't have benefitted from better lighting however. It just means that interesting or well-thought-out lighting can't be a substitute for a good layout/balance/whatever other factor.
Just because a map is a deathmatch map doesn't mean it has to be too low on contrast and/or uninteresting looking. I would say that the right image is best in many aspects: not only does it look better/more interesting, it also focusses the player on the better-lit floor and ceiling, giving a better sense of direction and allowing players to focus on area's that matter.
However, I do agree no map is the same (hopefully) and that different situations call for different lighting types, but what that article presents are general thumbrules and guidelines to help those that haven't grasped these basics yet. Once you're familiar with the underlying rules, you can decide when it's usefull to cross such a rule. The same goes for vertex manipulation or any other issue: it's a dangerous tool for beginners but usefull once you know how to avoid the trouble it can cause.
At least, that's the way I see it.
However, I do agree no map is the same (hopefully) and that different situations call for different lighting types, but what that article presents are general thumbrules and guidelines to help those that haven't grasped these basics yet. Once you're familiar with the underlying rules, you can decide when it's usefull to cross such a rule. The same goes for vertex manipulation or any other issue: it's a dangerous tool for beginners but usefull once you know how to avoid the trouble it can cause.
At least, that's the way I see it.
Heh, Orph (and ZL), exactly my thoughts on lighting. There's far more to it than making a level navigateable.
A lighting compo sounds good to me. We just collected some article links at the Snarkpit, and I found two interesting reads about lighting: HL Engine lighting tutorial by 3D-Mike and Lighting (example from the book 'The hows and whys of Level Design' by Hourences). Might be helpfull.
A lighting compo sounds good to me. We just collected some article links at the Snarkpit, and I found two interesting reads about lighting: HL Engine lighting tutorial by 3D-Mike and Lighting (example from the book 'The hows and whys of Level Design' by Hourences). Might be helpfull.
Congrats satch.
A friend of mine recently got a little baby girl and it's really sweet to see how she grows up. You're in for a big adventure. As if you didn't know, hehe.
A friend of mine recently got a little baby girl and it's really sweet to see how she grows up. You're in for a big adventure. As if you didn't know, hehe.
Those shots look nice. Reminds me of the time we used to create maps of our bedrooms...
Reminds me of the time we used to create maps of our bedrooms... Skyboxes just aren't as efficient. I use the skybox 'technique' extensively in (small) test maps, where efficiency simply isn't an issue.
Funny enough, I once saw an impressive CS map, where r_speeds almost never got beyond 800-1000, but after some noclipping I found out the map was skyboxed...
Funny enough, I once saw an impressive CS map, where r_speeds almost never got beyond 800-1000, but after some noclipping I found out the map was skyboxed...
I'm surprized I'm still getting nominated even after such a long time of absence/silence... I still find it offensive, however. Just for the sake of it. Mwahaha.
Anyway, congrats guys. Oh, and a belated happy newyear.
I still find it offensive, however. Just for the sake of it. Mwahaha.Anyway, congrats guys. Oh, and a belated happy newyear.
Yes, you can disable entities.
Once you've read that article, note that you can also change the state of a multisource master with an env_global entity, which is probably more usefull in your situation: just have two env_globals for every multisource, one that sets its state to 'on', and the other to set its state to 'off'. You can also tell an env_global to set that state to it's target multisource when the level starts, which is usefull for initializing the situation.
Once you've read that article, note that you can also change the state of a multisource master with an env_global entity, which is probably more usefull in your situation: just have two env_globals for every multisource, one that sets its state to 'on', and the other to set its state to 'off'. You can also tell an env_global to set that state to it's target multisource when the level starts, which is usefull for initializing the situation.
If you make one BIG box, you will make your W_Poly count sky rocket like crazy, because the SKY texture is only 16x16.To clarify on The Hunters response: sky surfaces are disregarded, and the skybox is rendered instead, where otherwise that sky surface would've been visible. Therefor, sky brushes do not add w_poly's. The shape of the skybrush doesn't matter either: a 'skybox' has the same effect as a few skybrushes placed strategically in front of those windows. The difference is that in the skybox case, the outside walls of a level get compiled as well (e.g. everything that's inside the playable area). That increases compile times and often decreases in-game performance.
Also, surfaces are split every 240 texels (texture pixels). The size of the texture doesn't matter.
Good idea.
A few tips that can help you prevent leaks:
1. Create the rough architecture of a map with Snap to Grid set to on (it's in one of the menu's) and a rough grid size (something like 64 or 32, you can change this with the [ and ] keys). This makes sure all brushes align well with each other, so there's no tiny small leaks sneaking up.
2. Be carefull with carving, clipping and vertex manipulation. They're usefull, but a bit risky since you may end up with tiny fragmented brushes or malformed faces that get corrected during the compile, causing a leak you'll never find in Hammer.
3. Make sure entities are within the playable area. An entity outside it causes a leak. Note than in leak reports, you'll often see an entity noticed. This is the entity that's most close to the leak, so it's not the cause of the trouble in most cases.
Oh, and, for test compiles, you may want to run only csg and bsp if all you need to do is checking for leaks.
A few tips that can help you prevent leaks:
1. Create the rough architecture of a map with Snap to Grid set to on (it's in one of the menu's) and a rough grid size (something like 64 or 32, you can change this with the [ and ] keys). This makes sure all brushes align well with each other, so there's no tiny small leaks sneaking up.
2. Be carefull with carving, clipping and vertex manipulation. They're usefull, but a bit risky since you may end up with tiny fragmented brushes or malformed faces that get corrected during the compile, causing a leak you'll never find in Hammer.
3. Make sure entities are within the playable area. An entity outside it causes a leak. Note than in leak reports, you'll often see an entity noticed. This is the entity that's most close to the leak, so it's not the cause of the trouble in most cases.
Oh, and, for test compiles, you may want to run only csg and bsp if all you need to do is checking for leaks.
Add -novirtualmesh to the BSP command line to solve this problem. The odd thing is, dismaps still work just fine in HL2DM maps...
When 'Delay before closed' is set to -1, the door will not automatically close. Any other value will make the door close after the specified amount of seconds.
Take a look at the left button bar. At the top, there's a button with a white mouse cursor on it (below there are two white icons, a camera and a light-bulb one). Make sure that top button is pressed.
Spirit of Half-Life is a mod that adds various interesting possibilities for modders/mappers.
And take a look in the sourcesdk_contenthl2mapsrc folder. It contains various example maps and the source of some of the first HL2 maps too. Especially those should be interesting for you.
Visually very impressive, but the gameplay was just more of the same. Funny story, though, and overall I'm not disappointed. Very good humor all throughout, too.
Yes, that's in the gamecode, probably a #define or something.
Anyway, are you sure those models are compiled correctly? And what render mode are you running HL with? I can imagine model transparancy not working in software mode, for example...
Anyway, are you sure those models are compiled correctly? And what render mode are you running HL with? I can imagine model transparancy not working in software mode, for example...
Without Spirit of Half-Life or other custom code, no, there's no solid way to achieve this, although there are ways to fake it to some extend. Trains or doors, doesn't matter.
I find Ctrl+M less workable, because I can't see the object being rotated which makes it harder to decide it's fine or not. The compile tools will snap all vertices to the grid anyway so as long as you only rotate smaller objects (preferrably func_walls/entities only), that shouldn't be much of a problem.
@LCP: have you made sure you're in selection mode?
@LCP: have you made sure you're in selection mode?
Thanks rowley.
Big area's simply result in a lot of faces to be lit, and complex structures make the VIS process (often needlessly) complicated, thus taking a long time (often without much gain, because small details hardly ever block other area's from being visible). Trying to keep the world brush architecture relatively simple is a good idea, not just for the sake of face splitting.
I wouldn't call this 'mapping the right way'. It's simply using your knowledge of the inner workings of the compile tools for your advantage. As if a compile program or process is always designed the right way... and that's exactly why it's so usefull to know how they work.
@espen180: give the vertex tool a try. Pretty usefull in situations like these.
Big area's simply result in a lot of faces to be lit, and complex structures make the VIS process (often needlessly) complicated, thus taking a long time (often without much gain, because small details hardly ever block other area's from being visible). Trying to keep the world brush architecture relatively simple is a good idea, not just for the sake of face splitting.
I wouldn't call this 'mapping the right way'. It's simply using your knowledge of the inner workings of the compile tools for your advantage. As if a compile program or process is always designed the right way... and that's exactly why it's so usefull to know how they work.
@espen180: give the vertex tool a try. Pretty usefull in situations like these.
@RotatorSplint: the HL compile tools ignored entities during lighting, but the HL2 tools do take entities into account.
What happens is that a so-called lightmap is created at compile-time. This lightmap is a sort of colored overlay, so the game world appears to be lit. This lightmap does not change after the map is compiled. Prop models do cast a shadow, but that's all they do: the lightmaps don't change anymore after the map is compiled.
There's a way to fake your desired effect, and that's by triggering a light entity when the door opens. What happens in that case, is that there are multiple lightmap versions generated beforehand: one set for that light entity being on, and one set for it being off. You'll understand that having many such lights results in a lot of lightmap versions, so this behaviour is limited in the compile tools.
What happens is that a so-called lightmap is created at compile-time. This lightmap is a sort of colored overlay, so the game world appears to be lit. This lightmap does not change after the map is compiled. Prop models do cast a shadow, but that's all they do: the lightmaps don't change anymore after the map is compiled.
There's a way to fake your desired effect, and that's by triggering a light entity when the door opens. What happens in that case, is that there are multiple lightmap versions generated beforehand: one set for that light entity being on, and one set for it being off. You'll understand that having many such lights results in a lot of lightmap versions, so this behaviour is limited in the compile tools.
I'd probably use a func_physbox in Source, and pull or push it out of the way with a phys_lengthconstraint or some train or door to push it...
Sounds about right, srry.
'World' will align a texture to one of the side-views, e.g. if you looked at the brush in one of the 2D views, you would see the texture unscaled - if the 2D view had a textured mode, of course.
'Face' will align the texture to the direction of that face itself, and therefor gives no scaling artifacts when looking straight at that face.
World works fine for square maps and for some lightly sheared walls, and gives less misaligned edges. Face works better for more organic structures, but can be hard to align. Using the Alt texture trick here helps, but it can only do so much when you're dealing with complex objects.
Sounds good, the precompiling. Happened to me a few days ago, although it was just a 15 min. compile (yes, full compile).
Nice Ctrl+selection box trick. Do you have to hold the Ctrl button all the time or just press it while hitting enter?
'World' will align a texture to one of the side-views, e.g. if you looked at the brush in one of the 2D views, you would see the texture unscaled - if the 2D view had a textured mode, of course.
'Face' will align the texture to the direction of that face itself, and therefor gives no scaling artifacts when looking straight at that face.
World works fine for square maps and for some lightly sheared walls, and gives less misaligned edges. Face works better for more organic structures, but can be hard to align. Using the Alt texture trick here helps, but it can only do so much when you're dealing with complex objects.
Sounds good, the precompiling. Happened to me a few days ago, although it was just a 15 min. compile (yes, full compile).
Nice Ctrl+selection box trick. Do you have to hold the Ctrl button all the time or just press it while hitting enter?
If you don't see these entities, then you either loaded the wrong .fgd file or your hl.fgd file is corrupted/edited/whatever. I think the hl.fgd file can be downloaded somewhere so try Googling for it.
*Note: .fgd files contain information for the editor. You can enter entity names and parameters manually so .fgd data isn't strictly necessary, but it surely makes working with entities a lot easier.
*Note: .fgd files contain information for the editor. You can enter entity names and parameters manually so .fgd data isn't strictly necessary, but it surely makes working with entities a lot easier.
Thanks for the feedback.
Yeah, there isn't much sound in it right now. I don't have much idea's for sounds really. What sort of sounds could enhance the ambience, you think?
And what light sprites looked ugly? The ones on the swinging lights or the light beams? What do you think could enhance them?
The throwing up happened to me too, but I haven't looked into it yet. Items that fall in are also 'lost' for the rest of the round so I guess I need to set up a todo list...
Yeah, there isn't much sound in it right now. I don't have much idea's for sounds really. What sort of sounds could enhance the ambience, you think?
And what light sprites looked ugly? The ones on the swinging lights or the light beams? What do you think could enhance them?
The throwing up happened to me too, but I haven't looked into it yet. Items that fall in are also 'lost' for the rest of the round so I guess I need to set up a todo list...
I started playing about a month ago through a friend from school. Since I'm a turtler I survived so far with 40K points, without ever being attacked. Then again, all I do is scavenge the inactive players and doing lots of research, building and building defenses. I prefer to invest in safe stuff so I'm not going for a large fleet when I don't need it...
It's more fun than I initially expected but in the end, it's really just a math game. I imagine that once you've reached a certain point (graviton research perhaps) it looses much of it's appeal.
It's more fun than I initially expected but in the end, it's really just a math game. I imagine that once you've reached a certain point (graviton research perhaps) it looses much of it's appeal.
Heh, yeah, I still believe brighter maps play 'easier' for some reason, more happy or such. But this map is also a bit about the athmosphere so I don't think making it sun-light bright will work. I'll up the brightness a bit but nothing too radical.
I've got a sunny map in planning stage bytheway but looking at how this map went, I shouldn't promise anything.
I'll up the brightness a bit but nothing too radical.I've got a sunny map in planning stage bytheway but looking at how this map went, I shouldn't promise anything.
Hey guys!
It's been some time since my last visit here, as I basically lost interest in mapping and I've been quite busy with my internship anyway.
However, I've picked up work on Mudanchee again, since the last version was fully playable anyway and all that needs to be done is some polishing and prop skinning.
Version 0.26 can be downloaded here (6.3 MB). I've done a little work since this version, and there's still some stuff to do, but it should give a good idea of the final quality.
So, here are the latest developments depicted in screenshots:
All platforms will finally be made of individual planks.
Also, I've chosen a different rock texture, one with a bumpmap.
A tomb cave overview, orange blocks still need replacement.
The central cave.
Overview of the central cave.
A more recent shot of the waterfall cave. This cave is almost final now.
A shot of the new waterfall material. I still want to add some shinier effects though.
Go ahead and give it a view. I'd appreciate any feedback. I'm planning to organize a playtest soon, so if anyone here is interested, I'll keep you up-to-date.
It's been some time since my last visit here, as I basically lost interest in mapping and I've been quite busy with my internship anyway.
However, I've picked up work on Mudanchee again, since the last version was fully playable anyway and all that needs to be done is some polishing and prop skinning.
Version 0.26 can be downloaded here (6.3 MB). I've done a little work since this version, and there's still some stuff to do, but it should give a good idea of the final quality.
So, here are the latest developments depicted in screenshots:
All platforms will finally be made of individual planks.
Also, I've chosen a different rock texture, one with a bumpmap.
A tomb cave overview, orange blocks still need replacement.
The central cave.
Overview of the central cave.
A more recent shot of the waterfall cave. This cave is almost final now.
A shot of the new waterfall material. I still want to add some shinier effects though.
Go ahead and give it a view. I'd appreciate any feedback. I'm planning to organize a playtest soon, so if anyone here is interested, I'll keep you up-to-date.
Some more contrast on the floor yeah, either through lighting or with some trims or marks. And some crack decals on those pillars, at the 'knack' point. Their absence is noticeable - it's like a connected surface while really it should look broken. Add the details where they count.
3d shot shows an impressive hall, those pillars look nice. I would, however, alter that pipe somewhat: add a fence around it and some grating in the floor below it. Looks more cautious and convincing that way. The staircase could use a railing too, they're so convenient.
Other than that, looky good.
3d shot shows an impressive hall, those pillars look nice. I would, however, alter that pipe somewhat: add a fence around it and some grating in the floor below it. Looks more cautious and convincing that way. The staircase could use a railing too, they're so convenient.
Other than that, looky good.
Kramer is correct, leaking is an engine-specific term, closely related to the bsp-tree system in fact. Take your average 3D RTS for example: tell me what a leak would be in such a game...
As for the T-shirt, I think those entity names are too loosely placed there, satchmo. I like the origin indicator, but those entities are too much. Perhaps add some purple and green blocks, to get the entity message across and give it a more iconic look. And a mouse selector perhaps...
As for the T-shirt, I think those entity names are too loosely placed there, satchmo. I like the origin indicator, but those entities are too much. Perhaps add some purple and green blocks, to get the entity message across and give it a more iconic look. And a mouse selector perhaps...
Nice stuff there, Muzzle. I see you got quite some further than my simple copy-pasting some year ago. I wonder, could you get those grunts to utilize Teh Mightly Grenade Machinegun? For some additional mayhem?
To everyone who's interesting in getting started with C++, Microsoft Visual Studio Express is freely available. I'm not sure if it works well with the HL SDK, but in fact, MSV 6.0 had two particular things it fell about too (wavelength has an article on how to fix those 2 code lines).
To everyone who's interesting in getting started with C++, Microsoft Visual Studio Express is freely available. I'm not sure if it works well with the HL SDK, but in fact, MSV 6.0 had two particular things it fell about too (wavelength has an article on how to fix those 2 code lines).
You don't need Hammer, because the used wads are already referenced in the .map file. I assume you still do need the .wads though, since the compile tools seem to scan them briefly.
Current page will be modified with the new rules and the timer will be reset to 5 days - gotta go now, will read the rest later today.
Ok, these are the BrushoPolis results:
Rowleybob wins with his entry, showing a nicely detailed monumental building, including parking places, bus stops, a construction site and residential buildings. Although somewhat dark, the interesting details fit in well and create a very believable and interesting environment.
Second comes Worldcraft dude with his skyscraper map. Nice and impressive to see, this map goes more large-scale. Small details like light poles are present but there's less street-level stuff than Rowley had. The additional car sounds created a good athmosphere though, if only there were some cars around...
Obviously this is what Worldcraft dude fits best: high skyscrapers and a city environment. Well done.
Last comes noob #2, but that doesn't mean it's a bad map. It had the best 'intro' of all: a beach walkway looking out over the sea, and you'll gradually be entering a village. noob #2 did a good job with his beach-side village map, though there weren't as much houses as I'd expect for such a village area and the wall did look odd, though it is a way to get rid of the sudden ending map problem. The buildings I did saw were of good quality however and it was the only map that contained a vehicle.
Congrats to you all, I was impressed at the quality of all three.
Combi map is (and I should've expected that) technically... demanding... if it wasn't in the first place for the different environment lights...
So, before going though the hassle of optimizing and such, what would the competetors want to see? Daylight, or night, or something in-between?
Rowleybob wins with his entry, showing a nicely detailed monumental building, including parking places, bus stops, a construction site and residential buildings. Although somewhat dark, the interesting details fit in well and create a very believable and interesting environment.
Second comes Worldcraft dude with his skyscraper map. Nice and impressive to see, this map goes more large-scale. Small details like light poles are present but there's less street-level stuff than Rowley had. The additional car sounds created a good athmosphere though, if only there were some cars around...
Obviously this is what Worldcraft dude fits best: high skyscrapers and a city environment. Well done.
Last comes noob #2, but that doesn't mean it's a bad map. It had the best 'intro' of all: a beach walkway looking out over the sea, and you'll gradually be entering a village. noob #2 did a good job with his beach-side village map, though there weren't as much houses as I'd expect for such a village area and the wall did look odd, though it is a way to get rid of the sudden ending map problem. The buildings I did saw were of good quality however and it was the only map that contained a vehicle.
Congrats to you all, I was impressed at the quality of all three.
Combi map is (and I should've expected that) technically... demanding... if it wasn't in the first place for the different environment lights...
So, before going though the hassle of optimizing and such, what would the competetors want to see? Daylight, or night, or something in-between?
You do need the .wad files as far as I know. At least that's what I think considering the compile tools check for texture memory usage...
Do you mean the word 'vectors', pepper?
Yeah, fresh as in clean. Perhaps it's the strong dark-greenish tone of the screenie that makes it look like muddy water, or the greyish water surface itself. Try some more blueish or more intense greenish?
Some Serious Sam levels did the same actually. And yes, it's a code thing - not really a simple thing though, I assume.
New page is up and running:
Detail-a-Hallway competition page.
You may want to send me some clarifications on the judgement part, or any other part, and I'll update it a.s.a.p., Muzzle. Good luck you all!
Previous results will be posted at tuesday, bytheway.
Detail-a-Hallway competition page.
You may want to send me some clarifications on the judgement part, or any other part, and I'll update it a.s.a.p., Muzzle. Good luck you all!
Previous results will be posted at tuesday, bytheway.
If you guys want a room compo, then a room compo it shall be.
Team compo sounds good too, perhaps not on these short terms but definitely something interesting. I'm thinking towards texture artist + mapper somewhat though that's probably not feasible here on TWHL.
Results coming up within 2 days or so, I've already made some notes but it's going to take a little time to decide who really won, and to prepare the combi-map.
And I'll happily prepare a next compo page, with timer, image and rules 'n stuff.
Team compo sounds good too, perhaps not on these short terms but definitely something interesting. I'm thinking towards texture artist + mapper somewhat though that's probably not feasible here on TWHL.
Results coming up within 2 days or so, I've already made some notes but it's going to take a little time to decide who really won, and to prepare the combi-map.
And I'll happily prepare a next compo page, with timer, image and rules 'n stuff.
Nice stuff, Trapt. I'd add some fences by the buildings up on the ridge though, because the lighting on the side of the buildings indicates there's a path there (otherwise you wouldn't need lights there, right? :)), and since there's a rail below... I'm talking about the yellow building specifically.
Alternately, take out those lights to put more focus on the entrance of that building plus the truck.
Rabid, your architecture is looking great and it breathes a worn-off industry athmosphere. I'm not sure about the greenish lights though, in combination with the red brick and reddish skylight. Some more yellow would suit the red better, I think. Also, consider upping the brightness some. It's nice and moody, but a bit too dark to show off the good stuff. Might be just the screenshots though.
Good luck guys, nice stuff.
Alternately, take out those lights to put more focus on the entrance of that building plus the truck.
Rabid, your architecture is looking great and it breathes a worn-off industry athmosphere. I'm not sure about the greenish lights though, in combination with the red brick and reddish skylight. Some more yellow would suit the red better, I think. Also, consider upping the brightness some. It's nice and moody, but a bit too dark to show off the good stuff. Might be just the screenshots though.
Good luck guys, nice stuff.
The screenshot looks rather dull really, the colors aren't fresh or pool-like. But the conveyor water trick works nice, ah? I used it several times in The Playtest, only without an added func_water.
I used it several times in The Playtest, only without an added func_water.