Gaming Command

[mchrisgm-backup]

Main command The user can type "?!lobby {name of lobby} {maximum number of people} {optional: password}" to create a private channel with the specified name ( {name of lobby} ) and assign it to the newly created role. Then, the bot will add the role to the user which will be able to view the private text channel. (Note: the bot will also create a voice channel, which will only be joinable by people that have the required role).

Lobbies Furthermore, other users can view the currently active lobbies (see Expiration) by typing "?!lobbies", where the bot will list all the currently active lobbies, both full and not. These lobbies are going to be saved in a text (or any other format) file so that the bot can keep track of them even if it crashes or was shuts down for any reason.

Exit A user already in a lobby will not be able to join another lobby before exiting the current one. Hence, they have to leave by typing: "?!leavelobby". This command will automatically remove his lobby role which will make him able to join another lobby (see Lobbies).

Expiration All lobbies will be deleted after 12 hours of their creation by saving the time they should be deleted inside of the lobby list text file. The bot, with every update, will check if the lobby is near deletion or has already passed the time of expected deletion and take the appropriate actions to delete the role and the channels regarding the specific lobby. Also, a lobby will be automatically deleted if all users leave the lobby.

Securing lobby with password Users might want to create a private gaming session. They can achieve that by locking the lobby with a specific password. The password will be stored as a hash in the lobby list file, and will be retrieved every time another user wants to join the channel (see Main command).

[IlleQuiProgrammat]

I think this sounds like a good idea but we should probably move this over to the database as it’s faster and easier to manage than a huge textfile.. I suppose that depends on the number of concurrent lobbies though. Although hashes are best practices do you not think that it’s a bit over the top? And where will this command be called? DMs I presume? (So the password is hidden from other users).

[mchrisgm-backup]

The database does sound like a good idea, although i haven’t seen the structure of it. Hashes are a good practice in general and having the passwords stored as hashes ensures more privacy. The user will be able to enter the command in a normal bot-commands channel and when it gets registered as a new lobby by the bot, the bot will delete the original message and respond with a “Lobby {name of lobby} has been created by {user} “. Like that, the password will not be shown to anyone reading the chat.

[IlleQuiProgrammat]

There’s just one issue with people who use modified discord clients and keep deleted messages (if they’ve been downloaded) that’s my only concern.

[mchrisgm-backup]

Oh ok, i see, then the other way of doing it is create it as public (without a password), and lock it when you are inside the channel with a command like "?!lock {password}". This will only give access to the people joining the lobby and not anyone else to see the password.

[IlleQuiProgrammat]

First thing lock would have to be a subcommand and perhaps an invite system would work better? So ?!lobby invite [uid/gid] and to make it public have ?!lobby invite *.

[mchrisgm-backup]

The command needs to contain both the number of users, the name and then the invite solution you proposed. My go on this is that you can have 2 commands, one that creates the lobby and one that locks it. “?!lock {password} “ will only work when you are already in a lobby, so i don’t see why this is a problem.

[IlleQuiProgrammat]

Is it necessary to lock down the number of users? And theoretically some plugins can get the channel messages before the channel is hidden by the bot and read the password there. I suppose a solution would be to have bot-generated passwords sent to the channel after it had been locked by the bot. We can also do ?!lobby create or check whether it’s a number but lock is already a command that’s the main reason why.

[mchrisgm-backup]

A bot generated command would be the best i think. Also, the number of users in a lobby should be locked because in games such as Counter Strike, you only get teams of 5 players. This means that you avoid all the other users that want to join your voice chat and annoy you.

[IlleQuiProgrammat]

Yeah I suppose people annoying you is fair. The next phase is planning the finicky bits so DB Schema and stuff. 👍

[Jet132]

Ok, I've read through the issue and comments and I have some opinion.

• We'll definitely store the data in the database because then we can easily create a backup (with replication), don't need to make a new system and also as anAlius said it's much faster
• There already exists a lock command so just ?!lock itself isn't possible. The solution would be making subcommands
• Because the other features also have one command with subcommands I would also do it here

If we do subcommands I suggest the following:

• ?!lobby create {name of lobby} {maximum number of people} (the shorthand would be leaving the create out)
• ?!lobby leave to leave a lobby
• ?!lobby lock [password] to lock the lobby with a password or just entirely
• ?!lobby unlock
• ?!lobby list to list all lobbies

We also need to think about permissions. We probably should just make the lobby creator be able to look the lobby and maybe there should be a kick or ban feature. Question is, how complex does the permission system need to be?

[mchrisgm-backup]

The lobby owner should probably only have a ?!lobby kick {user} command, although if you don't want someone to join the current session(lobby), you could change the password by re-locking the lobby with a new password by doing ?!lobby lock {new password} again . The subcommands is a good idea and the database is a must. How do we proceed with the database plan?