Implement a new Scoring System

[CryZe]

The current Scoring System punishes people for not participating in betting on every single split by giving them a score of 0 which is even worse than a score someone gets who is participating, but is horrible at guessing the times. So at the moment, this results in the people who participate the most, leading the leaderboards even though the might not be the best at guessing. An alternate approach of giving out the Scores is thus necessary eventually.

[Gyoo]

After discussing a bit with Cryze, it appears that our opinions diverge on ho to manage the scores. I agree that the current score system isn't totally fair to everyone, but at the same time I don't exactly know how to improve it.
Also, I try to think "big" already, and by big I mean that I want to have something that will be good when I may be gathering the information from whoever uses SplitsBet and centralize everything on a web platform with stats and such. It also shows the problem of the customization : If people can customize things like the unbet penalty, the system is not the same from a stream to another and the data collection is somehow screwed.
This is a big debate that we'll have to have at some point, the earlier the better, but maybe after the first public release that should come very soon(TM)

[0x0ade]

An option would be to move the settings from the component to the web
server and a select group of service moderators would manage these
settings. Obviously people would be able to circumvent it simply using
custom versions of SplitsBet, but I guess you don't want a central server
to handle every bet command of every channel due to the possibly high usage.

Also, moderators and / or a "report streamer" function on the website would
be profitable in such cases instead of simply hoping that everything will
go well. Streamers that would completely circumvent the settings could get
banned from the global scoring system.

Finally, what about people betting on two streams at once? Which stream
would count? What about score updates while betting? Getting the score from
the server upon any action of the user instead of a per-run basis would be
a solution, but again, I don't know how much you want to reduce server
load. Send and update scores every round? Or instantly?

I'm sorry in case I am of no help in this discussion as my suggestions are
quite obvious, but in my opinion it is not bad to - at least - put them
into this discussion and to know about what scale you are talking about
when you say "big". (Should the server handle everything or is it just a
decentralized web platform / global scoring system?)

Gyoo notifications@github.com schrieb am Fr., 29. Mai 2015 07:21:

After discussing a bit with Cryze, it appears that our opinions diverge on
ho to manage the scores. I agree that the current score system isn't
totally fair to everyone, but at the same time I don't exactly know how to
improve it.
Also, I try to think "big" already, and by big I mean that I want to have
something that will be good when I may be gathering the information from
whoever uses SplitsBet and centralize everything on a web platform with
stats and such. It also shows the problem of the customization : If people
can customize things like the unbet penalty, the system is not the same
from a stream to another and the data collection is somehow screwed.
This is a big debate that we'll have to have at some point, the earlier
the better, but maybe after the first public release that should come very
soon^TM

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

[Gyoo]

I think it'll be better to send the scores when a run is ended (completed or reset) because things can happen during a run (especially skipping/undoing splits) so it would be a mess if the scores are sent "live" or very frequently.
Therefore, I don't think playing on several streams at a time should be an issue : You just have your local score on the current stream(s) and then the result is sent to the server. I'm not sure that retrieving the score from the server at the beginning of a play is useful.

[0x0ade]

Turns out that was just a slight misunderstanding on my end then. I thought
the users have one score to share on every stream, but just as you
explained it, it rather seems like the users have a score per stream and
the sum of all scores is the "global score" which I meant.

Gyoo notifications@github.com schrieb am 07:59, Fr., Mai 29, 2015:

I think it'll be better to send the scores when a run is ended (completed
or reset) because things can happen during a run (especially
skipping/undoing splits) so it would be a mess if the scores are sent
"live" or very frequently.
Therefore, I don't think playing on several streams at a time should be an
issue : You just have your local score on the current stream(s) and then
the result is sent to the server. I'm not sure that retrieving the score
from the server at the beginning of a play is useful.

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

[szong]

Just a small comment here:
Any big ideas (centralized server, bot, etc.) should be ignored for now until functionality is complete.
Focusing on the foundation is good, but without a proper idea of what features to include it'll bring up more problems than needed.

Regardless, to sum up the alternatives:

1. Centralized server that keeps all the scores (SPOF warning) with a unified scoring system (seriously not recommended since it limits personalization).
2. Centralized server that keeps all the scores (SPOF) with a per-user scoring system (much better, some overhead but still the ideal choice)
3. Scores kept locally on users using the program with unique scoring systems

Implementation-Specific on Score Upload if using a Centralized Server:

1. Upload scores per split - more requests, can bottleneck server without good architecture, but very reliable
2. Upload scores after run - less uploads so less load, but does not allow partials
3. Scores saved to file, then uploaded - Probably the best of both worlds.

Either way, (1) gets screwed over since you can't verify what scores are really "good" or not. I suggest (2) as the best option for a "real system". Again, we should still focus on fixing everything else first (e.g. skipping splits, resetting, etc.).