Bug's Tug of War Logic - No Stalemates One Team Will Win

[Kill_the_Bug]

Hello Peeps,

I haven't seen a whole lot of tutorials or resources on this game mode so I thought I would post one here

What's inside:

• working bsp
• nav file
• vmf, vmx

This has taken me hours to get the code working right - there's a S*load of coding to do in these maps (basically you're making two payload maps in one), if anyone finds any errors, please let me know.

And now for the explaining of Tug-of-War aka. TOW :

The Basics:

• Think of it as a standard payload style of gameplay except that you have to code it for both red and blue - so all of your coding will be double - be careful of this as the entity count will get very large very fast
• The map will always have an odd number of cap points, 1 neutral staring point and however many you want on either side, 7 caps are the highest you can go.
• Even though you have both of the above - the programming is linear - path_track_start > path_track_end and the same goes for the cap points 1,2,3,4,5,6,7
• There are three pushzones: 1. Initial, 2. Red, 3. Blue. #1 is triggered by either team and is killed instantly on team cap where either 2 or 3 is activated.
• Speaking of action if, 2 is in activated, 3 is disabled and vice versa - both are controlled by onstarttouchall for their team, you can only activate the disabled item by pushing or killing the other team out of their cap zone. Of course if no player is in the zone - no payload movement, game logic controls cart movement, not the watcher
• The path track has to be the same length on both sides of the center point or else the HUD will appear off center in game
• The HUD will always have a house on the left, and you can't get it on the right, this is a hard coding issue in the game files that I haven't been able to get working and you can't seem to use custom HUD icons either for payload via the Hologram props.

The Complicated:

• Spawn rooms are dynamic and are hard to program as they will be in constant use depending on where the cart is - they will have to move both forwards and backwards
• The same goes for the player spawns - they will have to move forwards and backwards
• Spawn room teleportation - each room will have to have two player teleporters, one forward, one back and these are activated upon cart location - the teleporters will move any players left in spawn to the new spawn room forwards or backwards

- The three items above are controlled by control point logic and trigger relays*
- Cart movement is controlled by logic cases and remaps

* There is heavy use of trigger relays (it helps you from going crazy) in the map. Example: A control point

• Cart approaches and passes node A (The relays are disabled because it would trigger the for the wrong team). This node has (3) three relays, Relay 1 - the ownership of the point, Relay 2 - the teleporter logic, who goes where and Relay 3 - the spawn room logic + anything else going on like prop dynamic arrows, open/closing doors, etc.
• Cart approaches and passes node B - the Neutral point - nothing happens you don't want it to.
• Cart Approaches node C - this node is NOT disabled because you want it to fire Relay 1, 2 and 3
• The only difference is that the nodes are team and direction specific. The attackers push past the defenders node 'A' to their node 'C'. C fires the relays on pass for the attackers. One of the lines in their Relay 1 is to disable Relay 1, so it doesn't fire again if the defenders push past it. The other line in Relay 1 is to Enable relays attached to the defenders node A. So defenders can push past C and B and when they pass node A - it fires, whatever is coded there will fire and one of the lines that Relay 1 is to disable relay 1 attached to node A, so it doesn't fire again if the othre team pushes past it. The other line also in Relay 1 is to Enable relays attached to the defenders node C.

The Control Point Logic:
- Each point is controlled by three path_tracks close together, 1,2,3 or A,B,C. I would recommend that you call them in this fashion:
Start at your path_track start #1 (whatever team colour that is) and then move towards path_track_end #7 if you have seven points. Let's say blue is on the left> direction of movement is right
At CP 2 (1 and 7 are the last points and have different coding), the first node A will be left un-named at the start, node B will be called CP2-Neutral (believe me doing this will keep you from going insane later), node C will be called CPOwnerisBlue_going_to '(your next CP)' (believe me doing this will keep you from going insane later)
At CP 3 - same as 2 - the first node A will be left un-named at the start, node B will be called CP3-Neutral (believe me doing this will keep you from going insane later), node C will be called CPOwnerisBlue_going_to '(your next CP)' (believe me doing this will keep you from going insane later)
At CP4 - repeat BUT in this case, the first node A will be left un-named at the start, node B will be called 'Start_of_War or Center Point', Node C....repeat
At CP5, Same
At CP6, Same

Now that you have named them all in one direction you head back in the other direction starting at node CP6 Node A

At CP6 - Change CP Node A to 'CPOwnerisRed_going_to '(your next CP)'
At CP5 - Change CP Node A to 'CPOwnerisRed_going_to '(your next CP)'
Repeat until you have all node A's renamed so each CP will look like

Direction of Motion > is still left right > Cap point #2 Node A is now 'CPOwnerisRed_going_to (#7 Blue's Final CP)', Node B is now 'CP2-Neutral' and Node C is now 'CPOwnerisBlue_going_to (your next CP- CP#3)'

What about 1 and 7?

Same coding for each - this triggers the victory

• Onpass - kill train, delay 0.1
• Onpass - Pusher_Zone_Blue (or red depending what end you're at) CaptureCurrentCP
• Onpass - Setowner + team number
• Onpass - Payload_Constraint, Break
• Onpass - stop dispensers from dispensing

Cart will fall into hole - this triggers the boom
- Payload model will hit your trigger brush, on hit do your boom sequence

What You will see in game and in the VMF

In Game

• two sides, red and blue
• different cubilces 0,1, 2, 3, 4 < these are the spawn rooms, 1 is killed instantly (you can progrm it not to if that's what you want for your map) and spawnroom logic is wholely responsible based on cart location. Notice also that for one team it's 0,1,2,3,4 and it's the opposite for the other team 4,3,2,1,0 just like the coding above
• doors - examples of one way doors and two way doors (single arrow vs 2 arrows) - these are also coded into the logic so you can see how they work
• floor overlay in spawn room - two images - the man is where you the player spawns, the man with the top hat is the teleportation exit from one room to another. Note: there is only one exit you will be coding the forward or backward teleport to transport to this exit based upon cart location
• arrows on the floor inside the spawn one left, one right, if the teleport is active in that room you will walk past the arrow and be teleported to wherever the new spawn is
• pit door triggers to open/close door, sounds, lights, etc
• payload crate - this is where you put in your custom prop, it's just a placeholder
• working ownership indicators based uopn cart location i.e. blue controls a point all the track makers on that point are blue, if red caps they turn red.
• a separate nav file to put in with your maps folder to run bots - it's a slaughterhouse that's pretty evenly balance- but red will NOT push the cart - it's not in their AI coding < unless you can figure out a way for them to attack the cart.

The VMF

• all the coding for the map, teleporation logic, spawn room logic, cap point owner indicators, etc.
• everything is colour coded - orange are the forward teleports, red dev the backwards teleports - in your map these will cover the entire spawn room, they are placed in this fashion for the test map so it's not confusing for you when trying to learn it.
• everything is mostly vis grouped, i.e. main game logic, cart logic, cap point holograms. By checking unchecking you can look at things easier

Well that's it. Enjoy!

Buggy

 

[Kill_the_Bug]

Edit: although the code for the last cap works there are a couple of times when the trigger might not fire ( I only found this out in gameplay that would not be duplicated in a real game) i.e. payload model would hit the node before the train brush which can happen with custom model. Here is the work around:

Move the Kill train and and phys break to the cap point hologram and then use oncap team x to do these commands, which causes cart to fall into the pit for you boom time!

 

[Kill_the_Bug]

Ok Peeps - here we go - the update of all updates!

Well after 3-4 weeks + a number of hours today - I finally solved the stalemate issue for the Tug of War (TOW) game mode which has palgued this game mode forever on ALL TOW maps. The only time stalemate will occur is if both teams never touch the cart and only kill each other.

The TOW game mode will now work based on the following:

• Points for Capping Points
• Points for You Team's Possesion of the Cart
• Capping the final point - which overrides all of the above

Gameplay Summary Example:

Red team pushes the cart and gets points (on a timer) from when they start to push the cart - blue gets zero points and vice versa if blue has the cart.

Red team also gets points for capturing a checkpoint - while blue looses a point - and vice versa if blue caps a point red looses a point.

Let's say red has 40 points and blue only has 10. Red wins right? Well maybe not!

If the blue team suddenly get's their act together and pushs the cart all the way to the end of red's side to the final cap point - then blue wins the match even if red has held onto the cart for most of the round - and vice versa if blue has held the cart for most of the round and red pushes it right to the end.

Therefore:

No more stalemates for the TOW game mode.

Games will be won or lost based on aggression! The harder you fight for the cart or the harder you defend the cart = VICTORY for your Team! Because of this points based system!

---

What's in the file?

A working bsp and the VMF file so you can see all the coding.

So what's new? And this is going to get confusing as hell but bear with me

I'm still using the same sort of coding in post number 1 except I have added in a point system for capping the points

My map as 7 cap points and are broken down as follows:

• there are 2 end points one for each team (not counted in the points system)
• the center point starts neutral (0 Points at round start but it's worth 2 points at starting cap - more in a sec)
• 2 points enroute to the final cap point - these count as one point each
• a total of seven cap points

So therefore at round start - both the red team and the blue team each have 2 points to start with although it's not shown

On map start, if no one touches the cart for the ENTIRE Round, then stalemate occurs because the score is 2 points for each team.

Now here's where it gets confusing:

On round start either red or blue will capture the center point (i.e. bridge) and the team that caps it gets 2 points

Example - let's travel in the direction fo red to blue base

red 2 points - blue 2 points, red caps + 1 point | score now | red 3 points - blue 2 points red contiunes to push and caps the next point
red 4 points - blue 1 point - NOTICE THAT BLUE HAS LOST A POINT AND GIVEN IT TO THE RED TEAM - red continues and caps the next point
red 5 points - blue 0 points - blue now has to defend the last point and if red takes it, red team wins the round - just like a normal TOW map.

So what happens if blue starts to push back?
On Cap 1
Red 5 points - blue 1 point
on cap 2
red 4 points - blue 2 points
on center cap (i.e. bridge)
red 3 points - blue team 3 points < aha you say there's the stalemate - no it won't happen because of the timers explained in a minute - ha no pun intended)
on cap 4
Red 1 points - blue 4 points
on cap 5
Red 0 points - blue 5 points

and now for the wildcard item - THE TIMER

• when red or blue touches their pushzone at the cart, it enalbles their timer and disables and resets the other team's timer
• on timer expired (i.e. 30 seconds you can set it to whatever you want) players hear a team specific 'ding' and a HUD notification that a point has been aded to their team's score
• so the battle for the cart becomes absolutely the main goal because whoever touches the cart last has the timer counting for their team

i.e. if blue and red fight at the bridge and red wins the fight - the timer is counting for the red team EVEN IF all the players at the cart get killed in the fight - blue has to touch their cap zone to stop red's timer and get theirs started. So if all players die again - blue team's timer is counting down to give blue a point.

So winning the Tug of War now comes down to owning as many points as you can AND keeping possession of the cart.

At round = zero time - a logic compare is run and whomever has the most points (red or blue) - THAT TEAM WINS THE ROUND and a single point is awarded to the red/blue team on the overall points scoreboard.

HOWEVER

IF ONE TEAM CAN PUSH THE CART ALL THE WAY AND CAP THE FINAL POINT - REGARDLESS OF HOW MANY POINTS THE OTHER TEAM HAS - THAT TEAM WINS THE ROUND.

So if one team has zero cap points - it's still possible for them to win because they held onto the cart longer over the cours of the entire round.

Enjoy peeps and keep those TOW maps coming!!

Note: I have lowered all the time values for testing purposes, you'll have to tweak them for your own maps

Iif you want to add in a counter to show the scoreboard you could try to configure this into your map as well - I haven't done it yethttps://tf2maps.net/downloads/engineers-counter.646/

Aslo - Please credit me is used thanks