Geas Server Bot

This is a bot I wrote to manage the Discord server for Geas, the Edinburgh University Table-Top Role-Playing Society, during our move to an on-line format. The bot is designed to create and manage channels and roles for gaming groups in order to replicate our in-person pitch events on a Discord space as far as possible. The bot is written in Python, and was the first Python coding project I wrote, so it has a special place in my heart. The first version I committed to the repository is version 2.1, and I previously handled the version control manually, so migrating old versions to Git would be a pain. Version 3 was the second major upgrade, taking advantage of some of the recent changes to the Discord API.

Setup

The Bot is dockerised and uses docker-compose for deployment, so it is fairly straightforward to deploy an instance of. Clone the repository, install Docker and Docker Compose, navigate to the root directory (that contains the docker-compose.yml file), and use docker-compose up -d to set up and run the bot. The bot runs on one Docker container with the instance of the app as well as storage for its data and configuration. The bot uses docker-compose to mount an external volume to allow for persisting file storage and easy migration. It no longer uses a database engine because it never really benefitted from the various database manipulation tools in the earlier version, and was not worth the complexity.

The bot authenticates using an API key, which I have kept private in a .env file that I have not uploaded to the repository. In order to set up your own instance of the bot, you will need to provide the following values in a .env file in the root directory.

You will also need this database to set up a username and password for the MongoDB database. The specific username and password don't matter as the bot refers back to the environment variable when authenticating.

The following is the template for the .env file, with the variable names as are referenced in the bot's code: .env file:

BOT_TOKEN=(API token for the production version of the bot.)
TEST_TOKEN=(API token for any test instance.)
CONFIG=(Path to config file. The bot defaults to './data/config.yml' if not provided.)
DATA=(Path to data file. The bot defaults to './data/data.yml' if not provided.)
LOOKUP=(Path to the game role lookup file. The bot defaults to './data/lookup.yml' if not provided.)
GM=(Path to the GM lookup file. The bot defaults to './data/gm.yml' if not provided.)
CATEGORIES=(Path to the channel category lookup file. The bot defaults to './data/categories.yml' if not provided.)
PITCHES=(Path to the pitches data file. The bot defaults to './data/pitches.yml' if not provided.)
BOT_VERSION=(verson string)

The correct API keys need to be entered in the environment variables in the .env file, and for a copy of this file to be placed in the root and the app directories.

N.B.: When the bot is first run, it is configured to log in as the Test Bot, and not the main Geas Server Bot, as a safety measure. To change this, navigate to the last line of the file bot.py and change the line:

client.run(os.getenv('TEST_TOKEN'))

to

client.run(os.getenv('BOT_TOKEN'))

in order for to authenticate as the correct bot.

File Structure

|-- app
|   |-- .env
|   |-- bot.py
|   |-- cogs
|   |   |-- botcommands
|   |   |   `-- prefix.py
|   |   |-- controlcommands
|   |   |   `-- debug.py
|   |   |-- events
|   |   |   |-- on_command_error.py
|   |   |   |-- on_connect.py
|   |   |   |-- on_guild_channel_delete.py
|   |   |   |-- on_guild_join.py
|   |   |   |-- on_guild_remove.py
|   |   |   |-- on_guild_role_create.py
|   |   |   |-- on_guild_role_delete.py
|   |   |   |-- on_guild_role_update.py
|   |   |   |-- on_guild_update.py
|   |   |   |-- on_message.py
|   |   |   |-- on_ready.py
|   |   |   `-- secondary
|   |   |       `-- pitch_listener.py
|   |   |-- membership
|   |   |   |-- membership_verification.py
|   |   |   `-- restriction_listener.py
|   |   `-- slashcommands
|   |       |-- config.py
|   |       `-- secondary
|   |           |-- edit_membership.py
|   |           |-- game_create.py
|   |           |-- game_management.py
|   |           |-- manipulate_timeslots.py
|   |           |-- pitch.py
|   |           `-- player_commands.py
|   |-- data
|   |   |-- .gitkeep
|   |   |-- categories.yml
|   |   |-- config_blueprint.yml
|   |   |-- config.yml
|   |   |-- data.yml
|   |   |-- gm.yml
|   |   `-- lookup.yml
|   |-- Dockerfile
|   `-- requirements.txt
|-- CHANGELOG.md
|-- COMMANDS.md
|-- docker-compse.yml
|-- LICENSE
|-- README.md
|-- resources.md
`-- TODO.md

The COMMANDS.md file gives a list of all the commands the Bot uses, as well as a reference to the various cogs or base commands that are associated with them. The code for the command should be housed in the respective files within the file tree.

Data Structure

The bot holds data in two .yml files, config.yml for client configurations for each guild it is in and data.yml to hold the actual data regarding game and channel set-up. I was considering merging them into one file, but given how different the two concerns were I ended up splitting the files. I had initially condsiders a .ini file for the configuration settings and .json for the data, but I decided to use .yml for both just to avoid unnecessary complexity.

config.yml Structure

This tree gives the list of various keys for the .yml dictionary as well as the types of different data expected. The entire configuration file is essentially a dictionary with other dictionaries, strings, integers, and lists as values. All values in the dictionary are referenced first by a string of the guild id integer. Remember to convert the guild ID to strings during several operations, and be careful to compare like for like in any logics.

guild id string:
  channels:
    help: int
    mod: int
    signup: int
  configured: bool
  membership:
  - role id int
  name: str
  notifications:
    help: bool
    signup: bpp;
  owner: owner id int
  prefix: '-' by default
  roles:
    admin:
    - role id int
    bot:
    committee:
    newcomer:
    returning_player:
    student:
  timeslots:
    key: name

data.yml Structure

Just like above, the data.yml file is also a dictionary of dictionaries that is indexed by a string of the guild id. It stores only the relevant data necessary for the code to function. It only holds, for instance, ID numbers rather than user handles, Discord discriminators, or names.

guild id string:
  timeslot:
    role:
      category: category id int
      current_players: int
      header_message: message id int
      game_title: str
      gm: gm role id int
      max_players: int
      min_players: int
      platform: str
      role: role id int
      system: str
      text_channel: channel id int

Other Data Files

In addition to the above data file, the bot also uses storage in additional reference files to quickly look up values when needed for its various functions. The purpose of these lookup files is more to act as dictionaries facilitating arbitrary look-ups of key information when required. They are not intended to act as storage. Most of these lookup files are not particularly readable because they have raw values without informative keys. They are constructed and manipulated in tandem with the core data files.

In the Future

Restructure command execution using global event listeners

As it stands, there is a conundrum with the Bot: any kind of manual interaction to manipulate roles or categories will cause conflicts to emerge between the Bot's data and the guild settings. In order for the bot to be adaptable, and to respond to user interactions, it will need event listeners for things like channel, role, or category changes/creation/depetion, etc. Having such listeners will cause a circularity between the Bot's edit actions, which would then trigger the listener. There is currently no way of having an exception for the Bot's edits.

To reconcile this, the bot would need to work such that the command process that modified games only acted upon the roles, which would then trigger the event listeners to synchronise these changes with the categories, and subsequently the data. Having the bot edit the data in the main command process would mean that there would be conflicts with the simuntaneous execution of parallel threads.

This works for individual commands, but it breaks down when trying to use the purge command because of conflicts causedb by simultaneous changes to the data files. Programming around this will need a further layer of complexity, involving flags checking for R/W operations and a time-out.

Membership sign up performance issues

I have set the member verification prompt to use a global listener to avoid a situation where it creates several backlogged processes when multiple people post sign-ups at the same time. This should also mean that the sign-up prompts should persist over reboots. The best possible way of setting this up is probably using functions to dynamically set up and remove component call-backs. Also components do not need to all have unique names, just unique names in the message they are part of.