[Information] Bot control in mvm: Control points

Discussion in 'Tutorials & Resources' started by UKCS-Alias, Feb 4, 2014.

  1. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    748
    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
    • 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.
     
    • Thanks Thanks x 11
    Last edited: Feb 9, 2014
  2. s0da72

    s0da72 L2: Junior Member

    Messages:
    74
    Positive Ratings:
    17
    good info, thanks for sharing..
     
  3. henke37

    aa henke37

    Messages:
    1,836
    Positive Ratings:
    420
    Feel free to write up a good wiki page, it is a wiki.
     
  4. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    748
    I updated the post with 2 things.

    I had to add a 2nd note for the func_nav_prerequisite. There seems to be some extra behaviour on them which at first i wasnt even aware it existed (until my map failed by making bots not go for A and instead stand in front of it).

    And i added some extra notes to watch for. Although most are clear enough, reminders cant harm.
     
  5. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    748
    Ok, some extra info.

    Bots barely listen to a func_nav_prerequisite. They require alot more to actualy make them use it.

    To keep it simple the following pathing thing should be done:
    • At their spawn make a func_nav_prerequisite to target them to the control point.
    • Make a func_nav_prefer path that crosses and ends on the control point. They MUST pass the point on it or it wont work
    • Finaly on the point have another func_nav_prerequisite. They use this in combination of the prefer to alternate positions so they dont staticly stand at 1 point and insteed keep moving.
    • Make sure that after the prefer stops somewhere inside the prerequisite. Otherwise they will walk to the end of the point and stand there. They try to keep as close to the objectives as they are guided to. This can require alot of trial and error but will make the bots behave better.
    • After capping trigger a new nav prefer and prerequisite to be on to guide them to the next point.

    It does require trial and error since no map behaves the same and bots cant allways be predicted on behaviour. Still, the more static the system the easier this should get. I had alot of problems with this on intercept.
     
  6. RubbishyUser

    RubbishyUser L7: Fancy Member

    Messages:
    414
    Positive Ratings:
    242
    Looking at your info on the func_nav_prerequisite, it reminded me of the fact that in your map, capturing bots stand still. This makes them extremely easy to snipe. Could moving the target of the second prerequisite slightly make them shuffle around a bit when they reach the point, as they do in mannhatten?

    EDIT: Oh, that might be what you meant in the 4th bullet point above.
     
    Last edited: Mar 30, 2014
  7. Digaag Wa Riz

    Digaag Wa Riz L3: Member

    Messages:
    121
    Positive Ratings:
    83
    I thought I'd mention something useful that I discovered while making an MvM map myself. If you create a mission (as opposed to a normal wave) with the objective as "sniper", you can still use different classes. However, because their mission is to act like snipers, they will use func_tfbot_hints meant as sniper spots. If you disable/enable different func_tfbot_hints then they will try to go to active ones. I used this method to create bots that patrol an area while completely ignoring the bomb.

    As a side note, the bots being subjected to this will amusingly use the "Negative" voice command randomly. I guess it's because they went to a hint that is no longer active? I can't help but chuckle seeing a soldier walk up to an area, say "Dammit!", then walk away.
     
  8. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    748
    For patrolling its not recommended to use the sniper hints. They are sniper hints for a reason. It would make the mission incapable of having normal snipers. And im not sure but they also might not be shooting at you while patrolling then.

    Instead the prerequisite is better since you can have 2 of them at the opposing sides. each having a target to the other. Using a selfnamed tag you can make only those bots behave on them. And since bots also can have tags to make them ignore the bomb you can still get the same behaviour.

    When using more prerequisites you can also make them go from A to B to C to D to A and loop.

    Using prerequisites you also can have multiple bots take the same path without having them randomly change the path while walking to an other section.

    However, if you realy want that behaviour you can still make those prerequisites use the whole map as trigger. It might be less efficient to do so though so that would only be required to be active for 1 second to at least trigger the active bots to change paths.
     
  9. Tumbolisu

    aa Tumbolisu  I ⌄ I 

    Messages:
    931
    Positive Ratings:
    895
    That is coded in Sniper-Bot behaviour. This affects normal Bots and MvM Bots. Every time a Sniper scopes in and cant find a target he will randomly do the "Negative" thing.
    You are telling a soldier that he is a sniper, so he will do the same.
     
  10. Digaag Wa Riz

    Digaag Wa Riz L3: Member

    Messages:
    121
    Positive Ratings:
    83
    The thing about the prereqs is that the bots continue on their path if they use them while combating the player is only secondary. They basically become mobile turrets that travel a fixed path. I'd like them to patrol but still be able to go after the player when they see fit, which the sniper hints allow them to do. But as you've stated, having normal snipers is impossible that way.

    EDIT: @Tumbolisu, that's weird. I never noticed the Heavies using the voice commands. Although they did spin up their miniguns, probably because they think they were supposed to scope in.
     
    Last edited: Sep 3, 2014
  11. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    748
    If you are using valve's gatebots they will definitely do that because they have "BehaviorModifiers push". That modifier makes them never ignore their objective. You might want to try "BehaviorModifiers Mobber" on them to overrule it, although i think these will make them ignore the objective entirely. Best would be to try to make your own gatebot (copy theirs and rename it - for example copy T_TFGateBot_Scout_Normal and rename it to T_TFGateBot_Scout_Normal_Mobber to keep it clear what the trait is of the variant) and remove the modifier and test if that will work.