Even the most complicated gaming automation is, at a basic level, a combination of very small trigger and response reflexes.
In the mid 1990’s, widely distributed mud clients were created which made the simplest form of this automation easy:
When [pattern from server] is seen, send [response].
An example might be a fantasy game player character which provides services such as casting a spell.
When the server sends this character text such as “Bob says ‘please heal me’”, the client is instructed to send a message back to the server like “cast ‘heal’ Bob”.
The syntax for instructing the client to do that could resemble:
#TRIGGER {^%w says ‘please heal me’$} {cast ‘heal’ %1}
Two important things to note are that the syntax to describe text patterns is nonstandard (not regex) and that this approach is designed to match responses to input (a knee-jerk reflex), not to use input to update state of the game and to take action based on the evolving state.
The most obvious way to switch directions and track state within the confines of an existing client is to update variables instead of sending responses as the action in those types of triggers and to periodically examine state and determine what command(s) to send by triggering prompt lines and/or a periodic alarm type trigger.
That leaves two significant problems unsolved:
- Handling complex patterns and multi-line information
- managing state in this way results in many, possibly hard to maintain and debug, variables and state
#1 is a limitation of the pattern matching languages available in most clients and regex engines but there are workarounds. #2 is a much larger problem as it becomes difficult to build modular components and to test them.