MVP Game Mechanics v0.2

[Shpigford]

v0.2 of MVP Game Mechanics — This discussion is so we can have a central place to talk through game mechanics for the MVP.

Rockburg is a music industry similuation game built around trading cards dynamically generated on the blockchain.

We will have a fixed number of drops for each card type. Once those core cards are generated, no more will be created. Though utlimately the combinations of those cards could be used to create new ones.

Core Card Types

These card types are core to the game. They're used in combination with one another to create new resources.

Musicians

Limit: 10,000

• Name — Auto-generated
• Role — The core instrument they play
• Skill — How skilled they are with their instrument
• Looks — Better looking musicians attract more fans
• Ego — Volatility stat. Larger ego in a band could mean huge bonus for certain actions...or detrimental outcomes.
• Creativity — Higher creativity results in better songs

Studios

Limit: 2,500

• Reputation — Affects the ability for a band to book studio time
• Lead Time — How long will it take to produce a song

Instruments

Limit: 25,000

• Skill Bonus — When combined with the appropriate musician, it provides a bonus range.

Locked only while recording a Song or playing a Venue.

Combo Output Cards

These cards are the output of combining core cards.

Genres

Unlimited minting, but certain genres will be highly sought after (due to popularity + fan dedication stats) and thus rarer.

These should be very low-cost to mint.

• Name
• Popularity — How much of the population listens to this genre?
• Fan Dedication — How dedicated are the fans? Generally speaking, more obscure genres have more dedicated fans.
• Member Requirements — Each genre will require certain roles.

Bands

Requires a Genre card + the necessary Musicians to fill all the roles.

Genres are not locked. Musicians are locked.

• Name — Auto-generated
• Skill — How skilled is the band as a whole? (A product of the members)
• Performance — How good are they live?

What other attributes could be added?

Songs

Requires a Band card and a Studio card.

Locked for the “Lead Time” of the Studio card.

• Quality — How good is the recorded song?
• Name — Auto-generated (GPT-3?)

Could be cool to do something like Tunes where folks can create actual art, music, lyrics, etc to sell associated with the Songs.

[dgrcode]

Bringing one comment from v0.1 discussion #6 to keep everything in the same place.

what if the owners of those studios stop playing the game? You end up with some extreme scarcity

That's a good point. I guess all NFT games have the same issue where users can go inactive and break parts of the game mechanic. A posible solution here would be that studios can be "rented" (I think @StErMi used the term "landed") without owner's action. For example, a studio comes with a default use price, which the owner can change. If someone wants to rent it to record a new song, they just pay the fee and the studio get's locked. If a user stops playing the dynamic is not broken.

Some thoughts about v0.2:

• Genres is under "Combo Output Cards", but I don't see what cards would be used to create them. Are the cards needed missing? or should it be one of the core cards?

• In the Bands section:

  What other attributes could be added?

  I'd add properties contributed from the building cards properties. Like translating properties from the building cards into the built card. For example, the band could have a property named "fan attraction", which is a property based on the genre's "fan dedication", and musicians "looks". Properties that come to mind doing that translation of props:

  • Fan attraction. The one described in the example above.
  • Breakup odds (naming is not my strength): based on musicians' egos. Could be a % change of the band breaking up after a song/album/tour. We could come up with some formula, like having multiple musicians with high ego will increase that, or not having a musician with high ego will also increase it. Popularity and fan dedication could also affect this prop.
  • Creativity: Based on musicians' creativity and genre's popularity.

[StErMi]

Natively you cannot make Smart Contracts "real-time" or "dynamic" without an Oracle (never studied them).

[dgrcode]

@StErMi I'm getting a bit confused by the terminology we're using. I know in the crypto space people like to tweak words like "hodl" vs "hold", but just to make sure we're on the same page with wording:

• Is English "rent" (someone pays to use your property) transformed to "rant" in crypto world? A bit confusing because "rant" has another meaning in actual English (where hodl, for example, doesn't). I think we should use "rent" to avoid confusion.
• Is English "lend" (someone uses your property with your permission) transformed to "land" in crypto world? Also a bit confusing due to "land" having another meaning as well. I think we should use "lend" to avoid confusion.

I've also thought about real time issues with renting/lending of cards, and I think it can be solved by setting a property like availableOnTimestamp. That way we only need to check if the current time, available at block.timestamp is bigger or smaller than the availableOnTimestamp value assigned to the specific tokenId, which represents the locked card. If the time is bigger, it means the lock period finished and the card is available for use again. If the time is smaller, the transaction should be reverted and the user will spend the gas fees for nothing. On the frontend we can read the availableOnTimestamp period to know if a card is locked or not, and show it as disabled (or with a lock or whatever else) to show the user that the card is not available yet.

Does that make sense?

[dgrcode]

@Shpigford regarding

Could also be interesting to update something like "Fans" or "Buzz" for a band, based on how much it's getting traded (and at what price?).

I thought about the fans as well, but didn't include it as a property because I'm thinking about properties as things that cannot be changed. Something assigned during minting that's "written in stone". Being able to change any of those would make me worry about people finding a way to update their card's properties hacking something. It could lead to unfair advantages.

I do think bands should have something like "Fans" or "Buzz", but I see it more like part of the game state rather than the cards properties.

I also think game state could have effects on cards properties. For example, the current amount of fans of a band could affect the quality of a song during minting, or the income from a tour (I see tour has been removed in v0.2, just using it to illustrate this point).

[StErMi]

@dgrcode those were typos sorry :( yeah, it was what you meant.

Lending can be implemented with lending time or lending usage. I still need to understand how timestamp is "safe" in crypto (see the link above) but I think it can be used here. Lending time could be a problem if it overlaps with other timers like the time needed to create a song/album or to make a concert. @Shpigford in your initial thoughts those were instant actions, right?

For example, you lend an instrument for 10h, I use it at the 9th hour to create a song that takes 2h to do that (item is locked for 2h), should we take that into consideration? I mean, should you be able to create the song or not?

In this case, the "ownership" check that the Instrument needs to expose should take into consideration that. It should check if you own the item, if you have the approval (lending) to use it and if the time needed to do an action with the item is less than the span of time you have rented the item for.

Does it make sense @Shpigford @dgrcode?

[dgrcode]

those were typos sorry :(

No worries! Another English as Second Language speaker here 😄

Regarding time checks, I agree. There are two checks:

1. When you don't have the ITEM (instrument, venue, whatever else that can be rented) and want to rent it. We check that currentTimestamp > item.availableOnTimestamp for that given ITEM.
2. When you are using a rented ITEM, owned by someone else, and want to use it. We check that currentTimestamp + action.lockTime <= item.availableOnTimestamp

That's not working solidity, just pseudocode. item would be the item being rented, and action would be the action done using that item.

Having said that, I believe the locking logic, list of actions and lock times, etc., should be out of scope for the MVP. We can always create a second contract for locking logic which reads from the first contract (collectible logic), right? Maybe trickier to make the first read from the second, but that might not be a problem.

[StErMi]

If we want to move forward we need to solve some economic/logic issues, after that, I can start implementing and experimenting with the code.

1. Musicians have a role, which means that they can only equip an Instrument of a specific type right?
2. How can we balance the number of musicians of a specific role with the number of instruments of a specific type? We don't want to have 1000 vocalists and only 100 microphones right?
3. How does Genre interact with the Band? If a Band is of a specific genre does it mean it must have a specific number of musicians of a specific type? For example, a Rock band needs to have a vocalist, the main guitar, a rhythm guitar, a bass, and a drum?
4. If the (3) is correct I think that we need to simplify things to implement that metadata, so having a limited type of Genres in order to "hardcode" those checks. I need to think about it and find a dynamic way to do that

@Shpigford if I'm not wrong you said that you don't want to require a "fee" to do minting actions right? So to create a song you don't want to force the user to pay a fee?

@Shpigford names in general need to be embedded inside the contract (we have a pool of combinations or they can be provided as user input if you want). Getting that info from outside can't be done (not easy and it involves using an Oracle and I have no prior experience on that). Otherwise what we could do is to use GTP-3 to generate a name for each tokenId minted and expose that name from an external source (backend). So in the contract, you only have the _bandId, _songId, and so on and websites will pull the metadata from external sources (like they do right now with NFT metadata not embedded inside the contract). This is up to you but if we choose this way we can't use the SVG to render the NFT from the contract

[dgrcode]

names in general need to be embedded inside the contract

You're right, but there might be a workaround. I was thinking about having a mint function that receives names. This is what we have currently implemented in the mint{Type} functions (e.g. mintArtist). The problem with that is the contract is public, so people could start minting stuff with the name they choose, which we want to prevent.

We can add a check for the msg.sender, and make sure the mint is being called from a known address, which we control. The checks can be done using the Ownable interface. The known address can be used by a node server.

I have two open questions with this approach:

1. How to connect a node server to the blockchain?
   I'm pretty sure it can be done, but have never done it before. Best case: there's a npm package for that, or a service (infura?).

2. Is the name generation off-chain acceptable for us and our users?
   Concerns people might have:

   • Most blockchain stuff is public. Having some private backend in the minting pipeline could be an issue for some people.
   • Most blockchain stuff is trustless. The backend is a single point of failure and people need to trust that we'll have the server running at least until all minting with names is finished.
   • From the unchangeable point of view (not being able to change a minted NFT), I think this approach is solid. Once the server mints an NFT, it's "written in stone".