Hey frens, we are excited to announce that the SigProp for Gotchi Aging reached quorum organically and has been upgraded into a full blown CoreProp!
Let’s use this thread for any final discussion while we vote.
See you in the comments below, and on Snapshot!
Vote link: Snapshot
Hello frens, i will copy / paste what i wrote in discord. Please if you have to shoot, shoot the message not the messenger :
" I don’t understand this point “long term engagement”, as i understand the proposal there is not engagement in the process, im i wrong ? Buying a h1 gotchi isn’t engagement, gotchis don’t need engagement from players to procc the aging boost
It just boost H1 over H2 for the RF season 2, it’s not about fairness. The goal is to bring H1 more value.
Why do we need to make this decision before the gotchiverse ? We almost know nothing about the game and the impact of BRS in it.
Some people will point that im biaised because i have a top h2 gotchi (naked), really i don’t care about the RF, i bought h1/h2 and i will buy h3. Im just worried, i don’t think it’s wise to modify parameters with few informations in our hands.
If we have to think about rewarding engagement, maybe we can work on kinship, with the automatic petting services there is no engagement anymore. "
edit: “i don’t care about RF” means i won’t compete this season not idgaf about RF.
I think “longterm holding” is more accurate than “engagement.” Rare gotchis should increase in value, not decrease.
With adoption being a clear priority, we can expect each haunt to be larger than the last (or at least as large, dwarfing both H1 and H2 probably). This means that the rarest gotchis will naturally become significantly less rare over time. It’s truly not about pumping certain bags to me, it’s about molding incentives to avoid a death spiral of dumping high BRS gotchis before each new haunt. It also incentivizes opening portals and opens up new thematic game possibilities like Ethereality.
Your lack of care about rarity farming may be a mistake, since even if you don’t compete it’s what currently funds this whole project.
I hope we can discuss and run numbers on different curves for this mechanic if it passes. The timeline seems too short to me, basically being over in one year.
Likewise, I’d like to hear about dev ideas and interest in incorporating “Ethereality” or Aging into the game. What potential do you see? I think it would be so cool to be able judge gotchi age by some quality in game. Or is this more of a mathematical tack-on in your view?
I agree. Fibonacci sounds nice but if the effect is so small that they would have to implement it before RF S2 for it to have any noticeable effect, then it might not be the best implementation for a boost.
Yes, this has become more and more evident to people recently. A couple months back I suggested to make completely separate leaderboards (also for BRS) between veterans and rookies, with the veterans getting a larger piece of the pie. This would mitigate the problem a lot, but at this point it would deviate too much from what has already been announced.
I believe it would make sense to see RF as an interim-solution to player rewards. After the Gotchiverse realm goes live, we could completely replace RF with a much more refined and fair rewards distribution for players that would benefit long term holders as well as new players. Reward-pool-sponsored quests in combination with Gotchi lending comes to mind. And there could be exclusive quests for each Haaunt. That way, dilution would have a lot less of an impact.
Another idea would be to couple the amount of new Gotchis in a haaunt to the number of unique Gotchi owners as well as daily active users. If those numbers are too small compared to the Gotchi supply on the bazaar, we should hold off with haaunts.
We also discussed cheap entry-points a lot. Maybe we should reduce the standard deviation of the bell curve for each new haaunt. That way, the high BRS Gotchis would be rather safe from dilution while new people can still get a cheap Gotchis.
It might also be worth to revive my proposal of Gotchi resurrection by sacrificing two or more Gotchis. This would incentivize Gotchi sacrifice and thereby decrease supply. One could also make changes to the original proposal to give people some greater benefits for sacrificing high-BRS Gotchis.
“i don’t care about RF” means i won’t compete this season not idgaf about RF.
you said : “It’s truly not about pumping certain bags to me, it’s about molding incentives to avoid a death spiral of dumping high BRS”
I don’t understand, what’s the problem if people wants to dump their gotchis ? Gotchis will still aging if they are dumped, it won’t stop “the death spirale”, so it’s clearly about protecting investment.
The meta is that way because there is no gotchiverse yet, no point holding gotchis outside RF. If aging was implemented before H2, the meta would be the same.
H1 already got huge kinship and XP advantage (leveling increase BRS), retired collaterals (best myth eyes) and unique background, is it not enough ? Is it necessary to increase the gap between old gotchis and futurs H3,H4 … ?
I am ambivalent about this proposal. I share Monarch’s concern/suspicion that it’s about preserving value for H1 gotchis, which is already protected in a bunch of ways (see: the baazaar). Then again, there is no reason to expect, reliably, reasonably tight caps to haunt size, if that’s even a worthy goal (this project’s main internal contradiction again: a game needs players vs. a collectible needs scarcity).
I will more likely than not vote ‘yes’, because this is addressed at an actual problem and the proposed curve levels out quickly enough that it seems to pose relatively little risk to the ecosystem. But it’s worth dwelling on how easily a good community/competitive balance can be irreparably ****ed by the rent-seeking behavior on behalf of early adopters, whales, and (especially) actors who are both. That won’t go away. For instance, the idea of narrowing the rarity bell curve for future haunts strikes me as totally unfair and detrimental.
Looking forward to the results on this one, in any event!
It would be cool to see birth order along with age.
Why was this moved to core prop before voting ended?
Let’s read the full initial thread before getting into the same discussion all over: Introduction of an Aging Mechanic for BRS
TL;DR the aging mechanic rewards long term engagement and fixes on the short term the fact that H2 gotchies have a BRS advantage over H1 ones because of the change (aka fix) in the trait generation code.
Copied from discord:
I feel that the way this aging proposal has been inevitably associated with the H1 vs H2 BRS debate has both weakened and confused it.
Adding aging as a general concept/gotchi stat that could add flavor and utility in the Realm game has a lot of potential.
But the proposal links it purely to BRS boosting, which doesn’t open up further possibilities, and partially duplicates the XP/levelling mechanism. (As a developer, I’ve learned to be cautious about introducing complexity when there are existing features that can serve a similar purpose.)
The proposal itself outlines the algorithm for adding BRS in detail.
Goals: 1) to add an incentive to open portals earlier, 2) to counteract dilution i.e. what happens when we double the number of gotchis while limiting farming rewards to the same Top 5000.
Right now, BRS changes affect rarity farming and baazaar prices. We don’t have details of future utility of BRS in the Realm, and neither do we know how to value XP and kinship there (which themselves might turn out to be a sufficient H1 bonus).
Although the proposal only discusses the dilution effect, many people are thinking that this is a BRS ‘fix’/‘rebalance’ for high BRS gotchis, because the association has already been made and keeps being brought up. I haven’t yet seen any discussion on how it would affect the actual leaderboard though.
So I wanted to get an idea, especially as it looks like it’s happening regardless 
As a very rough ‘back-of-the-envelope’ calc, by very simply adding +5 BRS to H1 gotchis in the leaderboard (this is a maximum buff which will be smaller in practice/over time), I found that there was negligible effect on the uber gotchis at the top of the leaderboard, and the largest effect on the borderline gotchis around the top-5000 cutoff. In other words, this will not be noticed by the top where the expensive wearables dominate, but it will be felt most by those just reaching for the scraps at the bottom.
"top5000": {
"h1": 2804,
"h2": 2196
},
"top5000WithAge": {
"h1": 2975,
"h2": 2025
},
Also, when looking at the overall dilution effect from adding the H1 gotchis (~2200 H2s taking the place of H1s) this ‘helps’ ~200 of these H1 gotchis at most. So it only partially and temporarily addresses it (whereas benefits from levels and kinship have potential to be much more effective).
Note again that this is a rough test to get a broad idea of the kind of changes that could be produced. It is not accurate for many reasons, including:
If you want to try it yourself, you can run my script in the JS console of Aavegotchi Stats
Following instructions for Firefox, other browsers will be similar:
Visit the page and wait for the table to load
in the JS console. find the ‘rarity’ Array and store it as a global variable
move the focus to the console where it says ‘temp0’ and press Enter to create the global variable
paste in my JS below and press Enter
// After leaderboard table is loaded, in the js console,
// store 'rarity' Array as global variable: assume it's "temp0" by default
const rarity = temp0;
// BRS adjustment for each haunt:
const brsBonus = { "1": 5, "2": 0 };
const rarityWithAge = rarity.map(item => ({
...item,
withSetsAndAge: (item.withSetsRarityScore-0) + brsBonus[item.hauntId]
}))
rarityWithAge.sort((a, b) => {
if (a.withSetsAndAge === b.withSetsAndAge) {
if (a.kinship === b.kinship) {
return (a.id-0) < (b.id-0) ? -1 : +1;
}
return a.kinship > b.kinship ? -1 : +1;
}
return a.withSetsAndAge > b.withSetsAndAge ? -1 : +1;
})
const filterH1 = ({ hauntId }) => hauntId === "1"
const filterH2 = ({ hauntId }) => hauntId === "2"
const counts = {
all: {
h1: rarity.filter(filterH1).length,
h2: rarity.filter(filterH2).length
}
}
const countTopN = (n) => {
const topN = rarity.slice(0, n);
const topNWithAge = rarityWithAge.slice(0, n);
counts[`top${n}`] = {
h1: topN.filter(filterH1).length,
h2: topN.filter(filterH2).length
};
counts[`top${n}WithAge`] = {
h1: topNWithAge.filter(filterH1).length,
h2: topNWithAge.filter(filterH2).length
};
};
const topNs = [10, 20, 100, 1000, 5000, 10000];
topNs.map(countTopN);
console.log("Counts:", JSON.stringify(counts, null, 5));
console.table(topNs.map(n => ({
TopN: n,
differenceH1: counts[`top${n}WithAge`].h1 - counts[`top${n}`].h1,
differenceH2: counts[`top${n}WithAge`].h2 - counts[`top${n}`].h2
})))
const reportTopN = (n) => {
console.log(`Top ${n}: original`);
console.table(rarity.slice(0, n), ["hauntId", "id", "name", "withSetsRarityScore"]);
console.log(`Top ${n}: with Age`);
console.table(rarityWithAge.slice(0, n), ["hauntId", "id", "name", "withSetsRarityScore", "withSetsAndAge"]);
};
reportTopN(100);
Bonus: if you want to see the effect on a specific gotchi, paste in the following too:
const showGotchi = id => {
id = id + "";
const originalIndex = rarity.findIndex(item => item.id === id)
const withAgeIndex = rarityWithAge.findIndex(item => item.id === id)
console.log(`Gotchi ${id}: original index ${originalIndex}, index with age ${withAgeIndex}`)
};
const showOwner = id => {
id = id.toLowerCase();
const gotchis = rarity.filter(({ owner }) => owner.id === id);
console.log(`Found ${gotchis.length} gotchi(s)`);
const gotchiIndexes = gotchis.map(gotchi => {
const originalIndex = rarity.findIndex(item => item.id === gotchi.id)
const withAgeIndex = rarityWithAge.findIndex(item => item.id === gotchi.id)
return {
id: gotchi.id,
name: gotchi.name,
hauntId: gotchi.hauntId,
originalIndex,
withAgeIndex
}
});
console.table(gotchiIndexes);
};
console.log("Display a specific gotchi with: showGotchi(1549)")
showGotchi(1549)
console.log('Display a specific owner with: showOwner("0x118B427af645e5e696E6DA748BD66aC8E4f5E9A8")')
showOwner("0x118B427af645e5e696E6DA748BD66aC8E4f5E9A8")