User:Draco18s/Hedgerow
This project mostly exists to push the boundaries on what can be done within a level to make it fresh every time it's played. The director is little more than a random number generator, but how far can I push that?
Contents
Project Status
Name: Hedgerow Type: Campaign (Versus not anticipated, possible Survivor maps) Chapters: 2+ Status: 0%
Tool creation: 10% (Tools are things I'm developing to aid in map unique-ification) Chapter 1 planing: 90% construction: 50% Chapter 2 planning: 90% constuction: 70%
Hedgerow chapters themselves will be mazes, the first of which is a hedge maze, initiating the pun. Corn maze will also be present. A house of mirrors also piques my interest (do we have reflective surfaces?). Fairgrounds setting?
Chapter 1: Hedgemaze
Hedgemaze is captured in all my artistic glory to the right. The maze is random, there are 5 pairs of walls which can independently alternate, making for at least 10 unique routes without heading backwards. Get it here!
Oops, you need a nav mesh too (Stupid website forcing me to wait 24 HOURS before uploading another version).
Chapter 2: Secret Passages
Secret Passages is all about, well, the unseen, the unobvious, and the hidden. While it is possible to complete the map without taking advantage of the alternative pathways, you're missing half the fun. There are 2 main routes in the first half of the map, 1 hidden route, 1 bounce, 1 main loop with crescendo, and 1 items loop. The second half of the map has 2 main routes, 1 alternate route, 2 hidden routes, and 1 secret items room.
This map attempted to make use of the Bounce and Loop level design mechanics. While not completely valid as far as Left 4 Dead is concerned (nav_mesh bot pathing), nor terribly expansive like other Source games (see articles), I think it does make the map more interesting.
Tools
I don't think I can implement all of these, this exists as a collection of novel ideas.
Level Randomization
A neat trick, that I think Valve worked in minorly, not to the degree which I wish to push it. On No Mercy 2 after the white car to the right of the open van is a garage, sometimes it's open (pipes and Molotovs only) sometimes it's closed.
I've managed to build a series of logic nodes and walls that can be activated or deactivated at random. Right now all I've got is a basic layout. Conceptually each cell (area between the walls) could be a whole room of an apartment building with 4 exits: broken walls, doors, etc. Or even more drastically, each one could be a whole house, containing its own internal pathways between the four "edges" and the walls are merely blockages of one form or another (semi truck, fence, barricade, crashed car, hole in the wall) that can be summoned up or banished at the will of the RNG.
A necessary step in properly building these modular sections is a way to alert the human players which way to go, for this I have created orange spray paint arrow objects to spawn pointing in the right direction (or one of); logic_case objects were used to determine which arrow to make visible. Unfortunately the bots are stupid and it's impossible to modify the navigation mesh at runtime (though zombies will climb over obstacles--if the nav mesh connects through them).
Implementation
For those looking to implement this, the steps are simple: 1) create a wall, bind it to a func_wall_toggle entity, name it, and either set it flag to "starts invisible" or not, as you choose. I suggest picking one and sticking with it. 2)create logic_case entity and create 1 case per wall. If your walls start invisible this case will make it visible. Good for blocking off 1 route of many. The reverse means that it opens up one of many routes. I personally have only 2 walls to each logic_case entity, with exceptions where pure randomness creates non-navigable mazes. 3) logic_multicompare entities can help alleviate non-navigable mazes by opening up routes when all the other routes were closed at random. Merely add case outputs for each "closed route" wall to the compare object sending 1 as the parameter. Set an output on the logic_multicompare to OnEqual to trigger a wall (this wall should start visible).
Moving Crescendos
An idea thought up on the official forums, namely a panic event that is continuous until the survivors reach some area.
Additional Testing
These are entirely feasible.
- 1 Logic_Timer set to "disabled on start" with a timer of about 5 to 20 seconds.
- Some Logic_Case entities to spawn zombies in different places every time
- 1 Logic_Relay for each area to spawn zombies in
- Some Info_Zombie_Spawn entities in each spawn area, one per zombie to spawn.
When your panic event goes off (trigger it normally) also add an output to the Timer to enable it. Just after the AI triggered crescendo's zombies reach the players the timer will have hit 0 and spawned more zombies, continuing the event.
No endless_events needed!
Crumbling Ground
Possible motive for moving forward fast: the ground below (or some moving object, such as an oncoming train) forces the survivors forwards, or perish. Need not be combined with a typical panic event.
Split the Party
Feasible in Left 4 Dead 2
Some dual-triggered event spawns a wall between two halves of the 4 survivors (2 and 2 or 1 and 3). Each group acts independently until they regroup a short while later.
Got back into L4D mapping recently and looked over this list of stuff again. So I did up a dummy map and tested this idea out, as it had been seemingly forgotten.
Implementation:
- Two buttons linked to a logic_relay
- Two trigger_multiple set to detect onEntireTeamStartTouch (Survivors) and disable one of two buttons (can't proceed unless the party splits).
- One trigger multiple that is a single entity of the same two areas covered above, set to disable the buttons onEndTouch. OnEntireTeamStartTouch enables them.
- 0.1 second delay on all lock/disable events, so they occur last (ensuring that any trigger that would prevent the buttons from working is the last event that fires, leaving the buttons in a locked state).
What this does is prevents the buttons from working while the entire team is not ready and prevents the buttons working if the party is not in two groups.
Results: fantastic. The bots, due to dynamic pathing, seem to always split up at the event location for some unknown reason. One bot with not follow the player long and allow the button to be pressed. I did not test to see how long the bot dallied away from the group, but it does mean that as a mapping tool, the map would be fully playable single-player as well as co-op and versus. I am integrating this mechanic into a full fledged map that will be part of a collaborative campaign and see how it goes.
- Route length: approximately 22.5 seconds (running, no zombies) each side.
- 1 drop-down per side.
- 1 broken wall (passable)
- 1 broken wall (impassible)
- 2 broken floors
Block off the Past
The reverse of a Door to Before. No Mercy 4 has an example of this, the elevator. If you aren't in in, you're left behind. For good. This tool merely exists as a collection of possible alternatives to the elevator.
To the right is a crude animation of the castle gates closing and ending the earlier moving crescendo event. I should have grabbed more frames of the gates in motion, but standing in the same spot aiming at the same spot while the gates are moving and trying to catch it at the right moment is difficult.
Fighting on the Move
Not viable
Namely, a crescendo or finale that takes place on a moving object, such as a train. This one is likely impossible to achieve properly, and even less likely to work gracefully in versus.
Initiated an attempt at this one today. Several main issues to overcome:
1) Bots don't like the train. At all. If I spawn them off it, they won't get on it (even with a nav_mesh--if they aren't on the train, the finale won't start). If I spawn them on it, they slide off when it starts to move. I added in chest high railings to keep them on, limits visibility, but they can't jump off (foot high barriers they jumped over--idiots).
Additional Testing
Bots are still f-ing stupid.
2) The train jerks to a halt if any infected (or player) stands in front of the train.
3) Minor, but using a mounted minigun while riding the train has the visible barrel jumping badly. Doesn't effect aim, but looks bad.
4) My initial map is likely too large. Generating a nav mesh had to be done in quadrants. Finale hoard spawns are pitifully tiny against the background, and get shot down trying to chase the train engine. Added in a repeater logic object to add panic events every minute or so, triggering more hoards. I don't know if it works or not, my last test didn't seem to show any more zombies than before...
5) More train cars. Essh. Adding in more cars would be difficult.
6) Infected can't jump onto the train. They can try, but are frozen in place as the train slides out from under them. I'm going to try and give them a ground-level platform to jump onto first (plus anti-bot-slide railings on the back), to see if that helps.
Additional Testing
Adding 5 foot wide platforms was not enough, even standing on the platform and climbing up higher caused them to be locked to the unmoving terrain. Likely because common infected are objects, not players. This would also cause an issue if the roll of train and terrain were reversed (i.e. train is static and the scenery moves around it): the bots would "glide" over the terrain and be unable to do anything about obstacles (impacting on tends to cause death: numerous zombies were run over by my ground level platforms).
More Additional Testing
I reversed the rolls of "train" and "static" such that the terrain was moving relative to the game world, rather than the player's train object. Infected still jam the train to a hault even when there are push objects on the leading edge.
As a side effect of the nav mesh not matching up with the environment all the time, zombies spawned in mid air. I fixed this by adding in NPC clip brushes in the air around objects that they couldn't spawn above (such that the open spaces were only above legal spawn locations on the terrain).
Also had an issue with zombies attacking the players. I did a ongameplaystart director command to tell the director to start a panic event, but the zombies just stood there.
This might be viable if a way of keeping the zombies from blocking the train is found.
7) Train speed. At 125 units/second the train doesn't appear to be moving all that fast, a decent clip, but it's at least as fast as zombies. Balance will need to be found. Boomers will likely pose no threat on this kind of map.
Additional Testing
85 speed units seems to be decent. Train feels like it's on the move, zombies can easily catch up (and get run down).
Multiple Safe Rooms
Two ending safe rooms.
Two routes you could take.
Two different next maps.
Which do you choose?
Initial Gathered Knowledge
This method isn't exactly feasible. Bots will have trouble, the nav_mesh ESCAPE_ROUTE only goes to one room, and all (living) survivors need to be in the same safe room in order for the level to end. If they aren't, but both doors close, no one is sure what would happen, it is assumed that nothing would happen, both safe rooms would consider that someone is alive and Not Inside.
