Yay! Milestone passed!

[amadmonk]

Interesting. So your in-process code (assuming you're not just doing everything via mem-reading and key injection, etc.) is just a stub to execute commands and read info?

I'm liking this architecture. In many ways it's a good deal simpler than my own, at least partially because all the really "crashy" parts live outside of the WoW process.

As to top-down or bottom-up AI, that's a philosophical argument and both have merits, I think (my architecture is actually a combination of both). But I like your "lightweight injection" technique. I may see if I can adapt it to my own bots. Hmm, if I make my GameObjects MarshalByRef objects I can just pass them directly over the wire...

As to latency: yeah, you're right. Local comm (even WCF, even if you were using HttpBinding!) is light years faster than round-tripping some UDP. I just went with what (seemed) simple.

The only down side I can see to your design is that it effectively requires a central process to be running. But that's not a huge downside, and my design has similar (if not greater) limitations.

Edit: Hmm... Have to think about this a bit. I don't want a zillion CAO WoWObjects floating around, and I don't want to have to do a singleton service with a million tiny "getXXX" methods on it. Gotta think about how I'd architect this w/WCF.

Edit edit: Blah, this is why I didn't bother with WCF. Bidirectional bindings are a major pain. Maybe I'll just use two one directional bindings. A "phone home" and "per process" binding.

[EmilyStrange]

You don't have to use WCF, you can just use regular old producer/consumer events, so long as you make them thread safe.

If I were to turn my framework into a multi-node distributed system I would look at having a centralized application that did all the heavy thinking, with a small RPC client on each workstation node talking back to it. I could even make it so that each client could assume control if the main server were to go down, but I think that is overkill. I am not looking for an enterprise level application with failover capability. It's just a game bot.

I went with the top-down coercive AI approach, with only semi-autonomous goals, because of two design decisions:

1) The most important goal. The concept of the physical human player was tantamount to my design philosophy. This was to be a multi-boxing helper, rather than a full-fledged bot. The bot aspects simply "fell out" of the framework. The physical human player replaces the party evaluators. The physical human player says "I am the leader, I'm attacking this target, I'm doing a consecrate, I need a debuff on one of the DPS (I don't care who does it, just get it done), player character three needs healing (I don't care which of the two healers does it, just do it), interrupt that spell caster, someone off-tank the adds, heal me now! adds are down, give me full-rotation DPS whilst assisting on my target." The physical human player supplies the "what" in the what/why/how of the evaluators/goals/behaviours triumvirate. It was the principle design philosophy when I started building the application. It also explains why my application defines around 30 hotkeys and works with the Logitech G13 gaming pad. I want the physical human player to make the high-level decisions and the AI figures out how to carry it out.

2) I've used that same AI system for grouping behaviour within a popular RTS game -- though of course the group size and group makeup was more dynamic, and instead of five units with 30 abilities, you have 50 units with 2 and 3 abilities each.

I agree that emergent vs coercive is a philosophical decision. There is no "right way" of doing this.

Creating a distributed RPC server & client is an almost trivial exercise in .NET. My work on various casino games taught me that. Ordinarily I would advocate not using RPC/WCF/CORBA/remoting or any other heavyweight technology for low-latency/high-traffic game applications, but this isn't a game. It is an application that runs, at, at most, 5Hz or 10Hz. Message time and response don't need to be hard or soft real-time because 1) You're not building an enterprise level application capable of graceful failure whilst simultaneously handling tens of thousands of requests per second with real money on the line and 2) most MMORPG games have a definite "tick" to the game universe measured on the order of seconds because of various factors, the predominant one being the cost of server bandwidth for the game publisher, so stressing about response time when it stays under the human perceivable threshold of latency is a real non-issue.

With regard to injection, my multiboxer helper sits outside of the main game process, no endscene hooking at this time, simply because I have not gotten around to it. I toy with the idea each time I review my code, but still haven't sat down and figured out how it would alter my architecture nor what benefit it would convey. I am sure there are many positives, but the impact is greater than the benefit (at this time). I played around with endscene hooking in a toy project just to get a better understanding of how it works and thought it was neat, but I am still on the fence over using it in my application.

My solution consists of:
* Blackmagic -- handles reading and writing process memory. Thanks to Shynd for this library.
* Caronte -- handles my experiments in pathing. Thanks to the original authors and updates for this library.
* ManagedWinapi – handles hotkeys, wraps the WIN32 API for renaming/repositioning/resizing native windows, and offers a lot of other stuff that makes it cleanly hidden from the .NET developer.
* Voodoo -- understands the concept of a game client, expects there to be an "object manager", a local player character, game objects, game units, game player, containers, items, and so forth, provides a generic, abstract set of classes for various behaviours such as recuperation, fighting, exploring, looting, moving, etc. Has a game client manager that wrangles all of the game clients. Has the ability to be taken and easily repurposed to other MMORPG games because I don't expect WoW to be the only MMORPG I ever play -- I used to play Everquest, I expect to play something else in five years time.
* Warcraft Vodoo -- game specific project that inherits from Voodoo. Concrete classes for behaviours -- use CTM for the movement behaviour and loot behaviour. Understands how to retrieve the player's name, health, mana, etc.
Smarts – non-game specific, exceptionally generic, main AI module. Centralised AI, party and player management. Understands the concept of a party, a leader and player characters. Contains concrete and abstract classes for evaluators (what), goals (why), and behaviours (how). Some goals, such as recuperate (drink & eat), form up on leader, attack target, heal target, are applicable to many games. Similarly the same is true for behaviours and evaluators.
Warcraft Smarts – concrete classes that inherit from Smarts for this specific game. Most of the differences are in the goals and behaviours covering game and character class specific issues such as the difference between how a paladin is played to how a holy priest is played.
Cypher – Single player grinding/leveling bot. Mostly user-interface for creating profiles. It kills, it loots, it patrols. It kills, it loots, it patrols. It kills, it loots, it patrols. It feels no remorse. It feels no pity. It does not have any sense of morals. It cannot be reasoned with. It cannot be bargained with. It posts scathing messages on forums. And it most definitely, cannot be stopped. Yeah, no, nobody we know.
Matrix – The multi-player, semi-player controlled bot that was done as an experiment. Much of the code is just copy and pasted directly from the Cypher project. Least developed of the three “bot” projects.
Multiboxer – My favourite project and why I started this in the first place. Offers a simple, clean user-interface with hotkeys and preferences for playing multiple characters at once, because, believe it or not, I like playing the game, but I don’t like most PUGs and I don’t have time to dedicate to a raiding guild.

Without arguing the philosophical in-process/out-of-process points which have been done to death on these forums, I merely read/write memory directly. I wrote the application to operate on the assumption that an attached game client is hostile, i.e. memory will move, objects will be garbage collected, values will change without warning, memory writes will be rejected due to a race condition, and so on. I’ve written code to directly call non-destructive functions directly in the game client, from outside of the process, and for the most part, it works, but didn’t offer enough advantage (yet) over not calling the functions and just reading the memory directly.

Edit: I do want to point out that I feel my bot project is the least developed of all the ones I have read about on these discussion forums. I really feel I am far behind the curve in terms of what mine does when I look at the screenshots and videos on the screenshot threads.

[amadmonk]

Well, I'm toying with making a WCF out-of-process hive mind at the moment. The only problem is that I'm not willing to go completely OOP (I've written a LOT of code that just wouldn't be feasible out of process).

However, a little remoting shim should work... Just trying to figure out how to integrate serialization/MBRO with my current code base.

Edit: after investigation, WCF is a horrorshow for what I want. Basically I either have to rewrite my WoW object hierarchy to be exposed as a set of services --or-- I'd have to do a LOT of not-really-supported plumbing to get the equivalent of MarshalByRefObject's to work w/WCF.

The flip side is that .Net remoting is fragile, fragile, fragile, especially when dealing with client-activated objects.

This, in a nutshell, is why I never went down the path of the hive mind; you're either forced to go completely out-of-process (which I don't want to do for various reasons), or you have to put up with some nasty and fragile network protocols. To make this work for me would be a complete rewrite. *sigh*

[nitrogrlie]

I used to think that hooking D3D was gonne be somewhat-challenging and put it off too, until today. It turned out to be extremely easy actually with a simple trick. Instead of looking for the D3D9 device pointer, create your own inside of an injected DLL in the WoW process space. When you do that you can hook the virtual functions you are interested in based off of your D3D9 device and because it inherits from the same objects as WoW's D3D9 device the pointer to the VFT of your's and their device points to the same location. So VFT hooks to your device will also affect WoW's device.

Below is the code to do this:

typedef HRESULT ( WINAPI * tEndScene )( IDirect3DDevice9 * pThis );
tEndScene oEndScene = 0;
typedef HRESULT ( WINAPI * tReset )( IDirect3DDevice9 * pDevice, void * pPresentationParameters );
tReset oReset = 0;

void HookDevice( IDirect3DDevice9 * pDevice, HWND hFocusWindow )
{
	// Hook EndScene
	oEndScene = *(tEndScene*)( *(DWORD*)pDevice + 0xA8 );
	YOUR_DETOUR_LIB( &(PVOID&)oEndScene, (PBYTE)hook_EndScene, "EndScene" );

	// Hook Reset
	oReset = *(tReset*)( *(DWORD*)pDevice +  0x40 );
	YOUR_DETOUR_LIB( &(PVOID&)oReset, (PBYTE)hook_Reset, "Reset" );

	// Hook Anything else you like...
}

void InitDevice( IDirect3D9 * pD3D, HWND hWindow, IDirect3DDevice9 ** ppDevice, D3DPRESENT_PARAMETERS d3dPP )
{
	d3dPP.BackBufferCount = 1;
	d3dPP.MultiSampleType = D3DMULTISAMPLE_NONE;
	d3dPP.SwapEffect = D3DSWAPEFFECT_DISCARD;
	d3dPP.hDeviceWindow = hWindow;
	d3dPP.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
	d3dPP.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
	d3dPP.BackBufferFormat = D3DFMT_R5G6B5;
	d3dPP.Windowed = TRUE;

	pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWindow, D3DCREATE_HARDWARE_VERTEXPROCESSING, &d3dPP, ppDevice );

	HookDevice( *ppDevice, hWindow );
}

void HookD3D()
{
	D3DPRESENT_PARAMETERS d3dPP;
	IDirect3DDevice9 * pDevice = 0;
	HWND hWindow = 0;

	IDirect3D9 * pD3D = Direct3DCreate9( D3D_SDK_VERSION );

	hWindow = FindWindow(NULL, TEXT("World of Warcraft") ); 

	if( !hWindow ) {
		MessageBox(0, "Failed to obtain WoW hWindow", "Error", 0);
	}

	memset( &d3dPP, 0, sizeof( D3DPRESENT_PARAMETERS ) );
	InitDevice( pD3D, hWindow, &pDevice, d3dPP );
}

Then after your bot-framework initializes just call HookD3D().

Obviously you will need to write you own hook_* functions.

Credits:
Amadmonk - gave me the idea that this would work
Bobbysing - confirmed these concepts when I discussed it with him

[amadmonk]

Credits:
Amadmonk - gave me the idea that this would work
Bobbysing - confirmed these concepts when I discussed it with him

Credits for the D3D hook go to others (Apoc, Nesox, Cypher, Kynox... I'm looking at you...)

[amadmonk]

Well, I went through a couple of hours of soul-searching today, looking (back) into WCF and remoting and contemplating bot architectures, and the conclusion I came up with is:

My design is better :P Here's why:

While one attractive aspect of the "out-of-process" bot is the lowering of the attack profile (for bans and whatnot), you still have to hit all the most important things out-of-process (object list scans, CTM, vfunc invocations, etc.), so your attack profile isn't THAT much smaller. TLDR translation: the OOP bot isn't THAT much safer, assuming that all else is equal (you don't distribute the code, etc.).

Another aspect that's attractive is the idea of a central mind, but really -- why? One piece of code that says "attack mob X" to ten different bots versus ten separate pieces of code saying "attack mob X" individually *achieve exactly the same result*, and without the single point of failure. All that really has to be centralized is the *data*, not the behavior; simply running the same code in all the bots will sync up behavior, so as long as I have another mechanism (networking) for synching any data that's not obvious from in-game scans, I should be good.

The networking is just a horrorshow unless you want to go partially out-of-process. Once your in-proc stuff gets complex enough that you need persistent objects to maintain and track state, you're basically blocked from effectively/easily remoting out your bot. Trust me, I've looked at WCF and .Net remoting from every possible angle, and it's just not realistic. Either you run in-process (and accept the risks and benefits of doing that), or you run out of process. The one architecture that DOESN'T make sense is a hybrid, because you end up with the weaknesses of both worlds, and few of the strengths or benefits.

For inter-bot communication, I really don't need anything more complex than a socket server, which is likely all I'll write. Or, really, now that my in-game chat is effective (secure and compressed), it may be sufficient. 500ms latency would be too much for a per-frame behavior, but the kinds of things I communicate are not per-frame behaviors (that's all taken care of in the bot itself); they're "meta decisions" (you're the boss, attack this, stand down, don't loot!).

So I really do think that for what I want -- which, interestingly, is similar to your goals, a multibox helper bot -- my architecture makes more sense.

[EmilyStrange]

I am not saying that my architecture or solution is better than yours. There are many ways to skin a cat, this just happens to be the way I chose to do it. I just happened to pick the one way I knew would work, for my goals, that I had used in the past and was familiar with.

With regards to attack profile, in-process, out-of-process, injection, memory writing, calling functions directly -- anything that Blizzard deems inappropriate is subject to account termination. Have the wrong web page open? Have Visual Studio open? If Blizzard decides to track that, and decides that too many people are cheating with that application/web page open, you're gone.

Everyone that writes a game hack knows the risks. Or they should.

Yes, there are less risky behaviours than others, any risks taken need to be calculated, but if Blizzard wants you gone, that's it.

Hive mind or distributed system or simple message passing state machines written in Lua, there is no "one ideal solution." Just solutions, I was merely trying to present my solution to the problem to generate thoughtful discussion. I understand now that it wasn't appreciated.

[EmilyStrange]

I used to think that hooking D3D was gonne be somewhat-challenging and put it off too, until today. It turned out to be extremely easy actually with a simple trick. Instead of looking for the D3D9 device pointer, create your own inside of an injected DLL in the WoW process space. When you do that you can hook the virtual functions you

A very good and informative post.

But also... I am not using any object virtual function hooking at this time, not because I do not know how, but because the benefits are not enough to justify rewriting portions of my framework at this time. I've toyed with code, and the idea, but the system I have works for me, and I don't see any point in fixing what isn't, at this time, broken.

[namreeb]

I was merely trying to present my solution to the problem to generate thoughtful discussion. I understand now that it wasn't appreciated.

I did not get that impression at all from anything amadmonk or anyone else said. I have been following very intently this thread and wishing I had something meaningful to contribute. Alas, I am still waiting.

So, to be clear, I appreciate very much the discussion you two are having. A breath of fresh air around here.

[amadmonk]

I am not saying that my architecture or solution is better than yours. There are many ways to skin a cat, this just happens to be the way I chose to do it. I just happened to pick the one way I knew would work, for my goals, that I had used in the past and was familiar with.

With regards to attack profile, in-process, out-of-process, injection, memory writing, calling functions directly -- anything that Blizzard deems inappropriate is subject to account termination. Have the wrong web page open? Have Visual Studio open? If Blizzard decides to track that, and decides that too many people are cheating with that application/web page open, you're gone.

Everyone that writes a game hack knows the risks. Or they should.

Yes, there are less risky behaviours than others, any risks taken need to be calculated, but if Blizzard wants you gone, that's it.

Hive mind or distributed system or simple message passing state machines written in Lua, there is no "one ideal solution." Just solutions, I was merely trying to present my solution to the problem to generate thoughtful discussion. I understand now that it wasn't appreciated.

I didn't intend to be combative. I was really curious about the strengths and weaknesses of your design. From what I can tell, the two fundamental differences are the out-of-process nature of your group bot, and the top-down decision making. All I was trying to point out is that (a) I don't find out-of-process to be very compelling (I have a long history here at MMOwned coming over to the "dark side" of injection, trust me! ) and (b) "top-down" AI design I find to be less flexible and adaptable than group behaviors based on emergent properties.

I really am not trying to slam your bot design, honest. If it works well for you, more power -- as you say, there's more than one way to skin a cat. I just need to periodically re-visit my own design choices. Part of it is an agile mindset, I think... the desire to constantly refactor sometimes forces me to the realization that the current architecture is, for me, close to optimal.

So, please don't take my questioning -- and my final conclusion not to adopt your design choices -- personally or as some attempt to slam you. I was earnestly interested in how you're doing things. If my bot were not already 99% in-process, I might very well consider an architecture similar to your own for my own bot.

[Apoc]

Ring-0 proxies > your setups. Srsly.

[namreeb]

Ring-0 proxies > your setups. Srsly.

Don't mind him. That is Apoc-eeze for he doesn't understand what you're saying.

[Apoc]

Don't mind him. That is Apoc-eeze for he doesn't understand what you're saying.

Actually; I understand all of it. But I have my own methods for communication between 'clients'. So I won't bother to make it any more 'confusing' than it is already.

[nitrogrlie]

Another aspect that's attractive is the idea of a central mind, but really -- why? One piece of code that says "attack mob X" to ten different bots versus ten separate pieces of code saying "attack mob X" individually *achieve exactly the same result*, and without the single point of failure. All that really has to be centralized is the *data*, not the behavior; simply running the same code in all the bots will sync up behavior, so as long as I have another mechanism (networking) for synching any data that's not obvious from in-game scans, I should be good.

That's all good and dandy for what I would call an assist-bot setup (either human with helpers or 1 smart bot assisted by numerous smart bots) but I would argue that you need more centralized control for bots that required coordinated efforts.

For example, IMHO, if I were to write bots for Arena PvP, the coordination of CC-chains, target switches, dispel/interrupt rotations, etc. could not "effectively" be achieved without a centralized AI algorithm. I quoted effectively because I mean it from a do-ability perspective as well as a performance perspective.

Let's explore one of these coordination efforts a bit further: CC-chains. So you enter an arena and your bots makes individual decisions, rather then group decision from a centralized source. You have coded logic for which targets are the "CC" targets in specific team setups so each individual bot knows it. The question then is which bot cast the spell to CC? How is that information shared so two+ bots don't try to CC at the same time and offset the effects effectively wasting them? The answer is that they could share what they each will do as individuals to all the other individuals and each bot would have logic routines for handling information it is provided from others. It is essentially the same as humans sharing information over Ventrillo saying "I've got the next interrupt on Target XYZ". The other way to do this, is to have a single centralized intelligence that knows what's need to be done and instructs each bot what his next (or next few) actions should be. I feel like this solution is better as it removes the necessity of extra code for handling inter-bot communication, removes complexity from the design, results in faster execution (due to less code and any lag introduced in inter-bot communication). Just my thoughts.

[EmilyStrange]

@amadmonk: I apologise if I took your words to heart a little more than I should have.

Designing true emergent behaviour, without signaling, i.e. message passing between bots, and making it as efficient as possible, is damn difficult to do on anything more complex than a few trivial examples, e.g. boids, herds, FPS bots, etc.

The moment you add in signaling between cohesive units, i.e. groups of bots, you get a huge boost in capability and efficiency. But many would then argue, endlessly, far worse than any in-process/out-of-process argument on these forums, that the emergent behaviour is no longer "pure." And many of those arguers will go to extreme lengths to find "pure" examples in nature where emergent behaviour exists without signaling -- there are a few identified cases, but they exist (mostly) in isolation, usually at species interaction boundaries.

Single centralized AI? Or emergent behaviour with signaling? Or coordinated cohesive groups, i.e. dynamic centralization of AI within a cohesive group of autonomous units that only exists for the duration of the group or the duration of the event, e.g. a fight? There is no one best solution, only solutions that are "different."

With regard to injection or memory reading/writing, or whatever we're calling it today, I, personally, cannot see much difference between the two. Both techniques get the job done, though I would say that injection is probably a marginally better solution if you want to interact at a more fundamental level with the game client, e.g. drawing stuff directly on the game client's screen or invoking certain (destructive) functionality of the game client.