Predefined Deck Challenge
Challenge a deck built by other players created for a challenge with custom rules and rewards.
Requires and relies on the followings:
• direct match code — exists already
• card-proto-, user- and match API — exists already
• a designated challenge smart contract
• either AI to play the predefined deck or a scheduling solution for real players on both end.
The Challenge Contract
As provider, anyone can define a valid 30-card deck, of which all cards are owned by the challenge creator and generates a ‘direct match code’ that will be published and exposed to a smart contract that — broadly said — coordinates the conduct of such challenges, listing available challenges to be challenged by interested challengers along with further details, such as reward for beating the challenge, fees to sign up for a paid challenge, expiry terms, etc. explained in details further down.
As client, anyone can pick up any challenges previously provided to the smart contract to attempt to beat and earn the prize(s) it offers or — after no reward left — simply for prestige.
Challenges in details and the Proof of Zero-Violation
The creator of a challenge requires all cards to be owned and locked so long as there are prizes to be won, in other words, until there are any form of gains attached.
Locking cards to a challenge holds the potential giving a valid reason to own more than 2 copies of a card.
So the challenge creator is defining a set reward for beating the deck created and locked and a certain fee to be paid by clients, who are interested enough to sign up for the challenge to compete for the prize(s) upon beating the challenge.
Whether it’d be the first one to beat the challenge for a unique reward or split a reward pot in equal shares to allow many challengers to attempt to beat it, is only a matter of preference, meeting demand of desirable risk/reward ratio, the imagination and the limits of possibilities.
Type of Prizes and Rewards:
• fungible reward as an amount of Ether or Flux
• ownership or temporary use of cards
• trinkets, arenas etc.
• even qualification ticket for another challenge (?challenge-chain)
Restrictions and Validation
As decks are submitted prior to the match, meaning one can be prepared for the match against the challenge, is what becomes the challenge of the challenge creator to define restrictions of what god, god power, cards (by proto id) are allowed to play for a successful validation of a challenge. Furthermore, terms of what makes a challenge to be beaten is not necessarily just beating opponent but for example, it could be surviving for x turns, win with x hp remaining etc. rendering it as another custom difficulty factor for challenges.
1. the composition of challenger’s deck
the possible variations of deck compositions restrictions are vast and outlined in a separate document.
2. meeting eligibility conditions
• have played a total of x number of matches
• minimum level of x
• ownership of a trinket, a type of trinket or a trinket with common property
• qualifying and entry tickets
3. meeting certain condition(s) in results of match that is currently recorded and publicly available to validate
• win the match within x turns
• survive the match for at least x turns
• win the match with at least x remaining health
Validation
Validation has to be the simple and rock-solid set of rules with priority on simplicity over convenience and what is ideal.
1. challenges subject to this contract are to be designed as a single player experience of the challenger and the predefined deck is to be controlled by CPU/AI uniformly. Alternatively a scheduling solution if aiming for a two-player experience.
2. the generated direct match code is equivalent to the id of a challenge, that is meant to be (re)used by challengers. Once a challenge has been submitted to the contract, it is final and remains the same until last.
3. anyone shall be able to play the match of a challenge regardless of eligibility or restrictions and even so if challenger fee is not paid.
• the validation takes place post-match.
• if and when all requirements are met, which are outlined before the match and restrictions are fully adhered to (the challenger’s due diligence and responsibility) along with the validation passes successfully, the prize for beating the challenge is won.
• a challenge can be still considered unsuccessful when all requirements are met (aka. challenger was in fact, competing with real chance to win the prize) although it unfortunately failed to beat it, it still be recorded and the creator of the challenge earns the challenger’s fee paid upon calling the contract for the direct match code.
How?
The current card-proto, user and match API already provides the records required to validate all details mentioned so far and it also underpins how restrictions settings could be defined. In brief, by listing all non-restricted elements as the range, wherein to look for each relevant information of a challenger to establish proof of zero-violation.
The only thing that is not available yet is pre-defining a god power for a deck by the challenge creator.
Potential for even more financial means:
The reward pot shall be available to be topped up by original provider and remain the beneficiary of the challenger fees or it shall be allowed to be topped up by anyone else to fund rewards and become beneficiary of the challenger fees minus a fair cut to the original provider who created.
In case there’s funding being topped up from multiple sources, the original provider should retain its first priority to earn as long as that covers any successful challenge, and only once the original provider’s funding is depleted, let others to become the beneficiary of challenger fees.
