search

Gyoo / LiveSplit.SplitsBet

GitHub for the LiveSplit plugin SplitsBet, the bot that makes the viewers play with the runner
8 stars 10 forks source link

Implement a new Scoring System #20

Open CryZe opened 9 years ago

CryZe commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/Gyoo/LiveSplit.SplitsBet/issues/20#issuecomment-106691921 .

Gyoo commented 9 years ago

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 commented 9 years ago

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 https://github.com/Gyoo/LiveSplit.SplitsBet/issues/20#issuecomment-106699722 .

szong commented 9 years ago

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.).