projectmoon
/
tenebrous-dicebot
1
0
Fork 1
Code Issues 12 Pull Requests 1 Projects Releases 10 Wiki Activity

Update 'Roadmap'

projectmoon 2020-11-30 20:22:54 +00:00
parent 93aec5ed34
commit 7640f238d6
1 changed files with 36 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
Roadmap.md

@ -1,53 +1,37 @@
# Roadmap
This is the roadmap for functionality to be added to the dicebot. Features are listed in order of planned implementation, mostly because at this state of development, the bigger features require implementation of less exciting groundwork.
## Immediate
What is currently upcoming.
| Feature | Description | Depends on |
| --------------- | --------------- | --------------- |
| **Room State Management** | Bot keeps track of metadata relating to rooms it's in. | N/A |
| **Private Commands** | Manage all bot functionality from a private room | Room State Management |
### Room State Management
Room state management involves the dice bot keeping track of what rooms it is in and what users are in them. This feature is 100% invisible to the end user, but is a necessary prerequisite for managing the dicebot in a direct message.
* One-time sync of the dicebot's current rooms into the database (sort of a migration, but technically not?)
* When a user joins or leaves a room, add/remove them to/from a users list for the room.
* Probably useful to maintain a two-way relation: room -> list of users, user -> list of rooms.
This feature will be further expanded as necessary.
Database implementation:
* New keyspace: `rooms`.
* `rooms|by_user|<username>` = `list of user's rooms`.
* `rooms|list` = `list of dicebot's rooms`.
### Private Commands
Allow the user to manage the dicebot in a direct message. The user should be able to tell the bot which room to manage, and any commands executed in the direct message would be applied to the given room (until the user switches to another room). Only certain commands would be allowed in the direct message, namely anything involved with creating or modifying data (variables, etc).
This will require some internal changes:
* Dicebot must now be aware of what room a user is managing in a direct message. This may be the first introduction of a proper state struct for users in the database. Possibly new keyspace `state`, with just a key name of username.
* Commands must be aware of if they are being executed in a direct message or a regular room. Probably easiest to add this property to the `Context` object.
## Intermediate
Things that are easier to implement, but not yet scheduled.
| Feature | Description | Depends on |
| --------------- | --------------- | --------------- |
| **Resource Counting** | Creation of counters that can go up and down. System agnostic. | N/A |
| **CofD Game Management** | Management of slightly complex CofD things like health. | N/A |
## Future
Things in the far future that require a lot of groundwork or other features to be finished first.
| Feature | Description | Depends on |
| --------------- | --------------- | --------------- |
# Roadmap
This is the roadmap for functionality to be added to the dicebot. Features are listed in order of planned implementation, mostly because at this state of development, the bigger features require implementation of less exciting groundwork.
## Immediate
What is currently upcoming.
| Feature | Description | Depends on |
| --------------- | --------------- | --------------- |
| **Private Commands** | Manage all bot functionality from a private room | Room State Management |
### Private Commands
Allow the user to manage the dicebot in a direct message. The user should be able to tell the bot which room to manage, and any commands executed in the direct message would be applied to the given room (until the user switches to another room). Only certain commands would be allowed in the direct message, namely anything involved with creating or modifying data (variables, etc).
This will require some internal changes:
* Dicebot must now be aware of what room a user is managing in a direct message. This may be the first introduction of a proper state struct for users in the database. Possibly new keyspace `state`, with just a key name of username.
* Commands must be aware of if they are being executed in a direct message or a regular room. Probably easiest to add this property to the `Context` object.
## Intermediate
Things that are easier to implement, but not yet scheduled.
| Feature | Description | Depends on |
| --------------- | --------------- | --------------- |
| **Resource Counting** | Creation of counters that can go up and down. System agnostic. | N/A |
| **CofD Game Management** | Management of slightly complex CofD things like health. | N/A |
## Future
Things in the far future that require a lot of groundwork or other features to be finished first.
| Feature | Description | Depends on |
| --------------- | --------------- | --------------- |
| **Character Sheet Integration** | Integrate with an external online character sheet service. | Existence of said service, many dice bot features. |