Yay! Milestone passed!

[RoKFenris]

If you continue on that track I wouldn't doubt you will be ready to handle Arthas when he finally shows up (if you bother to get 7 more accounts)

Not exactly sure what you mean about pooling, but if it's similar to my concerns about matching, in each update, each mob in sight against the filter that lists all mobs I need to do something about for either quest or achievement purposes (depending on the character this list can grow to over a hundred names to match against), my take on that problem was to store a "tracked" enum on each mob with three possible values: notProcessed, tracked, notTracked. New mobs get the notProcessed value, as well as setting every mob to notProcessed whenever any filter change (which only happens when I get quests or complete objectives); then when updating mob data, if the mob has not been processed (and already have a name, sometimes they can go a long way without getting named) I set it to either tracked or notTracked.

[amadmonk]

Right! I only pull info like names on-demand. Unfortunately, my poll routines have to look for certain "named" mobs (e.g. Keristrasza) to know when to activate various "encounters," so I effectively have to get that information every tick. The cost of getting a single name is effectively zero; the cost of getting the name of every mob every tick is NOT, especially when you're doing this in twenty different individual loops.

The alternative is to be more event-driven; IE, process a mob only when there's a new mob, otherwise just "mark up" the existing mob with whatever is important ("he's a boss!" or "always cure his debuffs" or whatever). In the long run, I think that event-driven is a more robust architecture, because it allows you to delay processing for as long as possible. Unfortunately, for me, it would be a re-architect to go completely event-driven.

What I've discovered is that a simple rate-limiter function on most of the "for every single object, do XXX" routines has allowed me to dodge hefty CPU fines. Of course, the fact that my dev/test box is insanely beefy helps, but still.

What I've been toying with today at work is a better inter-bot communication system. Right now, the bots chat over the addon party channel. The problem with this is that it's a bit of a giveaway if Blizz ever decides to monitor this chatter. A shared socket for a hive-mind might be enough.

Edit: was able to take away 99% of the chatter, so my paranoia is satisfied. Still debating a better inter-bot chat mechanism. Anyone got a good 7-bit encoding mechanism?

[namreeb]

I find this thread very interesting, and may before too long become very relevant to me.

I'm curious if you can elaborate some on what members you have in your encounter function. The general design issue here is how to design a structure that is sufficiently powerful/useful to handle the subtle nuances of each encounter, yet be general enough to make things like storing them and writing the code for it nice and clean.

[amadmonk]

Right now, my encounter objects only have two members -- a function to get the preferred target (overriding the default "monte carlo" target selection mechanism), and a generic "per tick" function for any other critical per-frame behavior, including "stay out of the fire" mechanics, "must remove" debuffs, the "we can dance if we want to" move for Keristrasza, and so on.

The idea is that I just use the normal class hierarchy to represent encounters, so if I need one generic set of behaviors, and another specialized set for instances, I can derive the instance behavior from the generic behavior, and so on.

Simple is better.

[namreeb]

I see. Very elegant approach. What about spell/action rotation(s)? Do you just have a NextAction() with a series of conditions? Do you definite it in some sort of shorthand and have code to interpolate the specifics?

[amadmonk]

No, I don't bother with rotations. For the most part, rotations are designed to achieve a specific goal -- keep diseases up 100% on DK's, etc. So instead of trying to hard-code in a rotation (which means I'd need to be stateful about which step I'm in), I just look at the underlying goals -- must keep diseases up, etc. -- and then cast spells to achieve those goals. If disease X is missing and "spell which produces X" is ready, cast that spell. Etc.

From some rough tests with targeting dummies, this method is *at least* as high in DPS output as a hardcoded rotation (usually higher, since it doesn't have human error that misses a cooldown or something), and it removes all the tricky logic of transitioning from state to state to state (and needing to "reset" if a state gets screwed up or an emergency occurs, etc.)

Again -- simple is better You'd be amazed at how effective a simple set of rules can be.

Edit: one thing that's missing from my bot (for now) is positional element -- getting behind the boss. Most of my test bots have been either ranged dps (where you don't care) or tanks/healers (where it doesn't matter). I'm working on coding up a "get behind the mob" routine tonight. It should dovetail nicely with my "stay out of the fire" routines.

[namreeb]

Isn't that just a question of implementation? You're still using states, you're just letting WoW keep track of them for you (ie the disease debuffs in your example).

I have been thinking about how to do this in the context of a leveling bot, where due to training/level cap requirements, certain spells may not be available. It's obviously do-able, but I can see it getting very ugly very fast, and my priest can just keep spamming smite all the way to 80! =)

[amadmonk]

Well, sure, but I'm also letting WoW keep track of my casting status, position, health, mana, experience, inventory, velocity, and quests. Letting it keep track of buff/debuff states seemed like a no-brainer

All snarkiness aside, my motto is "the less work I do, the less things can break" -- and it's worked very well for me.

WRT your leveling bot, it's not too hard, you program in optimal behaviors and graceful fallbacks. Meaning that at some sane point (on load, also maybe when detecing talent changes, etc.) you scan and record what spells are available. And then in your behaviors, you say "if I have spell X, cast it... else if I have spell Y, cast it... else..." and so on.

[EmilyStrange]

a function to get the preferred target (overriding the default "monte carlo" target selection mechanism),

I am curious to know what predictor(s) you are using on your Monte Carlo simulation to target a mob. Is it just name? Or are you using threat and DPS? Or something else?

[EmilyStrange]

With regard to your inter-bot communication, I am curious to know why you chose that solution.

Do you run all clients on the same machine? Why not just make a single bot that controls all clients simultaneously. Effectively, the solution that I chose. I may eventually convert my "bot" to use RPC so that a bot client can reside on multiple PCs with multiple game clients and a bot server controls them all, but it is very low priority on my list of "things to accomplish" simply I use my bot for explicitly mulit-boxing. I have a "main" that I control explicitly, and then a swarm of helpers to make sure the tank stays alive, the DPS is in full rotation, etc.

With regard to architecture, I have the concept of a "party", an explicit AI, which has its own goals, evaluators, and behaviours. It is the "party" that decides which character gets healed, and which character does the healing. It is the "party" that determines whether to explore, fight or recuperate. This party AI runs on its own thread. The party AI understands about the concept of a leader, a healer, a tank, DPS, etc.

Then I have the concept of a "player", an explicit AI for each player character (a local player) that also has goals, evaluators and behaviours. Player AI can send messages back up to the party AI, which can then forward the message on to the other player AI if it is necessary. Messages are sent via the standard producer/consumer event system built-in to .NET.

Because there is a concept of an "all-powerful party character" all of the player characters can be orchestrated to perform a group of actions very easily. This is useful when performing a round-robin type of action such as for debuffing, shielding, stunning, spell interrupting, etc.

Also, when looting, I keep it on FFA when playing alone or with my room-mate and her hunter, and it is funny to watch my characters rush off and gather up the loot from various kills and then run over to my room-mate's hunter and /yell "Treasure!" and "For you!" at her. (Reference to the game Overlord)

[amadmonk]

Much simpler: which mob is closest. For the default, that's it! Sad, eh?

But as my fraps showed, for non-elite, non-instance encounters, it's surprisingly effective.

There were a COUPLE of special cases; for instance for a lock's life drain, I'd pick the mob that was in range with the highest health (in the thought that I'd get the most bang for the buck by draining healthier critters). Similarly, for soul drain, I'd only pick mobs that were in range below XXX health.

Simple, but effective (for non-instance encounters).

[amadmonk]

With regard to your inter-bot communication, I am curious to know why you chose that solution.

Do you run all clients on the same machine? Why not just make a single bot that controls all clients simultaneously. Effectively, the solution that I chose. I may eventually convert my "bot" to use RPC so that a bot client can reside on multiple PCs with multiple game clients and a bot server controls them all, but it is very low priority on my list of "things to accomplish" simply I use my bot for explicitly mulit-boxing. I have a "main" that I control explicitly, and then a swarm of helpers to make sure the tank stays alive, the DPS is in full rotation, etc.

With regard to architecture, I have the concept of a "party", an explicit AI, which has its own goals, evaluators, and behaviours. It is the "party" that decides which character gets healed, and which character does the healing. It is the "party" that determines whether to explore, fight or recuperate. This party AI runs on its own thread. The party AI understands about the concept of a leader, a healer, a tank, DPS, etc.

Then I have the concept of a "player", an explicit AI for each player character (a local player) that also has goals, evaluators and behaviours. Player AI can send messages back up to the party AI, which can then forward the message on to the other player AI if it is necessary. Messages are sent via the standard producer/consumer event system built-in to .NET.

Because there is a concept of an "all-powerful party character" all of the player characters can be orchestrated to perform a group of actions very easily. This is useful when performing a round-robin type of action such as for debuffing, shielding, stunning, spell interrupting, etc.

Also, when looting, I keep it on FFA when playing alone or with my room-mate and her hunter, and it is funny to watch my characters rush off and gather up the loot from various kills and then run over to my room-mate's hunter and /yell "Treasure!" and "For you!" at her. (Reference to the game Overlord)

You know, I went round and round and round about this. Hive-mind or emergent behavior?

I went with the latter -- emergent group behavior, where each player has his own "goals" etc. -- because it was simpler to code and less fragile; any one bot could go offline and the group would adjust accordingly.

The only real problem with the emergent behavior philosophy (and don't get me wrong; I do have central command and control ability through various addon messages, etc.) are situations where there must be a "leader" who "calls the shots." I don't mean things like target selection -- this can be done independently by simply using the same selection code for each individual bot. Rather, it's simpler things like "who should each bot follow?" and so on. I could have -- and contemplated -- creating some kind of voting mechanism to select the leader, but I decided on a much simpler course of action: I simply use whoever is party leader as bot leader. Of course this has its own issues (when the party leader isn't a bot, or when the bots aren't in a party), but my use cases all fit nicely with the solution.

Now I'm not saying that my architecture is perfect; I'm finding flaws every day. But I'm happy with the design choice of focusing more on emergent group behavior (through appropriate rules design) than trying to "top-down" architect the whole thing. The code for each individual bot is much, much simpler, and so far the performance has been stellar.

The only really hard thing about letting behavior emerge from group interactions is a human thing -- it's trusting that a simple set of rules applied to a group of bots will produce the "right" outcome. But for that, test, test, test -- you may be pleasantly surprised!

I'd be interested in hearing your counter-arguments, however.

[amadmonk]

Oh, one more quick question. Since it sounds like you're using .Net remoting or WCF to "chat" between your bots, how did you deal with network fragility? What's the master "service" -- an app that lives outside any game, or one chosen bot? Can the group "self-heal" if this external service goes down or hangs (or otherwise stops listening to net events)?

Very curious about this, because networking and bot architecture were things I've spent a LOT of cycles thinking over. I wanted inter-bot communication outside of the client (for a lot of reasons including paranoia, performance, and the rate-limiter that Blizz builds into addon chat), but there were always fragility issues. One benefit of using addon chat is that I can literally run my bots ANYWHERE. As long as addon chat gets through, they'll talk. Now that I have my addon chat encrypted (and mildly compressed, although compressing into 7bit is non-trivial), it seems relatively effective.

[namreeb]

I am nowhere near being ready for this, but I had always envisioned a stand-alone app whose sole purpose was controlling the network. I presume it would run on udp.

[EmilyStrange]

Perhaps I wasn't clear in my earlier post. A single process with multiple threads controls all of the game clients.

The messages that each player and the party send are all contained within a single application, and that application, at this time, exists on a single machine. All game clients are run on that same machine too.

So the network fragility is a non-issue because AFAIK WCF/remoting does not hit the network, nor even the standard loopback adapater, if it detects that the same process (but not the same thread) dispatched the message to itself, effectively circumventing any "network hit" or perceived fragility. This obviously does not hold true if I were to separate the bots onto multiple machines, but I will address that issue if I ever get around to going that route. On a LAN, it shouldn't really matter about latency within the context of the game, ~100ms to pass a message, even with the massive overhead of remoting, compared to a text-encoded message being sent via UDP from a game client to the game server and back to another game client? It's night and day.

Each player character has its own AI running on a separate thread, each player character AI also gets a thread for executing behaviours -- though I am thinking of removing this -- and also each player character AI gets a thread for monitoring status, descriptor flags, etc, which currently runs at 5Hz but this frequency could be reduced too.

The party AI gets its own thread too, for running evaluators, processing the goal tree/stack-of-stacks, and sundry other things.

Then there is the user interface thread, which handles the hotkeys that the actual human player can press if they want to handle the fight, buff a passing player, moving around in the world, etc.

I also have a thread for each game client, to monitor connection status, in-game status, crashed status.

And finally a thread for monitoring all of the game clients, watching for new game clients starting up, and so on.

It might sound complicated, but it really isn't. It is just a clean solution with clear separation, in to multiple projects, of what is a "game client," what is a "Warcraft game client," what is the AI, and what is the application/user-interface. In the same solution I have three separate "bot" projects
* Multiboxer -- ~90% human control of a main player character with elements of a simple AI to handle group functions, following, looting, healing, etc.
* Cypher -- 0% human control, single player character level grinding bot
* Matrix -- ~10% human control of a group of bots used for grinding instances, walk up to where you want to fight, hit the button, wait for the bots to kill everything and loot it, rinse and repeat.

I'd like to add more autonomy to the party, simply for the mental exercise, but I really got in to creating this bot framework to make me a more effective multi-boxer when running instances, or battlegrounds.