Quests champion proposal

Quests are one of the essential features of rpgs, so it would make sense to implement them in a slightly more interactive way in our ever-developing MetaOS. Luckily a lot of work has already been done in this regard, but unfortunately it was left unfinished. Since I continued where paco left off with the implementation of quests in MetaOS, peth suggested that I might as well pick up the champion role, which IMO would require me to have:

  1. insight into the current state of the questing system
  2. a clear vision on what we want to achieve with the implementations of quests in MetaOS
  3. a clear plan on how to achieve that

1. Current state

Resources are currently available in notion and on github.

Github

There is a bunch of specs that are either ideas or implemented to some degree. Paco has done a lot of work, which will serve as a foundation of what we want to build.

Notion

The quest paths which are defined in notion are well put together, but are not interactive and they are not very discoverable. It took me a couple of months to find the Quest board, but I think it’s very important to introduce new players to it asap.

2. Vision

I would like to unify onboarding with questing, along with automated attribution of xp in MetaOS by rethinking the UX. The idea is to create an engaging questing system that would provide users with a gamified onboarding guide and help them graduate into players.

3. MVP proposal

If we are to build a web3 onboarding machine, we need to figure out how to do it properly. I first aim to complete the basic functionality of quests, which includes

This, in turn, will enable us to start implementing the warm up quests, which will be available for every new user after they set up their account.

After the completion of warm up quests, one will be able to start doing the quests which pertain to their selected role path.

When they complete a given % of the path, they will gain access to the rest of the quests, which are currently listed in the Quest board.

In short: gradually we’d move the quests out of notion into MetaOS.

4. Future iterations

After we are done with implementation of the stuff I proposed in #3, we are free to play around with:

5. What would I need

I would very much like to work together with a focused team of people, so at least one designer (@dave?) and one to two additional builders. If you are interested, please let me know!


References:

  1. Path quests: https://meta-game.notion.site/88ce34ac198b49d1bf3934edb3be2a4c?v=eda2d7adca8f4a3a9a0c57abff5d213d
  2. Warm up quests: https://meta-game.notion.site/Warm-up-Quests-outdated-f0186959a1804fae935d84c5c140a21c
  3. Quest board: https://meta-game.notion.site/Quest-Board-WIP-0b85cd7549bc4227bbc0f5e4d413edf6
  4. Quests spec by paco?: https://meta-game.notion.site/Quests-bc8d3bcb6491493a879b9adc3a4f4938
  5. First PR by paco: https://github.com/MetaFam/TheGame/issues/290
  6. github quest issues: https://github.com/MetaFam/TheGame/issues?q=is%3Aissue+is%3Aopen+label%3Aquests
5 Likes

This sounds like a very good use of the meta-collab app me and Dan3ram have been working on. @CrisLeach has also expressed interest in the Design side.

Re. Metacollab, we are in a bit of a holding-pattern as we define what should be “owned” by MG and what should be a public service. Michiel reminded us that once the work goes into a MG repo and is tracked by SourceCred, we (the builders) no longer “own” it.

If that is the case, each initiative needs Players to share the load obviously, or each app that MG may want to use should be built first outside MG initially and not connected to Sourcecred so the participants can figure that out first.

I really like the idea you have proposed and would love to be part of it. I also think working out some of the the boring “ownership” detail may also make sense.

At this point I will assume its a MG owned initiative and the compensation/workload will only be made though MG XP SEED and Sourcecred.

1 Like

As discussed in yesterday’s meeting, we have a couple of options and it looks like that the best option might be to keep 2 separate versions of the MetaCollab app, one being a standalone app that would be maintained independently of MG and the other being adapted by MetaOS and implemented either by

  • integrating the smart contract into the questing system by providing a separate quest type(s), which upon quest completion directly awards a predefined amount of currency (instead of xp) or
  • having a separate app, independent of quests, inside of MetaOS

I think that the MetaCollab system is too similar to quests to just ignore the correlation, so I’m quite excited about what we can muster up. There is also no real time constriction, since MetaCollab implementation into MetaOS can be developed pretty much independently of my original proposal (onboarding) and by providing an additional quest type, @dan13ram and @tenfinney are also given a lot of creative freedom.

1 Like

Love it!
We already talked a bunch about all of this so I don’t really have much to add, sounds great.

Would you benefit from having a call with paco?

What do you mean “own” it?
Not sure we formally have any kind of a license on our repo but its all meant to be open source.

My main concern is the overhead cost, if we build every piece externally at first & only then work on integrating it into MetaOS, won’t it take a lot more effort?

I love the whole idea of having small autonomous teams working on their pieces but I think the questing system itself is too crucial.

If we are going with the whole idea of MetaOS as being the bare bones & then all of these things as apps built by intedependent/interdependent teams, here’s how I think it could work out long term:

  • All things start as internal projects unless contentious
  • If the project seems to lose direction from the community’s perspective or using too much resources or distracting people, it should spin out & work until they’re ready to integrate or decide to push forward on their own.
  • If the project is successful & fulfills its original purpose in MetaGame, the team can spin it out into an independent building block.
  • This could happen in two ways:
    • They keep it inside MetaFam but the weight of their repo is lowered
    • They completely fork it out into a new organization & repo
  • Whatever way they choose, they can then issue their own token by measuring only their piece of the work & give a small cut of the supply to MetaGame for providing the infrastructure & resources thus far.
  • Does this make any sense?