IIP-XX Gameplay Feature Proposals

[craggy thistle]

Simple Summary:
This document outlines a new proposal type, including the format and specifications for Gameplay Feature Proposals (GFP). Gameplay Feature Proposals will be used by the community for two purposes:

1. Modifications to existing gameplay systems.
2. Additions of new gameplay features.

https://docs.google.com/document/d/17ANt8QZT8J8nFG1uIEVftAFnTPesOkv4Fh5uIpz53a4/edit?usp=sharing

TL;DR: GFPs are a new proposal type that undergo a two approval process. This process is intended to ensure community members can share their ideas for gameplay features without having to draft proposals like a lawyer, while leaving agency to develop games with Illuvium Labs. Ultimately, the community decides if the final suggested implementation meets expectations.

NOTE: If you have feedback on this process, please share it. The intent of this proposal is to make putting forward ideas for gameplay features accessible, so that the DAO isn't passing over viable features due to the rigid nature of IIPs and ICCPs. If you see feedback you agree with, upvote it so it can be incorporated into a revision.

[elder quartz]

So if i get it right, one can be as detailed as he likes to Show the vision he has for the Feature he wants to be implemented, since Labs anyways will do their own Version of it and might or might not implement it if it gets approved again?

[craggy thistle]

Author can be as detailed as they want, that's correct. Approval adds it to the planned feature list. Labs, when they have time to slot it in, will use the core ideas to create the GDD they can implement. After that GDD is posted and gets upvotes and approval, it goes for development.

The key part is that we're not having to reject proposals for having too much specification. It doesn't mean that specification won't make it in to the end product, but it does mean that it doesn't HAVE to make it into the end product. If someone thinks a 25% bonus is the right value, and it turns out not to be, that can be changed, whereas under the current system, we're tied to that specification (which is why so many gameplay feature proposals have needed to be rejected).

[elder quartz]

Yea i get that, and thinks it good to introduce the gfp's.

However as Bad as it was stated it never was.
One could have just done an ICCP to IIP after labs would have Set their specifics. Would have been the Same process just not the same naming 😄

But yea, i like it. 👍

[willow swan]

The two main points I would raise here is that:

1. It leaves no question that what the proponent wrote that has passed may be changed, or adopted depending on Labs interpretation or execution.

Its avoiding the conflict that people apply the words strictly rather than liberally.

and,

2. The original idea that came from the community and its eventual implementation by Labs is still subject to the DAO's sentiment.

This ensures that even if Labs goes way left field with the idea, it wont be implemented without the DAO's approval.

Subsequently, it also ensures that they dont work on something that will get scrapped cause the DAO didnt like it. We save time, effort, and money with this process.

[waxen spruce]

Seems to my untrained eye like the second approval from the DAO can fit fine with how the team works through most tasks from ideation to implementation.

[willow swan]

Yes, its similar to when a GDD is being proposed by Labs. But since proposals might just talk about specific features, we want to differentiate that this only applies to when DAO suggests. We dont want to overburden Labs to get approval for every single feature they think about. We can propose changes through ICCPs or the Game System equivalent.

[green wren]

i got 4 questions:

1. Can we get an example of economic reason to cancel a GFP? is labs going to provide some data, calculation, or projection to justify using economic reason?
   one of the reason to reject IIP-55 was concern about economic implication. i still dnt quite understand that, arguably we can put a premium on that feature. kieran, suggested to offer the dev mode (scan & instant teleport) as a paid feature just like automated drone runs.

2. Fun to play.
   This is highly subjective. A feature which the Team believe to be fun might not be well received by the community, vice versa.
   I believe Fun is in the eye of the customer, not producer. What if the reason in proposing a GFP is because the sponsor does not see a feature as fun, for example the morphods (i hate those). But the team insist they love the bugs and they have spent resources on it. A lot or most of what we have in ILV rn is based on community feedback.

3. How detailed the reason is going to be?

4. IIP-50 and IIP-55 were similar. one of the rationale asked the sponsors to merge those proposals. first, i dont believe it is reasonable to ask sponsors to work together to merge their proposals. people have their own ideas and style. how will this proposal address similar GFPs?

[craggy thistle]

An economic reason could be, for example, a proposal to allow F2P land to generate Fuel. It's hard to be comprehensive here because we're dealing with hypothetical future proposals, but it should be pretty readily apparent that some ideas for gameplay features could have severe negative impacts on the game economy, whether that's because they result in unmitigable exploits or minting of assets, or other impacts that weren't foreseen during the first stage of the process.

Fun is subjective, definitely. It's absolutely in the eye of the consumer, but the producer creates the product. Do you have an alternative solution or wording to rectify this? If a feature sounds good on paper, but plays terribly, would you rather have Labs forge ahead and develop it so that it can be tested by the community, or communicate about the issues as they arise? Note that a cancellation doesn't preclude choosing an alternative means to develop a feature.

How detailed would you like it to be? I'm open to suggestions about specific metrics to be included in this communication. Personally, I'd be happy with an explanation that sufficiently explains the reasoning for the cancellation. If that requires a technical deep dive, or a dissertation on game design philosophy, so be it. If it can be communicated more effectively without those things, I'd tend to think that's going to be a better general solution. I've left this open ended for that reason, but if there's a desire to have some sort of framework around that communication, it can be changed.

Passing GFPs that are largely duplicate or have many similarities is something that will need to be monitored by the community and IMC who are voting on these proposals. I don't think asking sponsors to merge proposals makes much sense, personally, but I also think it's a little redundant to pass multiple GFPs for an extremely similar feature, as Labs will come back with their preferred implementation for the second round of voting either way. Ultimately this comes down to practicing decision making and using our best judgement as a DAO.

[forest rock]

Solid proposal that fills in the gap left from removing the game council and the idea of GIPs.

Only thing I would suggest adding is a brief segment on what is not allowed/ what is not a Gameplay feature for clarity.

Some may try to say the stats of an illuvial or drop rates could be a feature. This will reduce the quantity of proposals that should not be used with in the governance system.

[sharp quartz]

I like the 2 step approval process here. Good proposal @craggy thistle 👊🏽

[dapper tundra]

Fan of this, good work as always Blick. Makes it easier for the community to suggest features without having to put forth a full game design document. This also makes it easier for other community members to weigh in on the ideas, since many don't have the capacity or interest in reading a 20 page doc to understand an idea.

GGs!

[craggy thistle]

Just wanted to follow up on this - I've noted this as a potential pain point, but it's difficult to draw a clear line on what nature of modifications are too granular to warrant a GFP. If this does become an issue in the future, an ICCP would be suitable to adjust the requirements and solve the issue. This will likely be substantially more clear as we see more requests for features, and it seems that defining that line will make more sense once we've seen proposals that are too granular or are adjusting single variables.

[green wren]

ill upload this to github