Hunter bot, simplified.

Everyone, thank Tasha (my wife). She said something to me the other day that really got me going on the hunter bot, and actually inspired me to write some real code. She said, "Just write it."

I've been spending so much time thinking about the hithertoo's and whyfor's about it that I haven't touched a single line of relevant code. My biggest problem is and has always been a combination of over-thinking and over-planning. Many of my project concepts are huge ideas - my web game that'll never be built is a prime example of this. It's so large that it would require a team of people as dedicated to it as I am in order to actually happen, but that's a pipe dream.

So in following Tasha's advice, I've managed to get a very simple prototype hunter bot working. To do this, I've opted for a far simpler strategy: instead of following a walkpath, the user selects a 'camp spot', and the system brings viable targets to the camp spot to kill them.

I decided to do this for one primary reason: it'll help me get something out the door. Features can always be added later - with the Workflow system I wrote for Autocrat, this is easy as pie, once I've figured out the logic. But for now, I'd like to get something out to everyone whose waited so long for it - and the camp-bot is it. I'll have a beta version available very soon.

Progress thus far

Truth be told, at this point, progress is slow going. I've been doing a lot of work for my friend Brian, and as it pays more immediately than Macrocrafter work I have to focus on that. It's been calming down of late (unfortunately) so that should afford me more time to work on this stuff.

I've been slowly organizing the work I need to do on this system. So far I've divided it up into several main components that I'll need to build before I can start stitching them together.

Also I've decided to skip the intermediate step and just make a damned hunter bot out of this, so I'll also need to integrate targeting and walking into the system.

Anyway - one of those systems includes a VB.NET compiler, as I mentioned before. All I need to do with this is to take my proof of concept code and make a proper system out of it - something reusable. I'm going to add it to Autocrat. I'll also need a timer that can produce timing events in 150ms intervals - that's the interval at which I'm going to have the system pull down updated EQ2 data. Any of the .NET timers should be capable of doing this so I'm not too worried here. I'm also going to need a state machine engine that can be configured via XML - this will be responsible for persisting the user-editable 'scripts' that will make up the brains of the bot itself. I've got a schema all figured up; all that remains is actually putting the work into it - and then I get to build a UI on top of it, because the last thing I want to require is for people (or myself) to have to hand-edit XML to get it to work.

Coupled with the timer is going to be a system for describing stateful property changes. Here's the problem: my bot engine is going to be evaluating event trigger expressions every 150ms. The expressions are boolean, so they'll be testing data based on the content of the current tick's EQ2 properties. If an expression looks similar to: "Return EQ2.GroupMember(2).Health < 50" - then when group member 2's health drops below 50%, it will trigger the event. This is desired - BUT it will ALSO trigger once every 150ms tick until group member 2's health rises to or above 50. This is NOT desired, so I need a way to expose the concept of state changes: for example, I'd like to rewrite the same expression as: "Return EQ2.GroupMember(2).Health.DroppedBelow(50)". That would return True if, and only if, the previous tick's Health was at or above 50 AND the current tick's Health is below 50.

So I'll need to figure out an efficient system of encapsulating old state and exposing it via these state descriptors. I'm sure I'll figure it out.

But you can see why I've been making slow progress here. =) In between kids, contract work, looking for full-time work, EQ2 updates, and other life, I don't have much time for experimentation, which is a shame.

Big plans.

So I hinted, last time, about some big plans I have for a new EQ2 project. I think I may have gone off the deep end a bit with this one, but I'm thinking I might have a winner.

People have been begging for a hunter bot for a while now, and while I could make one, I don't think I could do it justice. EQ2 is a very complex beast, with combat being especially complex. Despite what many think, it's *not* as simple as walking around, targeting stuff, and mashing buttons until you're done. When you play EQ2, and you fight things, you create little strategies out of the abilities you're given, and considering that there are 24 classes and umpteen billion ways of customizing (AA, etc), there are far too many of these strategies to bake in to the software.

So, in order to appeal to everyone, I'm going to stop working on the hunter bot, and start working on my new project, a group assistant (or you could call it a two-box helper).

This will, however, be like no ordinary two-box helper. My system will be completely customizable, down to every last detail, thanks to a custom rules engine I plan to build. I'm scrapping my DSL idea for this - it works, but I don't want to trust it for a production build, not yet - and going with an XML rules system with a visual designer on top of it.

This will not be a general purpose scripting application. The rules engine will support the project's only goal - to make two-boxing (or three, four, five, twenty, etc) a hands-off endeavor.

But I have ulterior motives as well... This application will facilitate a rules-based system upon which the final hunter-bot can be built. Once the rules engine is in place, and all the wiring is complete, it'll be go time.

More details to come later. =)

Progress

To cut to the chase - progress on the new harvest/hunter bot is going very slow. Obviously I can't work on it while at work - sort of a conflict of interest when I'm supposed to be working on work stuff while at work - so my availability is limited. Weekends are limited as well, since because I work a 'real job' I only get to really see the kids during the weekends, and because the last thing I want to do during my days off is work...

More technically, I'm blocked on a couple issues. Since I'm merging a harvest bot and a hunter bot together, there are some technical difficulties to work out - they have to share targeting systems, navigation systems, and some settings which, from a UI perspective, will have to be separated yet united somehow... As far as the engine itself goes - well, because I'm using my workflow system, it's actually not going to be as hard as it seems.

I've been using the workflows as logical separations between the various systems involved. One workflow for hunter, one for harvester, and one for navigation. Targeting is too simple a process for an entire workflow - a single workitem will be sufficient. Finally, to tie everything together, a master workflow responsible for coordinating the efforts of these disparate (yet united) tasks.

The master workflow will be responsible for invoking the navigation sub-workflow, as well as the harvester and hunter workflows. All workitems for these sub-workflows are yielded to the workflow runner, so the entire hierarchy of workflows is flattened to a sequential list as its run - as it should be.

Where I'm being held up is in how to handle tasks that should be shared by all these workflows, but must happen separately in each of them. For example, stuck checking / handling. This sounds like a navigation concern, and it is, but it's also a concern for harvesting and hunting - in particular, moving from the walkpath to a node / mob, and moving back to the walkpath. Both of those tasks are prone to dealing with the stuck issue, so I'll need to have stuck checking there as well. Should I create another workflow - a stuck check workflow - that's responsible for detecting and dealing with the issue? If so, how do I invoke it while ensuring the harvest, hunter, and navigation workflows are ignorant of it? That's one of the goals for workflows - keeping the sub-workflows ignorant to each other and letting the master workflow do the coordination.

Maybe that is the answer. I can inspect the workitems given to me from the Hunter and Harvest workflows before I yield them - maybe I can check the specifics, and if they're in their navigation phases I can interleave the stuck checking in there with them. Hah - yes, I'll do it. =) Sometimes just talking through a problem can lead you to a solution - I'll give it a try when I get home.

Well, anyway - I need to get back to work. Lunch break only lasts so long...