Having selected a text game as the easiest demonstration, we need a way for the developer to see what’s happening and a method to incorporate the AI.
Building up automation is easiest if it’s a gradual process rather than a software development goal of “all the pieces have to work before you can actually test anything”. With this in mind, it’s tempting to start by using existing tools to test approaches manually first and incrementally build small pieces of automation.
For displaying information and gradually building up from manual play to automated runs there are many suitable existing MUD clients. Examples include:
- CMUD, from zuggsoft.com, is not free but is excellent and powerful. The only limitation is that it’s Windows based, but WINE users under Linux and users of emulators under MacOS have reported success.
- mushclient, from Gammon Software, is open source and also quite powerful though the UI is less intuitive than CMUD’s for many users.
- Mudlet, also open source, is multiplatform. Actually compiling it is rather difficult and it has some significant limitations, but for end users who just use the existing install packages it can be good.
- Tintin and derivatives are powerful but somewhat less accessible for new users because of their pure text interface and command line heritage and are more difficult to work with as GUI’s for multiple simultaneous sessions
Most of these clients are powerful enough to build substantial automation entirely within the client. Most use internal scripting languages which are not designed for complex automation, particularly modular and object-oriented approaches. Long time users might object to that statement but I would clarify with something like “Yes, your favorite client has features in that are which make it much better than [other client] but how about when compared to Python?”
Several support languages popular within the gaming community such as Lua, but the environments each piece of script runs in are somewhat limited as are the facilities for large scale persistent data stores. CMUD and Mudlet provide some facilities in this latter area.
For this reason, for this exercise we will take advantage of client capabilities but also build custom facilities in a language of our choice. Existing text games generally use protocols built on telnet or ssh, and can therefore be enhanced with the use of a proxy which can then include whatever features or existing libraries we desire to include.
Key for our bot development effort are:
- efficient and native database access- a large amount of data about various aspects of the world must be maintained and constantly accessed
- enhanced pattern matching, such as command and response or color patterns
The basic building blocks will be:
- a local telnet proxy server – handle connections and add functionality beyond what standard mud clients provide. The user can connect a favored client to the proxy. Using the proxy avoids writing a friendly GUI telnet client from scratch.
- sqlite – one of the most widely used sql databases in the world, with packages available to run in all widespread programming languages
- lua – portable and minimalist scripting language popular in the gaming community
- extensions to regular expressions – what we need is somewhere between regexes and a full lexer/parser which handles arbitrary grammars. It’s important for us to be able to recognize patterns such as sending a command matching a regex pattern and receiving response(s) matching patterns, possibly multi-line and also containing unrelated ‘noise’ data before and after the response.