So far, so good.

Early proofs of concept indicate this might be a viable option. Here are some of the hurdles ahead of me:

Trigger condition evaluation: I'm planning on using VB.NET as the language for trigger condition expressions. I've built a simple test that takes an arbitrary boolean expression, compiles it via CodeDOM into an in-memory assembly, and returns a delegate to invoke it with all the necessary information that will be required of the bot. This works well so far, but of course it remains to be seen how well it'll work in practice. I may change this to having the expression compiled into a System.Linq.Expression, which I could then compile into a delegate - I think that would be faster than the CodeDOM method I'm using now. Profiling will tell.

Dynamic state machines: Part of the system will be handling different states. I'm using states as a logical grouping of events for a common scenario. For example, a Fighter bot could have many states that it could be in at any one time; an out of combat state, an in-combat state, a dead state, and so on. Each of these states can have their own grouping of events, possibly having actions that force the machine to transition between states. I have some experience with state machines so this shouldn't be too much of a challenge.

Ability mapping and timing: Another vital part of the system is my Ability Mapping concept. Instead of having each user modify their scripts to include their character's own personal spells and combat arts, scripts will instead reference ability mappings. These mappings are then configured by the user to refer to one or more in-game abilities, each of which has its own cast, reuse, and duration timers. When a script action invokes the mapping, the system will use the first ability it's able to, according to its position in the mapping (top to bottom) and the status of its timers. This way, said Fighter bot can have a mapping called 'attack' that its user could have configured with all his character's single-target combat arts, so that every time that 'attack' mapping is invoked, one of those combat arts is used. I'm still conceptualizing this particular feature so any more detail would be speculation / brainstorming, which I will save for another post.

Configuration and UI: Of course, all of this complexity needs to be presented as simply as possible. I do not intend for people to manually edit XML in order to change these scripts, so I'll be building a script editing UI for that purpose. In addition, the UI will need to include a mapping editor, as well as a place for entering script-declared variables. All of these things will need to be data-aware, and some of them dynamically created. I've been debating with myself whether I want to use XAML and WPF for the UI, and while this sounds like it might be a good use of WPF, I still haven't taken the time to crest the learning wall, and with my current job situation I don't know if I want to take that time now.

There's more, but this is getting long already - I'll post again either tomorrow or the next day with more.