Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Code for bundle split proportional to full price (APL)

A topic by Arekku created Dec 17, 2020 Views: 182 Replies: 2
Viewing posts 1 to 3
(+1)

When doing a co op bundle you get to decide how to split the revenue. One way of splitting the revenue that seems fair to me is to base it on the pre-sale prices of the individual products.

So you basically sum it all up, then divide each contributor with the total sum. This works fine for when the results add up neatly to 100%.

This is not always the case, so I elected to solve this issue by a brute force error minimization method. There are some edge cases where this algorithm fails, one instance is where 3 contributors all have the same price. The algorithm is written in APL.

ret←bundlesplit arg;raw;rounded;error;misrepresantation;perm;mrcurrent;try;i;unique;index
raw←{100×⍵÷+/⍵}arg
rounded←⌊0.5+raw
error←100-+/rounded
:If 0≠error ⍝ Handle case where things doesn't round up nicely
unique←∪arg
misrepresantation←raw∘{+/|⍺-⍵}
mrcurrent←10000
:For i :In unique ⍝ Try every permutation
try←rounded
index←(i=arg)/⍳⍴arg
:If 0≠(⍴index)|error
:Continue
:EndIf
try[index]+←error÷⍴index
:If mrcurrent>misrepresantation try ⍝ Our new distribution is better than our previous best
mrcurrent←misrepresantation try
rounded←try
:EndIf
:EndFor
:EndIf
ret←rounded

Input to the function is total pre-sale price for each contributor, for instance 5$ 14$ and 7$

bundlesplit 5 14 7
Will output
19 54 27
This example rounds up nicely. However if the bundle prices were 5$ 5$ 1$, you would get 45 45 9 without the extra rounding handling. 45+45+9=99 is not 100. The output of this function is however 45 45 10 as it solves the issue by adding the extra 1% to the third participant causing the numbers to add up to 100. As stated before, it can not handle 3 equal contributions and will just output 33 33 33 as there is no way to split this evenly.

(1 edit) (+1)

Itch really doesn't like inline code. I realized if you were getting 2% of the cut, you are not going to be very happy if this decides to make your cut 1% just to round things out. Therefore I would like to replace the misrepresentation function to

misrepresantation←raw∘{+/|1-⍵÷⍺}<br>

This will make the algorithm favor evening out on contributors getting the biggest cut, as the relative change for these people is the least. For instance going from 80% to 79% is a lot better than going from 2% to 1%.

Brilliant!