- Jul 5, 2009
- 249
- 28
Here's another idea I want to run by people to see if they think it'd be viable. If not, so be it. I'm just curious if it'll work before I start up Hammer and find out for myself 80 hours in.
I've already figured out, more or less, how to handle randomized items, like getting props to show up (and I'll do a tutorial before long here) and so forth. But I was thinking about expanding that.
Specifically I was thinking about an arena map where relatively little of the map is actually static- instead, the majority of the map is all entities- brush based or otherwise- and hooked up to a randomizer. So, for instance, one round you're running through a mansion. The next, you're out in the hedge maze. Another you've got the secret underground lair hidden beneath the mansion. Everything is enabled or disabled based on a random pick in a Logic Case, with each Case representing an entire layout.
The immediate problem that comes to mind is lights- to enable/disable them in groups would require named lights. On the upside, entire sets of lights could be named identically (and in fact this would be optimal for purposes of the randomization), reducing the number of pages rather significantly as each set of lights would merge together, which (if I'm not mistaken) would mean only one page per layout. Of course, this doesn't help with the problem of VRAD only compiling direct lighting, but I think I could fudge things using unsourced lights with properly-tweaked constant, linear, and quadratic settings.
The second problem would be the skybox, although this is relatively minor. A common 3D skybox would assist in fixing this problem, but the possibility of binding skybox props to the randomization could work here as well- which would only be important in terms of relative positions. If the hedge maze is to the East of the mansion, for example, skybox props could be cloned, moved West, and linked to the hedge maze set. The static elements in the skybox would be fine as is, as it would likely seem like parallax effects and nothing to worry about. Then again, with parallax already going on this shifting may not even be necessary.
Third problem is budgeting- I'd imagine that making effectively three arena maps would bloat the file size and I'm not certain how that many entities (and so little world geography) would affect things. I'm sure I'd already be running into issues with the limitations on the number of props, and things like func_detail T-intersections could get to be a problem as well. But those limits might be high enough that it won't cause trouble in the larger scheme of things.
In any case, I'd like to see what the more experienced map-makers think of my latest ridiculous scheme.
I've already figured out, more or less, how to handle randomized items, like getting props to show up (and I'll do a tutorial before long here) and so forth. But I was thinking about expanding that.
Specifically I was thinking about an arena map where relatively little of the map is actually static- instead, the majority of the map is all entities- brush based or otherwise- and hooked up to a randomizer. So, for instance, one round you're running through a mansion. The next, you're out in the hedge maze. Another you've got the secret underground lair hidden beneath the mansion. Everything is enabled or disabled based on a random pick in a Logic Case, with each Case representing an entire layout.
The immediate problem that comes to mind is lights- to enable/disable them in groups would require named lights. On the upside, entire sets of lights could be named identically (and in fact this would be optimal for purposes of the randomization), reducing the number of pages rather significantly as each set of lights would merge together, which (if I'm not mistaken) would mean only one page per layout. Of course, this doesn't help with the problem of VRAD only compiling direct lighting, but I think I could fudge things using unsourced lights with properly-tweaked constant, linear, and quadratic settings.
The second problem would be the skybox, although this is relatively minor. A common 3D skybox would assist in fixing this problem, but the possibility of binding skybox props to the randomization could work here as well- which would only be important in terms of relative positions. If the hedge maze is to the East of the mansion, for example, skybox props could be cloned, moved West, and linked to the hedge maze set. The static elements in the skybox would be fine as is, as it would likely seem like parallax effects and nothing to worry about. Then again, with parallax already going on this shifting may not even be necessary.
Third problem is budgeting- I'd imagine that making effectively three arena maps would bloat the file size and I'm not certain how that many entities (and so little world geography) would affect things. I'm sure I'd already be running into issues with the limitations on the number of props, and things like func_detail T-intersections could get to be a problem as well. But those limits might be high enough that it won't cause trouble in the larger scheme of things.
In any case, I'd like to see what the more experienced map-makers think of my latest ridiculous scheme.