pacoccino
commented
3 years ago @peth-yursick @hammadj
Closed pacoccino closed 3 years ago
pacoccino
commented
3 years ago @peth-yursick @hammadj
peth-yursick
commented
3 years ago * number of people that have completed the quest
I'd also add "*number of people that claimed the quest" It can be just "click to claim" to begin with, but in the long term people would need to stake to claim.
* created_atWould be useful to have by-role or skill filtering too.
Creation of a quest. Only available to moderators.
Moderation access should probably be determined by the amount of pSeeds held. How much Seeds should you plant to get moderator access is an open question though. I'd say something like 100 at the minimum? (except for the "for metagame's good" ones, which should be free to post)
Thank you for taking a stab at this! I'll start looking for someone to design the UI :)
META-DREAMER
commented
3 years ago @pakokrew Hard to comment on this since its not a PR where I can have specific line comments to give feedback, but I think overall it looks good. Might even be worth putting this in the repo as a design doc / "MIP" (metagame improvement proposal) to make it easy to track comments and changes etc.
Quests will not contain rewards. Expected work should be tracked by sourcecred and generate XP/seeds
We can also create a plugin for SourceCred to distribute XP based on the quests that were completed if we want.
once per player (PERSONAL)
This probably means we will need to get BrightID integrated to prevent people doing the same quest multiple times under different accounts
Automatically create quests from github issues with quest label
Not a fan of this IMO, would start conflating what's a quest vs issue, better to keep clean separation
Create a "role" in guild_player, to define permissions inside a guild, which would enable guild member to create quests
These permissions will likely be set by discord roles to start. e.g. Anyone who is Diamond or Platinum fam can create quests. However I dont know if that will work for all communities, maybe some want to allow anyone with enough tokens to create a quest or something.
Allow anyone member of a guild to create a quest, use (conviction/quadratic) voting to pass the quest from proposal to open
Probably too complicated, simpler the better for quests. If we see a need to do something like this in the future we can take another look, but for now I would like it to be lean as possible
Allow anyone to accept quest completed submission through voting
Would have to define this further, might get easy to game / exploit
type - enum [ONE_OFF, EVERGREEN, PERSONAL]
The naming is a bit confusing. Maybe EVERGREEN can be "CHALLENGE" or "RECURRING", and PERSONAL can be "PERMANENT" or "OPEN", and ONE_OFF can be "RAID" ?
created_by => player.id
maybe "created_by_player_id" would be a better name to make it more explicit what the relationship is to
completed_by - UUID , not null
maybe "completed_by_player_id" or even just "player_id" would be a better name to make it more explicit what the relationship is to
submission_link - text, not null
not all completions might have a link, so "submission_text" could be more appropriate? User is free to include a link in the text if they wish
We need to create a function to bypass hasura permissions, to have a temporary check of who is allowed to create quests.
Could you elaborate what you mean by this?
Also, we should have the ability for a quest to have a prerequisite to complete other quests first.
alalonde
commented
3 years ago Moderation access should probably be determined by the amount of pSeeds held.
Is there a way to programmatically look this up?
@hammadj Aren't the concerns about gaming mostly remedied (at least in v1) by quests not explicitly being rewarded?
META-DREAMER
commented
3 years ago Moderation access should probably be determined by the amount of pSeeds held.
Is there a way to programmatically look this up?
@hammadj Aren't the concerns about gaming mostly remedied (at least in v1) by quests not explicitly being rewarded?
Yea, we can use Balancer's subgraph and remote join it into Hasura: https://thegraph.com/explorer/subgraph/balancer-labs/balancer
Quests still might be rewarded after the fact. I'm imagining that other guilds will be creating quests as well and might want to reward the people who complete it somehow. Its not something we have to worry about right away, but def should keep an eye out before we distribute rewards for quest completion
dysbulic
commented
3 years ago It is my hope to eventually associate skills needed for a quest, and to have a feedback mechanism where the quester is rewarded with skill points proportional to the time they spent practicing the skill.
pacoccino
commented
3 years ago Might even be worth putting this in the repo as a design doc / "MIP" (metagame improvement proposal) to make it easy to track comments and changes etc.
Good idea. We should create a template for this. For now I keep my first post updated with our discussions.
We can also create a plugin for SourceCred to distribute XP based on the quests that were completed if we want.
That'd be great !
This probably means we will need to get BrightID integrated to prevent people doing the same quest multiple times under different accounts
We already have this problem now in discord. But we definitely need to solve sybil attacks. I don't know if BrightID is ready for production use. It is not even available in my App Store (France)
Allow anyone member of a guild to create a quest, use (conviction/quadratic) voting to pass the quest from proposal to open
Probably too complicated, simpler the better for quests. If we see a need to do something like this in the future we can take another look, but for now I would like it to be lean as possible
This is left for a future work indeed. It is a topic we are thinking about taking inspiration from Snapshot and Tokenlog, and maybe asking for help from TokenEngineeringCommons.
The naming is a bit confusing. Maybe EVERGREEN can be "CHALLENGE" or "RECURRING", and PERSONAL can be "PERMANENT" or "OPEN", and ONE_OFF can be "RAID" ?
CHALLENGE => RECCURING ok PERSONAL => it is something everyone can do once. It is not always permanent, and I find OPEN confusing. ONE_OFF => RAID could be confusing with the eventual Raids we would have in the database in the future
not all completions might have a link, so "submission_text" could be more appropriate? User is free to include a link in the text if they wish
I think it is convenient for the UI to have a specific field for a link. I'll make submission_link nullable, and add a submission_text free text field (markdown-able?).
We need to create a function to bypass hasura permissions, to have a temporary check of who is allowed to create quests.
Could you elaborate what you mean by this?
I think it will be hard to make Hasura check for complex permissions required to create a quest. The requirement may be external of what's in the DB (like holding X amount of pSEEDs or a discord role), so a custom action could do that.
It is my hope to eventually associate skills needed for a quest, and to have a feedback mechanism where the quester is rewarded with skill points proportional to the time they spent practicing the skill.
That's what I meant with Accomplishing this will result in being able to assert player's skills, and that's an important topic (cf MetaSkills). We'll add skills required to complete a quest.
Updated things I haven't commented on what you said in the first post.
peth-yursick
commented
3 years ago The naming is a bit confusing. Maybe EVERGREEN can be "CHALLENGE" or "RECURRING", and PERSONAL can be "PERMANENT" or "OPEN", and ONE_OFF can be "RAID" ?
I literally just came back to this thread right now to write "maybe we should rename evergreen quests to challenges", but decided to ctrl+f "challenge" just in case somebody already wrote that 😂
This probably means we will need to get BrightID integrated to prevent people doing the same quest multiple times under different accounts
Personally not sold on BrightID & similar solutions, I think they would add a lot of friction to onboarding while still allowing more sophisticated scammers to get around. I think this problem is much easier solved by not paying people to complete "intro quests", "self discovery/actualization quests" & other "personal" quests. The intro quests could be rewarded by unlocking new areas or mechanics of the game & other personal quests could be rewarded with achievement NFTs & maybe some non-transferable tokens.
That's what I meant with Accomplishing this will result in being able to assert player's skills, and that's an important topic (cf MetaSkills). We'll add skills required to complete a quest.
I still think players should be able to stake to take quests rather than being forced through a system of proving they have a skill - or at least for what can be more easily arbitrated, vs something like consulting
pacoccino
commented
3 years ago I literally just came back to this thread right now to write "maybe we should rename evergreen quests to challenges", but decided to ctrl+f "challenge" just in case somebody already wrote that 😂
What are you thinking about this? What is a "challenge" for you ?
I've changed quest types to quest "repetition"
repetition - enum [ONCE, ONCE_PER_PLAYER, RECURRING]
Personally not sold on BrightID & similar solutions, I think they would add a lot of friction to onboarding while still allowing more sophisticated scammers to get around.
Agree to say that it's too early for that.
The intro quests could be rewarded by unlocking new areas or mechanics of the game & other personal quests could be rewarded with achievement NFTs & maybe some non-transferable tokens.
Definitely. And we can add requirements to achieve some quests before doing some others. I'll spec that.
That's what I meant with Accomplishing this will result in being able to assert player's skills, and that's an important topic (cf MetaSkills). We'll add skills required to complete a quest.
I still think players should be able to stake to take quests rather than being forced through a system of proving they have a skill - or at least for what can be more easily arbitrated, vs something like consulting
That's not what I was saying. What I was trying to explain is that when we create a quest, we define which skills it requires. But a player doesn't need to prove to have these skills to complete it, however they could prove they have them because they did the quest!
peth-yursick
commented
3 years ago What are you thinking about this? What is a "challenge" for you ? I've changed quest types to quest "repetition"
repetition - enum [ONCE, ONCE_PER_PLAYER, RECURRING]
Just something that is short & straightforward to complete. In this case I'd say "post one of MetaGame's articles to a community where it fits". But if you're taking this other approach, maybe just call them "daily quests" in the frontend?
Definitely. And we can add requirements to achieve some quests before doing some others. I'll spec that.
Yeah, I think this would be useful not just for personal quests but also things like the Builder path, so that people receive them 1 by 1 instead of being bombed with the whole list right away.
That's not what I was saying. What I was trying to explain is that when we create a quest, we define which skills it requires. But a player doesn't need to prove to have these skills to complete it, however they could prove they have them because they did the quest!
Ah ok ok! Sorry, misunderstood you there
This is the spec for the first iteration of the Quests app, which will be split in different PR and will require work from different people.
Trying to follow https://www.notion.so/Quests-57662b138f6240d386924b5c5f076312
Objective
We first try to create a simple system for replacing the #quests channel in discord. This will implement the Phase 0 we describe in Notion.
Quests can be done either:
Future work
As this is a first iteration, it will miss a lot of feature that will come in the future. What we may do after this:
Pages
/quests
Page displaying all the existing quests.
Should display as a paginated vertical list.
Each line contains:
Filterable by:
Sortable by:
/quests/{quest_id}
Page containing all the details about a specific quest.
Should display every quest prop
Should display all player's submissions.
If the viewer is the quest creator, he can edit the quest or accept submissions.
If the viewer is a player and the quest is OPEN, he can send a submission
/quests/{quest_id}/edit
Page to edit a quest. Only available to quest creator.
Should allow to edit quest's [title, description, external_link] props
/quests/new
Creation of a quest. Only available to moderators.
Should ask for quest's [guild_id, title, description, external_link] props
Creator must be member of the guild
Creator must be
DB Models
quest
id - UUID created_at - date, now() guild_id - UUID , not null created_by - UUID , not null
title - text, not null description - text external_link - text
status - enum [OPEN, CLOSED] repetition - enum [UNIQUE, PERSONAL, RECURRING] cooldown - number (only for RECURRING, time after we can do it again)
Relations
guild_id => guild.id created_by_player_id => player.id
Permissions
quest_skill
quest_id - UUID , not null skill_id - UUID , not null
Relations
quest_id => quest.id skill_id => skill.id
Permissions
quest_completion
quest_id - UUID , not null completed_by_player_id - UUID , not null submitted_at - date, now() submission_link - text submission_text - text status - enum [PENDING, ACCEPTED, REJECTED]
Relations
quest_id => quest.id completed_by_player_id => player.id
Permissions
Functions
Create quest
Check if player is holds more than 100 pSEED, and create the quest.
We need to create a function to bypass hasura permissions, to have a temporary check of who is allowed to create quests.
Create Quest submission
Check if:
cooldowntimeAccept/Reject Quest submission
Check if:
Set submission on ACCEPTED/REJECTED Set quest as CLOSED if repetition === ONCE