cptn-solo/woffler_contract

Woffler game EOSIO contract

woffler_contract's Issues

Level generator

Generate level with green and red cells, and pot balance. Append the level to the branch from the context of level generation (root branch creation: fill level's pot with branch owner's stake amount).
NB: may be adding a field for "branch starting balance" to (new, root) branch would be more clear and would separate branch creation logic from branch launch logic. Should think before implementation.

Simple GUI for turns as they are not visual with binary levels.

1. integrate with scatter/local sig-provider;
2. list root branches (pickable);
3. display:

• current level's map and pot
• previous level's map and pot
• next level's map (if exists) and pot
• branch winner
• current position and state
• try position and state

4. buttons:

• try
• turn
• next
• take
• un-jail
• claim green
• claim red
• claim take

Add class for player to implement validation logic in more reusable way

Now many actions perform almost same checks for player permission to do something, like check for current state, level, stake in branch, etc.
This logic can be implemented as player state check in player class.

Create Contract boilerplate using EOS Studio

`Unjail` action with payment and stake processing

Fix cdt

Initially tried link to setup cmake, but include warnings was fixed by renaming symlink from eosiolib to eosio

Consider change of revenue share policy

Root branches are missing its part of profit and the rate of branch share in level's profit not defined.

Branch switching

Set active branch and level for player. Player state initialisation.

`Split` action (`splitlvl`)

Consider using user provided seed for level generation or other sensitive actions required randomness.

1. Now ceed is derived from account, id of the level and block time. All are pretty easy to use to predict turns result.
2. There is a possible gameplay scenario where game can be started between several players staked on the branch being played. Branch pot became something like table pot in poker game. Contract can get hashed secrets from players upon staking and verify these secrets upon payment (claim from vesting balance as an example point for verification).
3. Some queueing can be implemented to let next player verify secret of previous player upon next player turn/stake/take/etc.

Add staked funds to root level (if exists) of staked branch while staking via stkaddval

Show try/commit turn actions workflow in IA model.

Add tables to contract

Will start with tables to get some feedback for the class diagram from #3.
There are not that many tables. Will create all of them, and after that will think on actions implementation sequence.

Add contract's 3% in each root branch stake

As it was stated in #17, contract gets Const::houseShare% of stake value in each stkaddval action made on root branch. Level's pot get's total staked value, only stake record gets split.

Level generation algorithm optimisation

#29 shown that 30ms max-transaction-time is not enough for current implementation. Need to try to defer some logic (unlock using vector intersection check) or to change cell storage logic - implement binary approach for cell generation and intersection checking. The latter will lead to some limitations in branch design (fixed length levels), but will also greatly simplify the level concept and improve performance dramatically.

Add some distribution algo for cell generator

we need green and red cells distributed around the level somehow

Registration

Action to create an account in the game contract without any balance yet.

Implement deferred transactions queueing

For each deferred action (tipbranch, tipstkhldrs, tipchannel) there should be a queue for transactions with sent/date flag set by a deferred action if fired. These queues should be processed each time upon revenue share event. More to say - revenue share itself should only place deferred transactions to the queue and then initiate processing of it. This approach will give deferred actions another chance to fire if for some reason it was not initially.

Handle TAKE state in `tryturn` action

Next level without winner or just zero position in the current level

`Claim red` action, reposition player after "RED"

Add check to signup to deny specifying "self" as a sales channel

Balance management (dep/wdr)

Enable processing of transfers send to contract:

• account creation upon funds received;
• account balance top-up with transfer;
• withdraw player's funds to his own account;

Logical and physical Data models

Will work in the same Draw.io file where Game loop models where made

`Claim green` action for ones gave up trying to unlock/extend branch while in green position

When splitting a branch, retries count runs out and player stays in position without available free options. To continue playing, someone will call claimgreen action to reset his position in the current level (zero, retries count restored).
This action's logic is basically called from the last attempt to unlock new level of a branch in next workflow and while unlocking a split branch and no retries left to continue trial without payment.

Sales channel table

Channel existence check and height update upon each signup.

Decide if solve autogenerated red/green cells overlapping should be a (paid while in split) trial

Solve overlapping of two vectors is not trivial task in terms of efficiency/algorithm development.
For split action generation of green cells, compatible with set of red cells is a trial and basically a paid feature.
Generating non-overlapping sets of red/green cells by contract can be non efficient and lead to action termination by a node due to transaction timings.
Suppose cells generation process for root level should be free as there is already a staking process in place.
Cell generation process for next level can be a matter of gamification. For example, a player solved level and decided to go further (which launch a level generation process in turn), can have same 3 retries to generate new level with appropriate cell sets. After retries count goes zero, player can be either jailed, or returned back 1 level, or just positioned to the level's base and try to solve it again.

Any gamification will be chosen, vector comparing algorithm should be implemented using bitwise operators to perform efficient comparisons. Later this same algorithm can be used to check if player's trial ends up with red or green cell. Storing cells as binary mask would be a good idea too - we can just convert vector into bit mask. But the generation process itself organised using "steps" concept is good and gives more dispersion to cells distribution, and offers to control quantity of reds and greens in the given level more accurately.

Another (vector) approach is vector intersection checking, which is more flexible and can allow simple implementation of big (long) levels.

Try to implement cursor-like reference for an object representing class data (wflPlayer/wflLevel/wflBranch, etc.)

Now class members are just copy values from structs made private and it is requires sync of values of that members each time we modify the underlying object.
It would be better to implement a reference/pointer on the object's instance data to avoid syncing which is obviously a bug prone approach.

`Take reward` action with pot balance processing

Turns (try/turn)

Implement trial logic - generate random number for "try position", count retries, enforce turn upon retries finished.
Implement turn logic - switch try-current position, commit turn result and timestamp.

Add referrer field to IA (players table)

Initial model is done: added sales channel to logic data model and to the TAKE flow.
So far we have revenue channels for participants:

1. Staking on branches for passive income: quests bought by advertisers, and then unjails payd from ad budget and go to branch stakeholders; Also counts unjail payments made from players balance.
2. Splitting branch is generating revenue for branch stakeholders too if new branch wasn't unblocked for free.
3. Referral income from being a sales channel is paid from branch budget on each TAKE made by referral (player brought to game by sales channel owner - referrer); This will lead referrer to advertising TAKE option and balance 1 and 2.

The question is, would the balance be correct and how to balance game win-win business model.

Consider adding unjail/untake logic into try/turn.

It could be done by check for timespan between level result and now() - if interval of jail/take where finished, then player state can be changed according to level result as if unjail/untake were claimed by specific actions.

Implement root level cells regeneration action for stakeholders of branch (now admin option)

Regeneration action must be available until level is unlocked. After non intersected red/green combination is found, level marked as unlocked and can be played.

Enable contract's account registration as a player to make it possible to claim revenue on stake and on sales channel

RegisterStake: Add case for already existing stake for the given owner and branch

extend the implementation for registerStake - (add balance via record modification in addition to emplace, which is done for now)

`Bet for split` action (`splitbet`)

Decide if a reward taking player should be promoted to the next level or not.

If a player selected an option of taking reward, he should solve a level once again to make another selection next time. Suppose claimtakeaction should position player on zero in solved level instead of promoting him.

Creating a Root Branch

Create branch before level generation, branch metadata processing. Stakeholders management for created branch (add contract as a stakeholder with 3% contract's stake)

Add params and storage of level presets

new fields added to models but not to the sources

Finish refactoring of currently implemented features (accessor/entity pattern)

Add check for maximum level length

Decide on enabling staking on non-root branch and contract share in non-root branch

Staking on non-root branch is ok and will unify the workflow of adding funds to levels - no matter root- or sub-branch is created, it's root level needs to be funded and the branch itself needs to register its stakeholders.

Question of adding contract's (house) stake to the non-root branches is more interesting.
On one hand is unification - when a branch is added, the player should stake on it, while contract should process his funds: subtract player's active balance, append stake to the branch and move funds forward to the level's pot. Each such transaction can be easily split at house share rate (say 3%), stake can be registered as 97:3 and total value (100%) then moved to the level's pot.
On the other hand, if this procedure is taking place in each branch staking workflow, and not only root branch, the house's share in business became too discrete. Anyway, there would be a hierarchical revenue share implemented and some part of child branches' revenue will flow upwards in any case. May be house' stake in the child branches is an excess.

Decide if referrer removal should move his referrals (if any) to contract as new referrer.

Until decision made, #44 is in effect (block account removal if referrals present).

`Claim take` action

Add check for branch meta usage before delete/modify

Game flow models

Prepare draw.io models to outline main subject-object interactions.
Same model file is pushed to the IA folder in contract source files.

Unify and describe unlock procedure of the split branch

Actually there are 3 actions involved in branch split process:

1. split (splitlvl) - split branch from green cell if there is no split yet in current level;
2. unlock (unlocklvl) - use retries (free or payed) to unlock new level;
3. bet for split (splitbet) - get additional retries by making a payment;

Switch referrer to contract upon referrer's account removal.

Handle RED state in `tryturn` action

Zero position in the current - or even previous if exists - level

Next level generation with pot balance processing

Decide on `rootlvl` action's scope

Action to create a root level is required anyway - for root branch initialisation or sub-branch. So the decision is - this action should work both for root- and sub-branches equally.