Multiline Games Do Not Pay Extra for Scatters

[lmstearn]

The motivation for this was by design, and made so long ago the precise reason is not recalled, so here goes:
The calculation of scatter prize amounts for a single Payline game is based on the random chance a Scatter appears in any of the 3 visible lines.
This method will work for successive Paylines only if they do not share any lines used by previous scatters. Which implies revealing more paylines on-screen. So for scatters on a second Payline, we'll be looking at six lines, with the main Paylines now being the 2nd and 5th.
If we allow any intersection or sharing of Scatter combinations, it then establishes an order a priori between the Paylines, so they are not random anymore, skewing the new Prize Amounts in proportion to their no-scatter counterparts.
In this example, the 2nd and 3rd Paylines are not randomly selected, but fixed in their positions wrt the first Payline.
The calculation of scatter prize amounts applying to the second or third line must involve a different and much more complicated method than the one currently used, whether or not the lines for calculation include those off screen. Calculating a scatter for a Payline implies the line above and below the Payline, as is already the case with the middle Payline.
We can always hope in vain to prove that, over a large number of plays, multiplying the middle line scatter prize amounts by the number of Paylines is equivalent to simply increasing the bet on the middle Payline by a similar quantity.
The larger the number of scatters per reel, the more the issue is brought into focus.
For games where scatters are the only symbols in play, this is not an issue.

[deathssoul]

I'm looking for the the relevant code and I need to ask: which file is that in? I'm not sure how the code is organized. :P

[lmstearn]

Hey there! It's a bit how's_your_Gaga as far as organization- but kept all the modules in line with the limitation of 64k.
Do a search for SortPrizes, that'll be in Auxrout1.bas, but there are associated routines above that in that module. It's called from the front end form: Pokemach.frm.
It has to be noted that, given Player selects Highest Wins Only Paid, and multiple line scatter payouts are selected as described above, they may then be split for each line, and will look rather odd to the Player.

[deathssoul]

Thanks, I'll take a look. :) I had to go to the hospital today due to fluid in my ear canals (caused me to pass out and dizziness) so give me a day or two to feel better and I'll see what I can do. :)

…

On Mon, Jul 23, 2018, 10:33 lmstearn ***@***.***> wrote: Hey there! It's a bit how's your Gaga as far as organization- but kept all the modules in line with the limitation of 64k <https://msdn.microsoft.com/en-us/vba/language-reference-vba/articles/fixed-or-static-data-can-t-be-larger-than-64k?f=255&MSPPError=-2147217396> . Do a search for SortPrizes, that'll be in Auxrout1.bas <https://github.com/lmstearn/MyReels/blob/master/Code/Auxrout1.bas>, but there are associated routines above that in that module. It's called from Pokemach.frm. <https://github.com/lmstearn/MyReels/blob/master/Code/Pokemach.frm> It has to be noted that given Player selects *Highest Wins Only Paid*, and multiple line scatter payouts are selected as described above, they may then be split for each line, and will look rather odd to the Player. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANRdnRCKxv9wt711EzcZUQuziqnpPXzQks5uJd6vgaJpZM4VX_dk> .

[lmstearn]

That's terrible! :( Back in the day GPs drained ear canals with a syringe- but that was only as a last resort as earwax is very important.
There is a bug floating around as this eustachian tube is inflamed- the (associated?) ulcer on the tongue is gone, so hopefully body has this one sorted. :)
BTW notwithstanding many commercial machines pay multiline scatters as described, this issue is more of a "policy" imperative more than a coding flaw.

[deathssoul]

I have bad sinuses so they thought that was the cause of it. They gave me some medicine that will hopefully help to clear things up. :)

Okay, I'll need to do some reading as well to make sure I fully understand the concept. I thought it was just a simple matter of checking if one thing was also visible as well. :P

[deathssoul]

Okay, I think I've got it figured out on my notepad. Give me one more day to type it up as I only got a few hours of sleep last night. :-P

[deathssoul]

Sorry, ran into some trouble updating Windows today. Here's what I've got:

Assume we have a list called Scatter.
Cell is defined as:
Cell { row; column; value; }

For each row for each column if cell at this point is a scatter then add to list

Iterate through the list.
calculate row_score[Scatter.row] and col_score[Scatter.col]

Iterate through those two lists, summing them up to get the final score.
Basically, we're flattening the lists as we go through them, calculating things based on the weighting.

[lmstearn]

Yes thanks, and it's also when the probabilistic considerations come into play with scatter prizes.
Consider the scatter prizes as some arbitrary mapping based on single line prizes. The sampling changes when we take another payline which, in it's allocated position, has a dependency on the first.
Any scatter prizes for second line would be the same as the first line- except that single line prizes for the second line are now affected by any scatter distributions used by the first line, and scatter prizes for the first line are now affected by the single line prizes on the second line, and so on.
With our arbitrary mapping compromised on the introduction of another payline, an "easy" way of determining the fairest scatter prizes would be to sample all of the possible distributions and crunch out the magic numbers in a Monte Carlo scenario. A gargantuan task.
Getting 3.2 ready- some improvements in the Picture Properties Screen, but the code is still far from optimal.

[deathssoul]

For dependency mapping, you're going to need to use a dependency graph or make Scatters a data-type with dependency linking. For instance:

Scatter {
    depends_on = Scatter2;
}

Or something similar.

You could also do a directed graph. I'm not sure if there are any libraries out there for Visual Basic though.

[lmstearn]

That would be cool, especially in a fair game where the chance of a prize has the same proportion to the prize, whenever it applies to both single line and scatter payouts, not just one.
Edit: That is when

 GPF = constant Global Prize Factor
Prize = probability of prize * GPF

Which clearly doesn't even happen for non-scatter prizes. Which is another issue. :P

[deathssoul]

I can certainly look at graph libraries. Graphs aren't hard to implement, I just haven't worked with Visual Basic much in fifteen years so I'm rather rusty.

[lmstearn]

Thanks. 👍 Graphs were actually considered a long time ago- they might have been a bit awkward fitting into the GUI. The best idea in the long run is a port or a rewrite in a more "modern" language- or just good old C++, or some variant of.
In any case SKSEView is also developing rust- so returning to that is a higher priority.

[deathssoul]

For C++, there are a ton of graph libraries. cppreference lists a few under Graph Theory here: https://en.cppreference.com/w/cpp/links/libs

Apologies, they don't provide links to each section so you'll need to do a ctrl+f for "Graph Theory" as the page is rather long.

Still looking for VB libraries!

[deathssoul]

Not having luck finding stuff for Visual Basic but I'll keep looking. When I search, all that comes up is stuff for C# which is not what we want so I'm not sure how to approach things.