Design

[Kalradia]

We need to come up with a design for the bot. There are a few things we need to consider. The first thing is that while the intent may be to create a bot to run the 'Wild Speculation' event, we need it to be open-ended enough to also handle future events.

My current ideas (just throwing them down to be on paper - will update this as we go):

• Database of users to track basic information
• Leaderboards

Bre should be able to pop into a channel and tell the bot to open/lock voting, so that she can make sure no one can vote just before the announcement comes. She should also be able to then call a command to reward all users under a specific vote choice, complete with a confirmation to make sure there was no typo or anything.

Please do expand upon my ideas here and add your own thoughts.

[Samalot]

Yeah, I agree with the above

My general thoughts on the database tables would be (just placeholder names for now)

(Table) Event

• id
• start datetime
• end datetime
• name

(Table) Option

• id
• event id
• name

(Table) Entry

• id
• event id
• option id
• discord username / uid
• bool - was winner?

[Samalot]

and then depending on if you want to support multiple concurrent events, there may need to be some tweaking around how we identify the active event

[psylvyn]

Under the Event, I would suggest:

Description (nvarchar(max))
Maybe an image, as we have had teaser images for the events up to now.

Potentially descriptions and images for Options as well.

For Entry, I would separate out the winner into an EntryWinner table with a constraint, to help enforce a single winner and separate out that detail from the Entry table. Of course all of these are suggestions.

[Kalradia]

Awesome! Perhaps on the Event table we should include the ids of the winners. Should the Entry table include the discord username, or refer to another table with a reference to their user data?

Also - we may need an additional table to contain a user's data. Something like an internal id, the user's uid, and their total points.

[Kalradia]

Let's open a new thread for the DB design, for whoever wishes to oversee that. Can always update the main post with the latest info.

[psylvyn]

I assume the uid will never change, so we should stick to that in case a user changes their username during or after an event.

Maybe a User table that just has the uid, and a UserToEvent table that joins the two, with the username the user had at the end of the event. Could even have the "winner" bool on this table instead of a separate Winner table as I suggested earlier.

[Kalradia]

Maybe a User table that just has the uid, and a UserToEvent table that joins the two, with the username the user had at the end of the event. Could even have the "winner" bool on this table instead of a separate Winner table as I suggested earlier.

I worry that this would overcomplicate it, to save the username at the end of the event. There should be a way to grab the current username from the uid. I wonder if we even need the middle table.

[psylvyn]

Possibly not. I'll create a db diagram during this meeting and play around with it.

[psylvyn]

I imagine something like this. Total points a user has would be winning entries point_max added together. used_points or points_used I guess would make more sense, would allow for us to use those points as a currency and keep around how much you have spent.

[Kalradia]

This is good progress. I hadn't thought about 'using' the points - I'd have to ask Bre if Synty would have anything they'd like to use those points for, because initially it was only for the prize they give out to the winners manually. This would be more of a management system for them to administer the events.

I am a little worried about the relationship between an event and the options. Ideally, options would always persist between runs of the speculation events, but could be removed or added by an admin at any time.

[psylvyn]

They could be "created" as part of a template as the event is created. Usually I only do soft deletes as deleting an option that happened to be chosen by a user in the entry table would violate that constraint. In other words, a field on the option that just denotes it is "deleted".

I could see benefits of either situation. I usually design large, extensible systems so my thoughts always go in that direction.

[psylvyn]

Something like this would be for a shared event options pool