|
||
---|---|---|
.vscode | ||
app | ||
.gitignore | ||
CHANGELOG.md | ||
COMMANDS.md | ||
docker-compose.yml | ||
LICENSE | ||
README.md | ||
resources.md | ||
TODO.md |
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)
BOT_MAINTAINER_ID=(Discord user ID of the person maintaining the bot to enable debug features.)
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
| | | `-- control.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
| |-- debug
| | `-- debug.py
| |-- 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.