Technology
Decentralized Video Game Update Voting
How to keep things representative
Getting a perfect representation of a sample is hard.
There is no perfect way to represent a sample, not even the sample itself; game theory dictates that people will not vote the way that would best fit their wants in order to keep an option that they dislike from winning. This is the two party problem.
When I first designed the decentralized video game, I made it so that votes would be separate, so that there wouldn’t be two competing possibilities of where the game could go every single update.
However, I came up with this scenario
- 30% want +20% damage on a weapon, and -25% firing speed.
- 30% want +20% firing speed on a weapon, and -20% move speed.
- 40% want +20% damage on a weapon, and -30 health on player
What would happen is that the weapon would get +20% damage, with nothing to counteract it. You’re probably thinking that that would never happen, and it wouldn’t, that’s the problem, the voting system is not representative of the voters.
A way to fix this is inclusivity. Inclusivity dictates that certain changes have to happen together; O in English, “I want both of these to happen, or none.”
Assuming everyone voted to make their votes for the weapon change to be exclusive, no change would win.
Unfortunately the “two party” problem will happen all over again. A way to fix this is exclusivity. Exclusivity allows for votes to contain multiple endorsed outcomes.
This allows people to vote for what they want, without the risk of a wasted vote, because multiple options can be voted opoun.
Say the above example changes to:
- 60% want +20% damage on a weapon, and -25% firing speed.
- 65% want +20% firing speed on a weapon, and -20% move speed.
- 40% want +20% damage on a weapon, and -30 health on player
The numbers add up to over 100% because votes can be casted for multiple options
On this case, the weapon would get +20% firing speed and -25% move speed on wearer. The change would happen to the exclusive option with the most vote percentage; even though the first option got over 55%, it doesn’t win because another option for more vote than the first.
Every blockchain and decentralized thereof must have a way to automatically implement changes that are not hard forks. In order for a computer to detect inclusivity and exclusively, identifiers are needed.
Inclusivity would basically just be two changes in parenthesis or braces or whatever, as long as the computer can detect the changes are together.
Exclusive groups needs the same thing as inclusive groups, but labeled exclusive.
Inclusivity and exclusivity can also be stacked indefinitely. In the latter example, votes were casted that contained inclusive changes in exclusive groups. I can also imagine someone creating an inclusive group around the the exclusive group that would change other weapons or abilities, to make everything balanced.
However, I imagine that this will lead to one giant inclusive group, though as long as the space allowed for votes is big enough to adequately communicate what they want.
In the original whitepaper, the votes allowed for compression of votes, by not requiring the voters to resubmit the data for a change every time it was votes for. The best way to compress things is to limit the vote storage capacity to say, 512 kilobytes, and another file that initializes changes with the data. that is limited to 1042 kilobytes.
