Open xavierlepretre opened 4 years ago
I think it's currently encoded in (derived from prepopulated data) in the SQL tables of the PHP implementation.
I suggest you use a fixed (hard-coded), or trivially-configurable, amount for the payout, initially,
Assuming we agree it is a fixed payout (i.e. which depends only on the random number, and doesn't depend on how much is in the "pot") then IMO this is low-risk, relatively uninteresting, deferrable bit (in that it is non-Corda logic).
Correct, non-Corda logic. I think best left hard-coded for now: random number -> absolute payout.
As per our live discussion, an absolute payout allows for parallelism.
The following (SQL) defines the preconfigured default game logic (data parameters) -- i.e. the probability of each prize, and the reel positions corresponding to each prize.
Let's use this for now.
Do you want to support a variable-sized bet (e.g. 1..10) or hard-code it as 1? The front end can support either (variable or fixed).
I propose to (or you could) hard-code this data using Kotlin (for the game contract) and again using JavaScript for the web front end (in theory we could fetch this data from Corda into the JavaScript via RPC, instead of hard-coding it in the JavaScript, however IMO that's not an immediate requirement).
INSERT INTO `luckscript_slots_game_types` (`id`, `enabled`, `min_bet`, `max_bet`) VALUES ('default', 1, 1, 10);
INSERT INTO `luckscript_slots_prizes` (`game_type`, `reel1`, `reel2`, `reel3`, `probability`, `payout_credits`, `payout_winnings`) VALUES
('default', 6, 6, 6, 0.0003, 200, 200),
('default', 4, 4, 4, 0.0015, 50, 50),
('default', 2, 2, 2, 0.0035, 20, 20),
('default', '1/3', '5/2', '4/6', 0.0045, 15, 15),
('default', 5, 5, 5, 0.0055, 13, 13),
('default', 1, 1, 1, 0.0080, 12, 12),
('default', 3, 3, 3, 0.0100, 10, 10),
('default', '1/3/5', '1/3/5', '1/3/5', 0.0900, 4, 4);
The odds of winning something are 0.0003+0.0015+etc.+0.0900 = 12.33%
To calculate winnings, pick a random number from 1 through 10000: If the number is 1..3 then you win 200. If the number is 4..18 (i.e. 3 + 1..15) then you win 50. etc.
Having calculated the win, then calculate the reel position. Sometimes the reel position is fixed e.g. [6,6,6] Sometimes it's one of several i.e. ['1/3/5', '1/3/5', '1/3/5']
I assume the contract is unable to calculate a random reel position. So instead:
So the only data which needs to be encoded in the Kotlin contract is a list of probability/payout pairs.
Plus these (hard-coded) payout values must be known, i.e. as expected by the JavaScript, so that it can assign a reel position corresponding to the received payout.
So we'll modify the GameResult, the remove the reels
. Or in fact the contract doesn't need the GameResult
type at all -- it only needs to return an integer (i.e. the payout) -- unless it might alternatively also need to return an error message, in any circumstance.
I'll take over what's in the payout-logic branch.
I updated the implementation of the logic i.e. https://github.com/xavierlepretre/corda-slot-machine/blob/payout-logic/contracts/src/main/kotlin/com/cordacodeclub/data/PayoutLogic.kt
I didn't update the tests (so they don't build), but that's what the payout logic should look like.
The result is just an integer, i.e. a payout value -- either 0, or one of a list of well-known winnings (e.g. 200, 50, etc.) for which the JavaScript has corresponding reel positions -- that's what the contract should expect and work with (I assume this object is part of the game contract).
JavaScript will calculate the (possibly-random) reel position, given only the payout.
The slot machine generates a random number. From this random number, a fixed payout is calculated. We need this non-Corda logic.