ChessFX
-
Number of $FX requested (incubator fund): 80000 $FX;
-
Proposal belongs to which segments: Developer Fund;
-
Incubator fund distribution timeframe and milestones.
-
Distribution timeframe: 80k ideally across 6 months.
-
Milestones:
- 1st stage - 10k $FX - 1st month - initial development, plan and architecture (encoding chess board and other challenges), setting up test environment
- 2nd stage - 10k $FX - 2nd month - encoding flow of chess movements between contract instances for 2 parties, adding rules, time limits, code optimization, basic functionality
- 3rd stage - 10k $FX - 3rd month - bids, reward pool logic, contract or backend validation of chess board and moves, penalties for invalid moves, web library and some interface to interact with
- 4th stage - 10k $FX - 4th month - smart contract code deployed and ready for testing by users on testnet, initial testing, fixing issues and inconsistencies, bug fixes
- 5th stage - 10k $FX - 5th month - solving final challenges, optimizing smart contract (to cost less, especially heavy calculation functions), finalizing for production, backend service, bug fixes, and edge cases
- 6th stage - 10k $FX - 6th month - deployed on mainnet, users can test and report any issues, inconsistency fixes, web interface improvements
- extra 20k $FX - cloud and server costs, backend services, domains, docs and other resources, extra risk for the unknowns and bugs.
Notes:
- Estimation for each month (20 working days) is based on ~500fx/day (dev/team and to cover other IT costs).
- The overall cost is based on the predicted complexity of the project. There are so many challenges and scenarios to solve.
-
-
Proposal details.
-
Name of the proposal: ChessFX (short for Chessmaster FX)
-
Description: Chess game that can be played by both parties with an initial equal bid. Winner gets rewarded.
Details: Two users decides to play chess (their game state is tracked by a smart contract). There is an initial cost requirements to start a game (a bid), then each user submits their next moves. The winner wins the total reward sum of ~198% (minus 2% maintanance fee).
-
Mechanics: Game can be played via web interface which interacts with Chess smart contract receiving and updating the state of the game. Each player move creates a separate contract instance (by sending encoded chess board or by updating figure positions). Wrong moves are going to be rejected (we could have some penalties). At the end of the game, the winner is rewarded. In case of a tie, reward is split equally.
-
Questions:
- What time limit should be specified between the moves? Should initial user decide and specify the limit (in minutes) according to their skills?
- If each player’s move cost gas, how much the total game is going to cost (short vs long games)? So users should take into the account the initial bid to be higher (to cover the total network fees).
- Should we add option to allow people undo their last moves for extra tokens, increasing the reward pool (could be approvable by the opponent)?
-
Challenges:
- Validating each move or a game’s end (whether king is in checkmate or in stalemate) can be too costly for the smart contract to run. This should be optimized or be outsourced for the backend service which should be validating each moves and scanning for the end game scenarios. Can we code it using a smart contract? We’ll see.
- Are we going to have cheaters by copying moves from the computers? Should we worry about it? Definitely nobody wants to play with some Deep Blue. Maybe some captcha to solve between some random moves? Another workaround could be to create some kind of player statistics, so weaker players can avoid 100% winners. And 100% winners would love to play with other 100% winners for the higher bids. But then what if 100% winner (strong player) will accept the game from 50% winner (weaker player)?
- I did initial research and some team of students tried to implement chess for ethereum few years back, but it was reported that contract/block processing (each move) was very expensive and taking too long (let’s hope FX can fix it). Check the following blog for more details: Lessons learned from making a Chess game for Ethereum | by Paul Grau | Medium
- Should smart contract be validating the right moves and states at the cost of contract? Or backend service should be validating it? Or give opponent ability to report invalid moves (to save costs), however, we can trust him?
-
Proposed features (optional at the later stage):
- Leadership published on the website (statistics like number of games played, best players based on their public addresses and names, and so on). So people could choose their games more wisely according to the player level (so weak players may decide to avoid 100% winners).
- Tournaments, like 16 people plays with each other (each with 100 $FX entry), then the winner gets the whole reward (~1600 $FX).
-
Benefits to F(X) ecosystem: It can be beneficial for both participants and contract owners.
-
Team: kenorb (kenorb (Rafal W.) · GitHub & User kenorb - Stack Overflow) and team.
With over 30 years of software engineering experience, I specialize in variety of technologies, programming, tooling and delivering complex projects.
I’ve been working for large enterprise companies, including a decentralized blockchain company for the enterprise clients across the globe.
My recent personal project includes free and open source Forex trading robot which was developed across many years.
-
-
Reasons why the project should be selected and supported and included an analysis of the competitive landscape;
Reasons:
- Open source code smart contract and free to use by anybody.
- People can get paid for their chess skills.
- Transparent progress during stages.
- Once this project is implemented and challenges are solved, can be expanded to other games such as Go, etc.
The proposed project is more competitive, because:
- FX blockchain can be more suitable for this game, more competitive comparing to others (such as Ethereum) where the game could be much more costly.
- It’s decentralized, no relying on 3rd party games or websites being down.
- Users are rewarded for being smart and their skills by playing a chess game.
- Rules and rewards are protected by the smart contract code.
- Nobody can shut down the service, cheat or take the tokens away.
- Transparency of reward logic due to open-source code.
- Due to open-source nature of the code, anybody else could verify the code or use it to deploy the contract for themselves.
-
Include attachments, such as GitHub links, product prototype, video, planning, blueprint, twitter, etc.
- GitHub: TBC (kenorb (Rafal W.) · GitHub)
- Product prototype: on request
- Blueprint: on request
- Twitter: not needed
- Videos: on request
-
Additional information;
Scenario 1:
- Alice creates a chess game instance with a bid 100 $FX with her first move starting with figure color of her choice (this creates a first contract). People starting a new game can decide on the initial proposed bet amount and color of their figures.
- Bob accepts the game by sending his move as the response to Alice with 100 $FX (he creates 2nd contract which got the reference to the Alice first contract).
- Reward pool is 200 $FX.
- After Bob accepted a game, the contract locks this game for only these 2 participants. If anybody else who sent anything after the Bob’s move, $FX are added to the reward pool as extra reward.
- Alice needs to response with her next move within X amount of time (5min? 1h? 24h?).
- Same for Bob, who needs to response with his next move after Alice completed her move.
- At the end of the game, the final Bob’s move result in the checkmate of his opponent and he wins the game (end game validated by the algorithm).
- Bob can request the reward of 196 $FX (-2% maintanance fee).
Scenario 2:
- Same situation as above, but final move result in stalemate.
- Both parties can claim 148 $FX back (-2% maintanance fee).
Scenario 3:
- Alice creates a chess game instance with a bid 100 $FX (as white).
- Bob accepts the game by sending his move (as black) as the response to Alice with 50 $FX.
- Since bid sent is not equal to Alice bid, smart contract rejected Bob’s move (and awaits for further bids). Normally this shouldn’t happen via the web interface due to frontend validation.
- Smart contract now awaits for another valid move from blacks, this time with 50 $FX left (this logic to be clarified).
- Bob accepts the game again by sending his move (as black) as the response to Alice with 100 $FX (not knowing he could send only 50).
- Reward pool is 250 $FX.
- The winner gets the entire reward pool (-2% maintanance fee).
- In case of stalemate, sum is split equally.
Scenario 4:
- Similar situation as above.
- In the middle of game, Bob didn’t respond with his move within agreed X amount of time (5min? 15min? 24h?).
- Alice can claim the reward after the deadline (and she’s announced as a winner).
Scenario 5:
- Alice creates a chess game instance with a bid 1000 $FX (as white).
- Nobody responded to the game within a deadline as the bid is too high for some (e.g. within 24h).
- Alice can claim her original bid back (minus fees) after the deadline.
Note: Above scenarios are not finalized yet and the logic and interaction can be adjusted along with more research and time spent based on the known possibilities and limitations of the smart contract.
-
Licensing: MIT or GPL (open to suggestions).
Included open-source code: smart contract code, JS library (if required) required for the website. Access to code will allow people to deploy their instances of smart contracts and verify the game logic.
Do not delete this part
Disclaimer: This poll is just a tool to get the sentiment around this proposal and it will NOT affect on-chain voting in any way. If your proposal is getting a good sentiment around the community, it might signal that the proposal is good to go to the next phase, otherwise, some modifications might be necessary.
- YES
- NO
0 voters
and we combine our projects 