The source is available at http://tinyurl.com/Gambot with hosting kindly provided by the awesome folks at the Wesnoth UMC Dev project. It does partially serve Wesnoth after-all.
At some point I'd like to get technical about it, but I think for now all I can manage is a quick overview of my philosophy.
The main feature that one must have for a multichannel IRC bot is live updating and testing. You want to be able to update the bot without having to restart it. The more frequently you update the bot the more apparent this need becomes.
The main reason is that it takes forever to connect to IRC. You would waste a lot of time if you had to go through this reconnection every single time. At around twenty to thirty seconds between when you start the process to when the bot is actually in all of its channels you'd be wasting one out of every three hours of work you put in.
Secondly you spam all the channels that the bot is in with quit messages. If you're constantly tweaking the bot, and must restart each time, that's a ton of QUITs and JOINs.
This is pretty much the central theme to Gambot's design. Every single ounce of code that goes into the project is geared towards making it extremely easy to change while the bot it is running.
This process starts with segmentation. The bots code is very fractured. It's not just one script that you run, edit, and reload. Mainly there is a connection script and a processing script. The connection script connects to IRC and then sends the raw messages to the processing script and then logs the message. The processing script processes the message (more on that below) and sends its response back to the connection script. The connection script logs the response and sends it to the IRC server.
That's all that the connection script is in charge of; logging messages, and sending messages. Because it is the main script, any changes to it require a restart. Therefor, we want it to handle as little as possible. Once that little bit is done, we may never have to touch that file again.
Since the processing script is loaded anew for each individual message, any changes to it instantly take affect If you notice a typo in the bots response to a message, you can edit the processor to fix that typo and as soon as you hit save that change is now in effect. This allows you to debug and tweak while the bot is live. I generally even go so far as to add brand new features to the bot while it's running, and nobody even notices.
But there is even further fracturing in the processing script now. I turned every feature/command into a plugin file. These plugins are loaded and run every time the processing script is. This also means if you have multiple bots running the same processor, or two processors with the same command in them (for example, every bot should respond to CTCP VERSION) you only have one file to update.
Since the bot is hosted with SVN this has another benefit. If my bot is running, and I update the plugin "hug.pm" anyone else running a bot merely has to SVN update and that change is live on their bot as well.
0 comments:
Post a Comment