This guide is assuming you know how to set up a default mvm map. For that reason im not going to explain the default func_nav_avoid and prefer entity. A warning though, depending on the complexity of the system it can be tough to make it. You need to be able to make a complex system of entities for the best player experience. Im not going into alot of depth on this but ill explain on what valve did to make mannhattan work.
Its a big read, but i thought its better to explain how it works than to just say what to set up. If i just say 'do this', 'do that' followed by 'and finaly do this' in the end youll still end up not knowing what you did and it can make your progress deadlock. By giving this information i hope you are able to debug your system.
Setting up the system
The first thing is to set up the control point. This is a point you already know how to set it up. This system can be similar to any map, gravelpit, gorge or granary (mannhattan using the system of gorge). The entity they used to cap is trigger_timer_door, although the other capturezone entity is most likely also working. They just used it as they wanted the door to show the capture status aswel.
To these points they tied events that on capping the bots are disabled for 22 seconds and after that get critboosted for a short moment. All these events can be custom decided per map and to know the details its best to simply look at the mannhattan decompile. Most of these events are easy to copy and use.
When the system has been set up you can test the system by joining the blue team and perform the caps (disable the mvm entities for this). Once this works you can go for the next step:
Making the bots capture points instead of the bomb
Although in a normal game bots are smart enough to capture, in mvm they are strict on going for the bomb. They wont capture points by default and youll have to steer them to do so.
Start with creating special classes to cap in the popfile. Valve used a class with 2 event settings to allow them to capture and finish by becoming a bomber. If you dont use a bomb you wont need these settings at all. Most important is to give him tags. Valve used the tag: bot_gatebot for this. Using these in your map can make your popfile work easier. In my case of gravelpit mvm i had to manualy make versions that prefer A and B (just to note that doing wrong things can give alot of work).
func_nav_prerequisite
Before making the system ill have to explain you a newer entity that wasnt explained on the valve wiki yet: func_nav_prerequisite
This entity changes the objective of a bot. They can be triggered to attack a specific object or walk to another. For cappers valve used the walking version and a target which was placed at the points. This makes bots go for the gates and because those bots had a few other tags they ignore the bomb entirely.
Once a bot has reached the target they will return to old behaviour.
To prevent your bombers getting triggered you require the bots to have the bot_gatebot tag on them which is simply a filter based on a tag similar to how you mark bots to use flanks.
Prequisite targeting
Although they have a set target it doesnt allways mean that they will behave correctly. This is because the target only has a limited reach (see it having a sort of valid radius). For this reason a target area allways needs a func_nav_prerequisite that isnt conflicting with others (a full map size one is valid for this if you used correct filters - but small is more recommended).
Its origin is being used to accurately guide the bots on where to stand. Once they reached the target. If its not on the control point they still wont cap.
The same can also be used to make bots stand back a bit during the 22 seconds of waiting between captures.
Setting up the events
Using this knowledge you can get bots to move to the gates, place a func_nav_prerequisite at their spawn and the target on the point. Voila, they will attack. But to actualy make them capture they must stay on. Place a func_nav_prerequisite at the size of the control point using the same target as you used to make them walk to the point. They will remain on the point thanks to the requirement resetting constantly. On a capture it gets turned of usualy and a new target is instantly set.
Although you could set this entity to cover the map it isnt wise to do so. Mainly because after a capture you still want bots to reach the point before walking straight to the next one (giving them shortcuts isnt recommended in mvm). Hence keeping them small is recommended. It isnt a must to do though, if you think they should instantly change then thats your choise.
Changing behaviour
Since you can constantly toggle between active prerequisites you can change their behaviour. For example if A is capped you can make the bots on that point change behaviour to attack B by turning off the old prerequisite and turning on a new one. This new one is obviously placed just behind their new spawn so they will allways touch it and for that reason allways get their new objective.
If you used events you can also toggle their events so they suddenly will ignore these prerequisites.
Other example systems:
In intercept i did have 2 prerequisite types. One for bot_gatebot_A and one for bot_gatebot_B. Once one of those points was captured i simply gave the A version the target to attack B and the other way arround. The prerequisites to attack C simply used bot_gatebot which was a tag that both types had. Thats actualy how simple gravelpit mvm can become.
For a 5cp version you could simply set the target 1 control point further. And to make bots defend aswel use the A and B system aswel where A is on the enemy point and B on their own.
Some extra notes
Its a big read, but i thought its better to explain how it works than to just say what to set up. If i just say 'do this', 'do that' followed by 'and finaly do this' in the end youll still end up not knowing what you did and it can make your progress deadlock. By giving this information i hope you are able to debug your system.
Setting up the system
The first thing is to set up the control point. This is a point you already know how to set it up. This system can be similar to any map, gravelpit, gorge or granary (mannhattan using the system of gorge). The entity they used to cap is trigger_timer_door, although the other capturezone entity is most likely also working. They just used it as they wanted the door to show the capture status aswel.
To these points they tied events that on capping the bots are disabled for 22 seconds and after that get critboosted for a short moment. All these events can be custom decided per map and to know the details its best to simply look at the mannhattan decompile. Most of these events are easy to copy and use.
When the system has been set up you can test the system by joining the blue team and perform the caps (disable the mvm entities for this). Once this works you can go for the next step:
Making the bots capture points instead of the bomb
Although in a normal game bots are smart enough to capture, in mvm they are strict on going for the bomb. They wont capture points by default and youll have to steer them to do so.
Start with creating special classes to cap in the popfile. Valve used a class with 2 event settings to allow them to capture and finish by becoming a bomber. If you dont use a bomb you wont need these settings at all. Most important is to give him tags. Valve used the tag: bot_gatebot for this. Using these in your map can make your popfile work easier. In my case of gravelpit mvm i had to manualy make versions that prefer A and B (just to note that doing wrong things can give alot of work).
func_nav_prerequisite
Before making the system ill have to explain you a newer entity that wasnt explained on the valve wiki yet: func_nav_prerequisite
This entity changes the objective of a bot. They can be triggered to attack a specific object or walk to another. For cappers valve used the walking version and a target which was placed at the points. This makes bots go for the gates and because those bots had a few other tags they ignore the bomb entirely.
Once a bot has reached the target they will return to old behaviour.
To prevent your bombers getting triggered you require the bots to have the bot_gatebot tag on them which is simply a filter based on a tag similar to how you mark bots to use flanks.
Prequisite targeting
Although they have a set target it doesnt allways mean that they will behave correctly. This is because the target only has a limited reach (see it having a sort of valid radius). For this reason a target area allways needs a func_nav_prerequisite that isnt conflicting with others (a full map size one is valid for this if you used correct filters - but small is more recommended).
Its origin is being used to accurately guide the bots on where to stand. Once they reached the target. If its not on the control point they still wont cap.
The same can also be used to make bots stand back a bit during the 22 seconds of waiting between captures.
Setting up the events
Using this knowledge you can get bots to move to the gates, place a func_nav_prerequisite at their spawn and the target on the point. Voila, they will attack. But to actualy make them capture they must stay on. Place a func_nav_prerequisite at the size of the control point using the same target as you used to make them walk to the point. They will remain on the point thanks to the requirement resetting constantly. On a capture it gets turned of usualy and a new target is instantly set.
Although you could set this entity to cover the map it isnt wise to do so. Mainly because after a capture you still want bots to reach the point before walking straight to the next one (giving them shortcuts isnt recommended in mvm). Hence keeping them small is recommended. It isnt a must to do though, if you think they should instantly change then thats your choise.
Changing behaviour
Since you can constantly toggle between active prerequisites you can change their behaviour. For example if A is capped you can make the bots on that point change behaviour to attack B by turning off the old prerequisite and turning on a new one. This new one is obviously placed just behind their new spawn so they will allways touch it and for that reason allways get their new objective.
If you used events you can also toggle their events so they suddenly will ignore these prerequisites.
Other example systems:
In intercept i did have 2 prerequisite types. One for bot_gatebot_A and one for bot_gatebot_B. Once one of those points was captured i simply gave the A version the target to attack B and the other way arround. The prerequisites to attack C simply used bot_gatebot which was a tag that both types had. Thats actualy how simple gravelpit mvm can become.
For a 5cp version you could simply set the target 1 control point further. And to make bots defend aswel use the A and B system aswel where A is on the enemy point and B on their own.
Some extra notes
- Never blindly accept your system. Allways try to test diffirent situations. Things i made as mistake before for example were:
- If it works once and fails the other time, make sure to check it. If they skip a capture point once it means that you made a mistake even if its minor. These mistakes can influence a map alot. (bots will go to the hatch and stay there being allmost inactive, these bots can influence wave balance since other bots might be waiting for them to die)
- I had a spawn before where they werent on a func_nav_prerequisite. Once bots capped that prerequisite got disabled and they suddenly ignored their objective
- All spawn places that are active should have a target for all gatebots. Even if you name a spawn B to only spawn B bots, still make sure that A bots also will accept the objective. Popfile mistakes are easy enough
- Bots are dumb, allways guide them to the position you want them to be. Never assume that they take the ideal path since many times they dont. a single func_nav_prefer does enough
- Dont blindly accept timers based on bots in an area. There are a few things in mvm that matter on capture progress. A sapper disables small bots from capping.
Last edited:
