Page 1 of 12 1 2 3 11 ... LastLast
Results 1 to 10 of 113

Thread: Dota 2 Bot Full-Overwrite Project

  1. #1
    Basic Member
    Join Date
    Dec 2016

    Dota 2 Bot Full-Overwrite Project

    This is a full bot over-write implementation. This means that for each hero
    (eventually all of them, but we start with small sample) we will implement
    a bot_<heroName>.lua file with an implementation of the Think() function.

    This is a WORK IN PROGRESS. I share it in the hope that other developers will
    find it useful and potentially contribute by requesting pull commits against
    this code base building a better community bot framework.

    The code representing this bot codebase is largely comprised of work of the
    author and many contributors of the "Dota 2 Bot Scripting Forums" which can be
    found here:

    Code Layout:
    The design intention was to largely leverage the concept of class-based
    inheritance as existant in Object Oriented Programming languagues, but in LUA.
    To that end, there exists a "decision_tree.lua" base class that loosely
    defines the behavior of every bot we make by the virtue of the fact that all
    bot_<heroName>.lua files will derive off of it. This allows the hero-specific
    files to only over-load those decision_tree.lua functions that they want the
    specific hero to handle differently, while keeping other aspects of bot
    behavior untouched.

    Current Files:
    * - this file

    * constants.lua - constants that allow for easy use of our defined values
    across all files

    * utility.lua - many utility functions that are used by other files which
    implement generic logic and behaviors of the bots

    * hero_selection.lua - basic and very simple hero selection and lane
    assignment for the bots. The lane assignment is only useful for not
    implemented bot_<heroName>s as the ones that are implemented have
    their lane assignment controlled by the ROLE they are assigned. This
    whole file will eventually be scrapped I think for a better counter-
    picker implementation based on hero choices made by opposing team. For
    now it's just a stepping stool to get other stuff working.

    * role.lua - this assigns roles to bots based on a not-fully filled out
    concept of what hero belongs in what role. Roles are categorized into
    7 buckets: HardCarry, Mid, Offlane, SemiSupport, HardSupport, Jungler,
    and Roamer. This file implements a brute-force technique for minimizing
    role overlap by attempting to not assign more than one hero to a bucket.
    I was going to implement the Hungarian Algorithm to do this, but brute-
    forcing 80,000 possibilities if faster than doing advanced matrix math.
    The concept of roles flows down into laning for purposes of last hitting
    and denying.

    * enemy_data.lua - this was my attempt to globally track information about
    all of our enemies based on metered updates by our bots as we have
    vision of the heroes. Intention here is be able to predict ganks and
    enemy hero rotations based on noticing the disappearance of the heros
    from vision while knowing what the last values of their location, health,
    mana, etc. where. I am aware that the API exposes GetLastSeenLocation()
    and GetTimeSinceLastSeen() - however these don't provide the values like
    mana & health which will help us know probabilistic reasons for why the
    bots disappeared (e.g., low health/mana -> probably went to heal at shrine
    or fountain -> don't be as worried). Currently the information is just
    stored and not used in any way. TO BE FIXED! I wasn't sure how Valve calls
    multi-bot over-writes so I made it atomic via locks. I honestly think
    that our bots are called by a single thread though and we won't have race
    conditions every present.

    * global_hero_data.lua - this is a global table that allows for per-hero
    persistant storage of variables. It is saved based on the hero's playerID.
    If a variable is retrieved via getHeroVar(<strNameOfVar>) that does not
    exist, nil is returned.

    * decision_tree.lua - this is a start... there will be lots of things that
    need to be fixed here and actually implemented (many place holders).
    For now laning is in and some item-swapping when dead and rudimentary
    retreat functionality (read below) are implemented. This is the BIG
    KAHUNA of the majority of the bot logic. Larger concepts, like laning,
    will have their own files and states and be tied to this file and
    transitioned between based on the bot's foremost ACTION in actionQueue.
    In a way I'm trying to re-implement what I think Valve's Think() is doing,
    but I have no clue really, so I'm doing what I think should be done. It
    would be very appreciated and useful to have more people fill placeholder
    functions out.

    * laning_generic.lua - an implementation for laning based on role. Some
    aspects are still completely missing like: neutral pulling, camp stacking,
    support enemy hero zoning for safelane, etc. Additionally, while last
    hitting and denying seem "ok" for ranged heroes, they are rather bad for
    melee. Need to improve and change logic based on utility.lua->IsMelee()
    in the future.

    * retreat_generic.lua - draft implementation of retreating when taking damage
    from tower, creeps, or heroes/overall. There are BUGS in here with logic
    as I see bots say they are RETREATING but sometimes they just stand in place.

    * item_usage.lua - this implements basic and generic use of items. It is very
    limited for now to use of clarity, salve, bottle, TPs, arcane boots (not
    efficiently -> doesn't care about allies being in range). Needs to be
    largely implemented still.

    * generic_item_purchase.lua - this is a generic class for all hero-specific
    item purchase files (e.g., item_purchase_lina.lua) that actually does all
    the work of buying the item when appropriate. It is named as such to not
    interfere with "item_purchase_generic.lua" which if exists in the bots/
    will over-ride all bot purchases that don't have a named file for them
    resulting in no items being bought for "ANY" bots that don't have a specific
    hero-named lua file for item purchasing present. The hero-specific LUA files
    now only need to define the appropriate ROLE specific table for item purchase
    order (i.e., Mid, HardCarry, Support, etc).

    * bot_<heroName>.lua - three exist for now - Lina, Viper and Antimage. Look,
    they are hard-coded implmenetations for now that don't build according
    to the game state, but rather to a hardcoded ordering. This will need to
    be largely re-written in an intelligent fashion eventually so it makes
    choices that respond to what's happening in the game and based on the
    makeup of enemy heroes. These heroes require supporting lua files to
    really function: item_purchase_<heroName>.lua and ability_usage_<heroName>.lua
    These exist for Lina only. The existing hero files were created to demo
    some of the possibilities of decision_tree function over-loading.

    * other files are in support of bot_<heroName> files

    Lots - we need fighting logic, rune logic, ward logic, tower attack logic,
    ally defend logic, tower defend logic, bot 5-man assembly logic, roshan logic, etc.
    We need lots of item_purchasing for heroes and lots more heroes.

    Some FIXMEs are commented in code - I add them as a tag to get back to with ideas.

    Check the Issue Tracker for things I'm planning on doing next or what others in the community are doing.
    Last edited by nostrademous; 02-10-2017 at 04:39 PM.

  2. #2
    Basic Member
    Join Date
    Dec 2016
    FYI - I have a full-time job, 2 kids, a wife and other pet projects. I will continue to work on this and accept any contributions and pushes that make sense and are explained; however, it might take a day here or there (usually less than 6 hrs) before I get to it.

  3. #3
    Basic Member
    Join Date
    Dec 2016
    Looks like a big and pro project.
    But for my painful experience, I doubt that if it is possible to finish within finite time.
    Do you have a schedule for this project?

  4. #4
    Basic Member
    Join Date
    Dec 2016
    Quote Originally Posted by lenlrx View Post
    Looks like a big and pro project.
    But for my painful experience, I doubt that if it is possible to finish within finite time.
    Do you have a schedule for this project?
    I don't yet. As I just wrote up the huge and now need to do some real-work related costing for a program the company is bidding. It might be a big project, but if there is community involvement it will get done fast. I saw how much you and Platinum_Dota2 got done relatively quickly

    My next things I want is (and feel free anyone to do these while I am busy today):
    1) figure out why the hell the bots hate the "ranged" creep so much and often will go and right click it once before doing normal laning last-hit behavior?
    2) fix last-hitting for melee chars
    3) teach the bots to right-click the tower when they determine they should push
    4) add code for using Faerie Fire and Tangos

  5. #5
    Basic Member
    Join Date
    Dec 2016
    Updated code with better use of Anti-Mage's blink for retreat purposes. I now do:
    -- same name for bot AM and QoP, "tooltip_range" for "riki_blink_strike"
    		local value = 0.03
    		if (utils.GetHeroName(npcBot) == "antimage" or utils.GetHeroName(npcBot) == "queen_of_pain") then
    			value = retreatAbility:GetSpecialValueInt("blink_range")
    			-- below I test how far in units is a single 0.01 move in terms of GetLocationAlongLane()
    			local scale = utils.GetDistance(GetLocationAlongLane(npcBot.CurLane, 0.5), GetLocationAlongLane(npcBot.CurLane, 0.49))
    			value = (value / scale)*0.01 - 0.001
    			nextmove = GetLocationAlongLane(npcBot.RetreatLane, Max(npcBot.RetreatPos-value, 0.0))
    			npcBot:Action_UseAbilityOnLocation(retreatAbility, nextmove)
    Fixed retreat code based on Tower or Creep damage to not be more important than generic health-based retreat code.

  6. #6
    Basic Member
    Join Date
    Dec 2016
    Pushed two larger updates to codebase recently.

    - bots no longer randomly hit the ranged enemy creep at random times
    - largely improved last-hitting/denying for melee heroes
    - hopefully bots will no longer push with creep wave ignoring presence of enemy towers and die
    - bots should right click enemy towers now when they believe they should push lane
    - AntiMage has learned various conditions of when to use his Ult
    - We will consume our Faerie Fire if we think we are about to die... just in case it helps us survive
    - We will use our tangos (this code not 100% how I want it... it will eat a tree, but only if we are next to it by chance, we don't path to tree yet)

    - Retreat code still needs improvement
    - Fight Enemy Code needs to be implemented
    - Fix tango usage

    Folks feel free to get engages if you can and improve the code base by submitting git commits against it

  7. #7
    Basic Member
    Join Date
    Dec 2016
    - Pushed larger update that moved my bastardized overload of npcBot members for storage which then required a load/save function between GetBot() calls (aka per Think() frame) into global_hero_data.lua which is a large table indexed by PlayerID() that has stored values of all variables you want to persist.
    - Revamped how item purchasing works to make the creation of new item purchasing tables for new heroes much easier. There is now a generic purchasing system that does all the work of buying items. The hero-specific files now just need to specific the ROLE specific item purchase ordering (as in - what should I buy if I'm Mid or HardCarry, or Support, etc.)

    Check the Issue Tracker for things I'm planning on doing next or what others in the community are doing.

  8. #8
    Basic Member
    Join Date
    Dec 2016
    We now have a jungling Bloodseeker that loves to jungle fairly efficiently until the end of the game added by a community member. He will kill you if you get in his way though.

  9. #9
    So, these AIs play human-like?

  10. #10
    Basic Member
    Join Date
    Dec 2016
    Quote Originally Posted by DreadedGhoul575 View Post
    So, these AIs play human-like?
    At some MMRs yes

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts