Support #55
Updated by didi over 7 years ago
# Initial proposal
## Naming
*City Gameboy* is probably not the right term. I was thinking about *City Slot Machine*, but it isn't a slot machine either. What is it? How were those devices named?
## Bidding
There's a bidding timeslot (something between 1 and 5 minutes?) before every game run.
The website always shows either a countdown for the next bidding slot or the bidding interface.
The bidding interface includes a live stream of incoming bids, similar to the incoming transaction stream on Blockchain Explorers.
### Proposal 1
Simple auction: whoever bids most gets the next game slot.
### Proposal 2
Random selection: The bid contains a fixed amount (e.g. 0.1 Ether).
After the bidding timeslot, a bidder is randomly selected (using [randao](https://github.com/randao/randao) ?).
### Proposal 3
Combination of 1 and 2: The bidding amount can be selected freely, choice is made randomly, but based on the bid weighted amount.
Thus somebody bidding more has a higher chance of getting the next slot.
### Comment
I would slightly prefer proposal 2, however without id authentication this can be gamed by somebody bidding more then once, essentially resulting in the same outcome of proposal 3 - except that honest bidders are disadvantaged.
## Fund allocation
In order to show the power of smart contracts, we could make that a bit fancy. For example:
Initially, 30% (?) of funds are allocated for covering cost. Those are again split up among the people contributing to the project and ongoing expenses. E.g. a small amount for the server hosting the web application and a small amount for Kunsthaus for electricity (whatever - if they want it).
The retribution for the one time cost (development) could be capped, such that it doesn't become a rent like payment. The cap may however be above the cost (e.g. +100%) to compensate for the risk of not getting any/enough compensation.
Once the contributors are paid out, this 30% are reduced, probably to <10%.
The remaining payments go to charity. Here we could add an option for every bidder to choose one (default: random selection).
We may check a cooperation with [Helperbit](https://helperbit.com/) for getting the donations to their destination.
The point to be made is that all this claims can be made transparently, because it's coded. I'd propose a subsite *how this works* where the contract code is shown and explained to non-devs line by line / function by function. With link to the Blockchain Explorer where one can verify that's what's deployed.
## Web application
I think the game should play in the browser in realtime, with the webcam view added as in a passive manner (as it will lag behind).
*To be continued*
## Naming
*City Gameboy* is probably not the right term. I was thinking about *City Slot Machine*, but it isn't a slot machine either. What is it? How were those devices named?
## Bidding
There's a bidding timeslot (something between 1 and 5 minutes?) before every game run.
The website always shows either a countdown for the next bidding slot or the bidding interface.
The bidding interface includes a live stream of incoming bids, similar to the incoming transaction stream on Blockchain Explorers.
### Proposal 1
Simple auction: whoever bids most gets the next game slot.
### Proposal 2
Random selection: The bid contains a fixed amount (e.g. 0.1 Ether).
After the bidding timeslot, a bidder is randomly selected (using [randao](https://github.com/randao/randao) ?).
### Proposal 3
Combination of 1 and 2: The bidding amount can be selected freely, choice is made randomly, but based on the bid weighted amount.
Thus somebody bidding more has a higher chance of getting the next slot.
### Comment
I would slightly prefer proposal 2, however without id authentication this can be gamed by somebody bidding more then once, essentially resulting in the same outcome of proposal 3 - except that honest bidders are disadvantaged.
## Fund allocation
In order to show the power of smart contracts, we could make that a bit fancy. For example:
Initially, 30% (?) of funds are allocated for covering cost. Those are again split up among the people contributing to the project and ongoing expenses. E.g. a small amount for the server hosting the web application and a small amount for Kunsthaus for electricity (whatever - if they want it).
The retribution for the one time cost (development) could be capped, such that it doesn't become a rent like payment. The cap may however be above the cost (e.g. +100%) to compensate for the risk of not getting any/enough compensation.
Once the contributors are paid out, this 30% are reduced, probably to <10%.
The remaining payments go to charity. Here we could add an option for every bidder to choose one (default: random selection).
We may check a cooperation with [Helperbit](https://helperbit.com/) for getting the donations to their destination.
The point to be made is that all this claims can be made transparently, because it's coded. I'd propose a subsite *how this works* where the contract code is shown and explained to non-devs line by line / function by function. With link to the Blockchain Explorer where one can verify that's what's deployed.
## Web application
I think the game should play in the browser in realtime, with the webcam view added as in a passive manner (as it will lag behind).
*To be continued*