New algorithm for autobalance=auto
n/m <--- There was a long post here that I decided to edit to that because I was terse and one would say, hopefully, most unlike my normal self.
A little preamble
Most of you in this section discussing these ideas where not here for the implementation of AllegSkill and the all encompassing @#(!storm that happened upon it's announcement. It was pretty $#@!ing bad let me tell you. After explaining at least hundred times over again, pretty much all of the items being discussed here, I've grown rather grumpy on the subject matter.
Let's try again shall we with the understanding I will not get into a debate on AllegSkill's worth from an algorithm's point of view. It's rock solid, the best availible as far as Ive been able to find anywhere. This isn't an idle comment based on personal observations and gut feelings but hard core checking of actual game data vs predicted outcomes.
Boiler plate response
I ask that you indulge me a little on this everyone and save the I just know Im right argument approach...just with me of course.... and just on this matter. I'd truly appreciate it since my reply will be each and every time: There were literally hundreds and hundreds of man hours spent in the development of the C++ version of the system from evaluating eight completely different approaches through actually checking predicted accuracy. It requires an actual statistical (and probability) check of the results to determine any systems's accuracy, along with the raw game data. I welcome your efforts and look forward to discussing and reviewing the results after you perform the checks too
General comment
Ok Ive got my happiest face, and most Cheerful Wishes for everyone that I can on. If I've offended you in any way please take comfort in the idea that it was unintentional.
Main section
Im torn between quoting everything or just ther relevant section. For sake of brevity I chosen the later. Please believe I read every word of the entire post(s).
The.ynik: Currenly, alleg offers only 2 choices of auto-balance: balance by player count (#autobalance 1) and balance by total AS (#autobalance auto). Both are fundamentally broken by preventing newbies from joining the team that's up.
This as written is fundmentally flawed way of looking at balance. The balancing of a system doesn't hinge on allowing a brand new player access to the game, a perplexing and challenging issue tbs, but in creating a balanced game play experience as a whole. Allowing a brand new player access to either team simply because they are new is a haphazrd approach with regard to balance. As you touch on later there are two aspects to balance. Team size and player ranks which are locked together quite tightly. How you handle this dicotamy is what makes one system vs another stand out. Im going with you had a touch of MrChaosness and it was a words thing vs an idea thing. Just want to make the point is all.
Imago: just implement it in http://svn.alleg.net/svn/Allegiance/branch/FAZR6/src upload a patch file to trac and we will test it
DasSmiter: I like the way you think
Xynth: this (points back to Imago's comment) I like your algorithm. If C++ is not your thing I may look at it, but you should learn
Freyja: I like that it can block too many newbies on one team. Many comms let imbalance happen from lack of skill or desire to police.
the.ynik: I know C++, but I don't have any time for coding this myself right now (at least not in the next 6 weeks). I'm already working on other open source projects, and on top of that I got this bachelor thesis to write... I just wrote that implementation in JS to get the idea out of my mind into some reusable form.
This exchange more then ANYTHING was what got me so crabby in the first post. It's pretty classic response to people working in their own little cloistured group. It starts with "I've got an idea to solve something that I preceive to be an issue, it will effect things at a fundamental level, but Ive given it a good thunk and like it", (the idea could be the second coming of sliced bread I must say out of fairness). Prefunctional checks to no check at all by the peers and we are already to, "let's do it".
Even more dishearening it is followed by the suggester handing all responsibility for implementation to anyone else (RL is RL no slight meant by not having time). So now you have a back of the napkin idea, being green lighted by the group, and handed off by the person, to be championed by someone who didn't even put the concept together. This is a text book example of how not to implement change and all of us already know it. Ok no harm no foul someone will give a gentle nudge and hint that enthuasism has gotten the better of the group.
notJarvis: To be honest though I would consider sticking with Allegskill's roots and look at the MS Trueskill method of working out Team Skill as...
There we go the "voice of reason" and to those who have now bought into the idea aka "cock blocker of change to a better idea". Note that this will cause a subjective response to notJarvis since we in fact have nothing to test the validity of the proposal, and almost assurdedly a full frontal attack on the alternate suggestion. Note: facts, figures, and proven theories are awesomsauce, nor am I discouraging intelligent discourse on any subject.
the.ynik: That could be an alternative to measure 'imbalance'. But I'm not sure we if have that data on client side. Maybe it even requires an ASGS change (to tell the game server µ and σ, if it currently only transmits the rank), that would make it much more complicated to implement than my suggestion (due to closed nature of ASGS).
At this point the response gave me hope since it demonstrates an understanding of the pit falls of implementing the superior (been tested via looking at the predicted outcome vs reality using real game data) TrueSkill's Autobalance (henceforth TS AB) to the current version. However much more complicated is a profucntional attack and incorrect since the code is already written and tested, slack being cut on that tidbit tbs but it illustrates a point.
the.ynik: I haven't really thought about what the advantage would be if both (µ,σ) are available. But that would just be a replacement for the 'imbalance' measure; if implemented that way you'd still want to use my 'flexibility' and rules for joining a side (compare new imbalance with old or with optimum).
the.yhik: Could someone with more AllegSkill and statistics knowledge tell me how to calculate something like my 'imbalance' measure using the player's µ and σ?
Yes use Baker's already coded implementation and follow the link that notJarvis gave you to understand imbalance. We didn't test this one since it didn't exist at the time. I can tell you the high points of what to do but thats off the cuff and bound to miss something and currently I am in no way interested in working on any Allegiance project.
the.ynik: Edit: also, my approach has the advantage that it's testable right now; for example half an hour ago I put in numbers from the running game, and it would've prevented Shiz from stacking (with #autobalance 1, the game got to 170:133 AS shortly after). With team's AllegSkill, it would suddenly depend on numbers that almost no one knows how to calculate. And on the beta server ASGS is not required, so where would we get (µ,σ) for testing?
Oh, and another argument against Team AllegSkill: unlike my suggestion, it wouldn't work for multi-team games.
But if you can find solutions to all those problems, then team AllegSkill would certainly be better (using only ranks isn't making use of all the information we have).
OK as the idea's father one can understand making a case for it. The laborious approach of sitting in game noting all of the coming and going from the teams and NOAT is fraught with error tbs but worse it is not an accurate check. You need to perform s statistically relevant version utilizing existing game data which shows the coming and going of the players through out the game. That's the only way to do it.
Your idea requires ranks to decide balance as well so the beta server is out for that one too. The less then one percent of all games played that are multi-teamers may not be covered in the coded version of TS AB by Baker. The reason was simply work to utilization but it can be done too.
Xynth: I think the conservative rank is the best piece of information to use anyway. A big problem with Trueskill for allegiance is that experience is more important than on a game like Halo or Gears of War. Learning the intricacies of the game is a big part of being a good player so the conservative rank is actually a good measure of value to a team which is what we really need for balance.
Also I didn't see any algorithms like what the.ynik is proposing in that link. Maybe I didn't go deep enough but I couldn't find anything more than what is on our wiki.
Freyja: Yes, yes, yes, yes!And AS specifically restricts that learning by having a very small window tied to experience. Typically a player that's rank 15 playing 6 months is much, much worse than a rank 10 player that's played 2 years... often because of that experience/knowledge.
(responding to Xynth)
TurkeyXIII: I once fiddled with the mus and sigmas to try to see if I'd be able to use AS to predict the winning probability of games. The main problem is newbies: they have a mu 25, which is higher than plenty of people who know what they're doing, so balancing algorithms based on it will often put them on the lower-ranked team. Also their crazy-high sigma increases the sigma of the whole team, so such a system would think that newbies joining would even a game out, regardless of which team they join.
Conservative rank is more accurate imo. ynik's algorithm is a work of art. Consider putting the weights into a .txt file in the server artwork so it can be modified without a code change.
TurkeyXIII: That's not what I meant, but it's not a bad idea... some reciprocal of sigma as a weighting factor... But depending on the brains behind it, it wouldn't be any less arbitrary than ynik's method, and ASGS/CSS would need to pass two rank values instead of just one.
Please induldge me.
First the term "conservative rank" is taking the player's rank and looking at it as a one-tail implementation rather then a two-tailed implmenation. It slides the collective and individual Mu leftward in the distribution for the displayed rank only. You know consider the bit to the left and this depresses ranks every so slightly.
TS AB doesn't use just Mu but also Sigma. Their "crazy high sigma" and AllegSkill Mu of 15 is EXACTLY the right way to handle their introduction to the team. Im not sure what you fiddled with and how (Im aware you are numbers guy, no slight meant just mean i wasb't there) but my experience is there is no bias to team choice that you mention.
When Mu and Sigma compared to ranks, there is no question that ranks are not as accurate, and I leave it to you to do the math. It's a one hundred percent lock. The information is on the websire, papers, and other links all over sigs, wiki and elsewhere
Finally see boilerplate above... I know it may seem unfair but I've spent probably as many hours correcting this stuff as I have implementing it by now. Im tired of it tbt.
*sigh* maybe I should have quoted the below and been done with this bit.
notJarvis: It's basically what Microsoft uses in TrueSkill - statistical, and proven (is my point).
Anyhow now the gloves are obviously off, sides are choosen, and still no one has a stitch of proof that this new idea has any validity at all. We are now at the armed camps stage with lot's of heat and very very little light. Again let me emphasis no has proven a thing about the.ynik's idea just that they like it. No on is listening anymore and the shouters are about to get shouted at by the other shouters. Until everyone is angry and many epeens are waggled.
Phantom032: If I got it right what Turkey implemented is yniks initial idea, which does NOT use AllegSkill-algorithms, only the RANK thats the RESULT of AllegSkill-algorithms.
Well no, you are using the AllegSkill algorithm in order to develop the rank.
Phantom032: This imbalance=auto change does NOT change how ranks are calculated, it simply uses the given ranks to try and balance a game - a job thats COULD be done by the commanders with imbal=na but, as we all know, isnt. This is why we use imbal=1, to prevent either comm from getting more and more players while the other dies alone. This is why imbal=auto was initially implementet, to prevent either comm from getting a vastly superior team (AS wise).
Well no again. It does by implementing an idea that utilizes the underlying ranking system then places a series of rules above it on how the match play happens. When you do this it most definitely effect the underlying ranking. The degree and severity need to be checked out. This isn't the first time this flawed logic causd big issues. Inflating newbies ranks multiple times anyone. Oh and this is not a subtle point but a glaring one. The current autobalance was not implemented for AllegSkills, nor HELO, bur rather ELO which was a ranking system that went live without any testing and just a "let's do it" attitude. The results were not pretty and the drama caused a huge @#(!storm and lose of player base.
There is more much more after Phantom032's post but I've run out of gas other and leave you with this closing:
Closing and no there is no tl;dr
I've been around for at least four distinctive ranking system changes, autobalance implementation, repeated attempts to deal with rookie integration in the game. Each and every single time code goes live without an actual check of the implications of it *shakes head* bad things occur. Now all, or most of us have experience how to correctly implement change in a team environment. I realize you code for free, and out of love for the game. Same reason I voluntary my time and money too.
However being a dev doesn't shouldn't allow one to just code it up and implement something without vetting the underlying idea. So put together your app, get the old game data, there is 100,000s of them. Perform rigorous statistical testing on the idea, ask for others to check your work (most likely no can by that point you'll be so far into it), and then move forward. Please do it the right way, there is no reason to rush this out half assed. Also the attitude of it STILL may never see the light of day for some totally unrelatd reason is probably going to help with those angry feelings we all have, including me, when does happen. This being illustrated quite spectacularly by one of your own atm.
I am MrChaos and Im sure Ive spelt words wrong, have punctuation errors, got facts twisted and even wrong, along with pissing of everyone... *sigh* it's sincerely not my intention
p.s. I probably won't respond, it's not a sign of arrogance but rather real weariness
A little preamble
Most of you in this section discussing these ideas where not here for the implementation of AllegSkill and the all encompassing @#(!storm that happened upon it's announcement. It was pretty $#@!ing bad let me tell you. After explaining at least hundred times over again, pretty much all of the items being discussed here, I've grown rather grumpy on the subject matter.
Let's try again shall we with the understanding I will not get into a debate on AllegSkill's worth from an algorithm's point of view. It's rock solid, the best availible as far as Ive been able to find anywhere. This isn't an idle comment based on personal observations and gut feelings but hard core checking of actual game data vs predicted outcomes.
Boiler plate response
I ask that you indulge me a little on this everyone and save the I just know Im right argument approach...just with me of course.... and just on this matter. I'd truly appreciate it since my reply will be each and every time: There were literally hundreds and hundreds of man hours spent in the development of the C++ version of the system from evaluating eight completely different approaches through actually checking predicted accuracy. It requires an actual statistical (and probability) check of the results to determine any systems's accuracy, along with the raw game data. I welcome your efforts and look forward to discussing and reviewing the results after you perform the checks too
General comment
Ok Ive got my happiest face, and most Cheerful Wishes for everyone that I can on. If I've offended you in any way please take comfort in the idea that it was unintentional.
Main section
Im torn between quoting everything or just ther relevant section. For sake of brevity I chosen the later. Please believe I read every word of the entire post(s).
The.ynik: Currenly, alleg offers only 2 choices of auto-balance: balance by player count (#autobalance 1) and balance by total AS (#autobalance auto). Both are fundamentally broken by preventing newbies from joining the team that's up.
This as written is fundmentally flawed way of looking at balance. The balancing of a system doesn't hinge on allowing a brand new player access to the game, a perplexing and challenging issue tbs, but in creating a balanced game play experience as a whole. Allowing a brand new player access to either team simply because they are new is a haphazrd approach with regard to balance. As you touch on later there are two aspects to balance. Team size and player ranks which are locked together quite tightly. How you handle this dicotamy is what makes one system vs another stand out. Im going with you had a touch of MrChaosness and it was a words thing vs an idea thing. Just want to make the point is all.
Imago: just implement it in http://svn.alleg.net/svn/Allegiance/branch/FAZR6/src upload a patch file to trac and we will test it
DasSmiter: I like the way you think
Xynth: this (points back to Imago's comment) I like your algorithm. If C++ is not your thing I may look at it, but you should learn
Freyja: I like that it can block too many newbies on one team. Many comms let imbalance happen from lack of skill or desire to police.
the.ynik: I know C++, but I don't have any time for coding this myself right now (at least not in the next 6 weeks). I'm already working on other open source projects, and on top of that I got this bachelor thesis to write... I just wrote that implementation in JS to get the idea out of my mind into some reusable form.
This exchange more then ANYTHING was what got me so crabby in the first post. It's pretty classic response to people working in their own little cloistured group. It starts with "I've got an idea to solve something that I preceive to be an issue, it will effect things at a fundamental level, but Ive given it a good thunk and like it", (the idea could be the second coming of sliced bread I must say out of fairness). Prefunctional checks to no check at all by the peers and we are already to, "let's do it".
Even more dishearening it is followed by the suggester handing all responsibility for implementation to anyone else (RL is RL no slight meant by not having time). So now you have a back of the napkin idea, being green lighted by the group, and handed off by the person, to be championed by someone who didn't even put the concept together. This is a text book example of how not to implement change and all of us already know it. Ok no harm no foul someone will give a gentle nudge and hint that enthuasism has gotten the better of the group.
notJarvis: To be honest though I would consider sticking with Allegskill's roots and look at the MS Trueskill method of working out Team Skill as...
There we go the "voice of reason" and to those who have now bought into the idea aka "cock blocker of change to a better idea". Note that this will cause a subjective response to notJarvis since we in fact have nothing to test the validity of the proposal, and almost assurdedly a full frontal attack on the alternate suggestion. Note: facts, figures, and proven theories are awesomsauce, nor am I discouraging intelligent discourse on any subject.
the.ynik: That could be an alternative to measure 'imbalance'. But I'm not sure we if have that data on client side. Maybe it even requires an ASGS change (to tell the game server µ and σ, if it currently only transmits the rank), that would make it much more complicated to implement than my suggestion (due to closed nature of ASGS).
At this point the response gave me hope since it demonstrates an understanding of the pit falls of implementing the superior (been tested via looking at the predicted outcome vs reality using real game data) TrueSkill's Autobalance (henceforth TS AB) to the current version. However much more complicated is a profucntional attack and incorrect since the code is already written and tested, slack being cut on that tidbit tbs but it illustrates a point.
the.ynik: I haven't really thought about what the advantage would be if both (µ,σ) are available. But that would just be a replacement for the 'imbalance' measure; if implemented that way you'd still want to use my 'flexibility' and rules for joining a side (compare new imbalance with old or with optimum).
the.yhik: Could someone with more AllegSkill and statistics knowledge tell me how to calculate something like my 'imbalance' measure using the player's µ and σ?
Yes use Baker's already coded implementation and follow the link that notJarvis gave you to understand imbalance. We didn't test this one since it didn't exist at the time. I can tell you the high points of what to do but thats off the cuff and bound to miss something and currently I am in no way interested in working on any Allegiance project.
the.ynik: Edit: also, my approach has the advantage that it's testable right now; for example half an hour ago I put in numbers from the running game, and it would've prevented Shiz from stacking (with #autobalance 1, the game got to 170:133 AS shortly after). With team's AllegSkill, it would suddenly depend on numbers that almost no one knows how to calculate. And on the beta server ASGS is not required, so where would we get (µ,σ) for testing?
Oh, and another argument against Team AllegSkill: unlike my suggestion, it wouldn't work for multi-team games.
But if you can find solutions to all those problems, then team AllegSkill would certainly be better (using only ranks isn't making use of all the information we have).
OK as the idea's father one can understand making a case for it. The laborious approach of sitting in game noting all of the coming and going from the teams and NOAT is fraught with error tbs but worse it is not an accurate check. You need to perform s statistically relevant version utilizing existing game data which shows the coming and going of the players through out the game. That's the only way to do it.
Your idea requires ranks to decide balance as well so the beta server is out for that one too. The less then one percent of all games played that are multi-teamers may not be covered in the coded version of TS AB by Baker. The reason was simply work to utilization but it can be done too.
Xynth: I think the conservative rank is the best piece of information to use anyway. A big problem with Trueskill for allegiance is that experience is more important than on a game like Halo or Gears of War. Learning the intricacies of the game is a big part of being a good player so the conservative rank is actually a good measure of value to a team which is what we really need for balance.
Also I didn't see any algorithms like what the.ynik is proposing in that link. Maybe I didn't go deep enough but I couldn't find anything more than what is on our wiki.
Freyja: Yes, yes, yes, yes!And AS specifically restricts that learning by having a very small window tied to experience. Typically a player that's rank 15 playing 6 months is much, much worse than a rank 10 player that's played 2 years... often because of that experience/knowledge.
(responding to Xynth)
TurkeyXIII: I once fiddled with the mus and sigmas to try to see if I'd be able to use AS to predict the winning probability of games. The main problem is newbies: they have a mu 25, which is higher than plenty of people who know what they're doing, so balancing algorithms based on it will often put them on the lower-ranked team. Also their crazy-high sigma increases the sigma of the whole team, so such a system would think that newbies joining would even a game out, regardless of which team they join.
Conservative rank is more accurate imo. ynik's algorithm is a work of art. Consider putting the weights into a .txt file in the server artwork so it can be modified without a code change.
TurkeyXIII: That's not what I meant, but it's not a bad idea... some reciprocal of sigma as a weighting factor... But depending on the brains behind it, it wouldn't be any less arbitrary than ynik's method, and ASGS/CSS would need to pass two rank values instead of just one.
Please induldge me.
First the term "conservative rank" is taking the player's rank and looking at it as a one-tail implementation rather then a two-tailed implmenation. It slides the collective and individual Mu leftward in the distribution for the displayed rank only. You know consider the bit to the left and this depresses ranks every so slightly.
TS AB doesn't use just Mu but also Sigma. Their "crazy high sigma" and AllegSkill Mu of 15 is EXACTLY the right way to handle their introduction to the team. Im not sure what you fiddled with and how (Im aware you are numbers guy, no slight meant just mean i wasb't there) but my experience is there is no bias to team choice that you mention.
When Mu and Sigma compared to ranks, there is no question that ranks are not as accurate, and I leave it to you to do the math. It's a one hundred percent lock. The information is on the websire, papers, and other links all over sigs, wiki and elsewhere
Finally see boilerplate above... I know it may seem unfair but I've spent probably as many hours correcting this stuff as I have implementing it by now. Im tired of it tbt.
*sigh* maybe I should have quoted the below and been done with this bit.
notJarvis: It's basically what Microsoft uses in TrueSkill - statistical, and proven (is my point).
Anyhow now the gloves are obviously off, sides are choosen, and still no one has a stitch of proof that this new idea has any validity at all. We are now at the armed camps stage with lot's of heat and very very little light. Again let me emphasis no has proven a thing about the.ynik's idea just that they like it. No on is listening anymore and the shouters are about to get shouted at by the other shouters. Until everyone is angry and many epeens are waggled.
Phantom032: If I got it right what Turkey implemented is yniks initial idea, which does NOT use AllegSkill-algorithms, only the RANK thats the RESULT of AllegSkill-algorithms.
Well no, you are using the AllegSkill algorithm in order to develop the rank.
Phantom032: This imbalance=auto change does NOT change how ranks are calculated, it simply uses the given ranks to try and balance a game - a job thats COULD be done by the commanders with imbal=na but, as we all know, isnt. This is why we use imbal=1, to prevent either comm from getting more and more players while the other dies alone. This is why imbal=auto was initially implementet, to prevent either comm from getting a vastly superior team (AS wise).
Well no again. It does by implementing an idea that utilizes the underlying ranking system then places a series of rules above it on how the match play happens. When you do this it most definitely effect the underlying ranking. The degree and severity need to be checked out. This isn't the first time this flawed logic causd big issues. Inflating newbies ranks multiple times anyone. Oh and this is not a subtle point but a glaring one. The current autobalance was not implemented for AllegSkills, nor HELO, bur rather ELO which was a ranking system that went live without any testing and just a "let's do it" attitude. The results were not pretty and the drama caused a huge @#(!storm and lose of player base.
There is more much more after Phantom032's post but I've run out of gas other and leave you with this closing:
Closing and no there is no tl;dr
I've been around for at least four distinctive ranking system changes, autobalance implementation, repeated attempts to deal with rookie integration in the game. Each and every single time code goes live without an actual check of the implications of it *shakes head* bad things occur. Now all, or most of us have experience how to correctly implement change in a team environment. I realize you code for free, and out of love for the game. Same reason I voluntary my time and money too.
However being a dev doesn't shouldn't allow one to just code it up and implement something without vetting the underlying idea. So put together your app, get the old game data, there is 100,000s of them. Perform rigorous statistical testing on the idea, ask for others to check your work (most likely no can by that point you'll be so far into it), and then move forward. Please do it the right way, there is no reason to rush this out half assed. Also the attitude of it STILL may never see the light of day for some totally unrelatd reason is probably going to help with those angry feelings we all have, including me, when does happen. This being illustrated quite spectacularly by one of your own atm.
I am MrChaos and Im sure Ive spelt words wrong, have punctuation errors, got facts twisted and even wrong, along with pissing of everyone... *sigh* it's sincerely not my intention
p.s. I probably won't respond, it's not a sign of arrogance but rather real weariness
Last edited by MrChaos on Fri Jul 30, 2010 8:59 am, edited 1 time in total.
Ssssh
I don't understand why you are blocking what is obviously an improvement to me. I'm completely open to throwing my idea out of the window for a better solution IF it's implementable. But given that ASGS is complex to change (no code avaiable for most people), it seems to me that any proper AllegSkill-based solution is NOT implementable in the R6 timeframe.
Again, PLEASE tell me why my idea is worse than what we are currently using: autobalance=1.
Remember, autobalance=1 is COMPLETELY ignoring all your great work on AllegSkill and simply using the number of players instead. Surely almost anything is better than that?
Again, PLEASE tell me why my idea is worse than what we are currently using: autobalance=1.
Remember, autobalance=1 is COMPLETELY ignoring all your great work on AllegSkill and simply using the number of players instead. Surely almost anything is better than that?
It may seem to you. But how do you know you are in full possession of the facts?the.ynik wrote:QUOTE (the.ynik @ Jul 30 2010, 12:37 PM) I But given that ASGS is complex to change (no code avaiable for most people), it seems to me that any proper AllegSkill-based solution is NOT implementable in the R6 timeframe.
e.g.
To be honest. I suggest you converse with Bard directly on this. He is the only one who knows exactly how soon alternatives are on-line, or when the changes go through.sgt_baker wrote:QUOTE (sgt_baker @ Jul 29 2010, 08:27 PM) Fortunately something new is coming our way...
And he is the one with ultimate authority on such things. If an alternative comes online soon after you have implemented something, won't you have wasted your time?
-
ThePhantom032
- Posts: 836
- Joined: Sat May 09, 2009 11:00 am
- Location: Germany
.
baaad Phantom. Having a bad day is NOT a reason to get all grumpy on the forums.
baaad Phantom. Having a bad day is NOT a reason to get all grumpy on the forums.
Last edited by ThePhantom032 on Fri Jul 30, 2010 5:02 pm, edited 1 time in total.
Still ready to teach anyone who asks nicely whatever they want to know about playing alleg. Contrary to popular opinion I do not eat newbies. Voobs taste much better.
I'm not in full possession of the facts.notjarvis wrote:QUOTE (notjarvis @ Jul 30 2010, 03:15 PM) It may seem to you. But how do you know you are in full possession of the facts?
e.g.
In fact, I can't do half of what MrChaos suggests because the required info (AllegSkill implementation, recorded past game info) simply isn't public or at least well-hidden.
I prefer to waste a bit of my time over having to deal with autobalance=1 in game for yet another release. It's great if a better alternative is coming soon, but if it's not soon enough for R6, I'd like that my solution is used in the meantime.notjarvis wrote:QUOTE (notjarvis @ Jul 30 2010, 03:15 PM) To be honest. I suggest you converse with Bard directly on this. He is the only one who knows exactly how soon alternatives are on-line, or when the changes go through.
And he is the one with ultimate authority on such things. If an alternative comes online soon after you have implemented something, won't you have wasted your time?
In any case, why this secrecy on part of the dev team? Someone could have simply responded "I'm looking into doing some AllegSkill-based implementation for R6" on this thread and spared us a lot of drama.
But looking at the information available to me, no one has stepped up yet.
You should get into contact with Bard as he's in charge of the dev stuff now.
MrC's long rambling post (didn't that used to be shorter?) has a lot of good stuff in it. I think this thread proves that people are willing to support a change to autobalance, but what MrC (and possibly Baker too) are saying is that we should wait until all the AS numbers are available.
Baker has created an excellent system and it would be a waste to implement any AB idea without making full use of that system
I was just saying that Ynik's idea was the best I had heard in a long time. I didn't realize that the AB was designed for ELO, I thought the current AB was designed by Baker & Crew and just didn't work as expected.
Sorry about that
MrC's long rambling post (didn't that used to be shorter?) has a lot of good stuff in it. I think this thread proves that people are willing to support a change to autobalance, but what MrC (and possibly Baker too) are saying is that we should wait until all the AS numbers are available.
Baker has created an excellent system and it would be a waste to implement any AB idea without making full use of that system
I was just saying that Ynik's idea was the best I had heard in a long time. I didn't realize that the AB was designed for ELO, I thought the current AB was designed by Baker & Crew and just didn't work as expected.
Sorry about that
Get over yourselves, don't try to win arguments on the internet where the option of a punch in the mouth is unavailable
"It is not that I cannot create anything good, but that I will not." And to prove this, he created the peacock.
I do not know for sure but I think this is the reason it was suggested that you hold back.
As you say ASGS handing over the AS information cannot be done (at least not easily if I understand it which I don't). However there's a successor system to ASGS in development (CSS, it has a forum and everything, it's hardly a secret). I'm assuming that CSS will be able to deal with sending the AS stats to AllServ. If this is the case then Baker already has an implementation of the improved autobalance ready coded (again, an assumption on my part).
So getting fully operational AB into the game is a case of waiting for CSS, however long that will be. If it's only going to be a month or so then it's probably not worth your time and effort.
Also there's a PR aspect to this whole issue. There's a general perception that AB sucks and I would fear that your implementation, better though it would no doubt be, would tarnish the concept as and when a better solution rolls up.
As you say ASGS handing over the AS information cannot be done (at least not easily if I understand it which I don't). However there's a successor system to ASGS in development (CSS, it has a forum and everything, it's hardly a secret). I'm assuming that CSS will be able to deal with sending the AS stats to AllServ. If this is the case then Baker already has an implementation of the improved autobalance ready coded (again, an assumption on my part).
So getting fully operational AB into the game is a case of waiting for CSS, however long that will be. If it's only going to be a month or so then it's probably not worth your time and effort.
Also there's a PR aspect to this whole issue. There's a general perception that AB sucks and I would fear that your implementation, better though it would no doubt be, would tarnish the concept as and when a better solution rolls up.
Spidey: Can't think of a reason I'd need to know anything
-
ThePhantom032
- Posts: 836
- Joined: Sat May 09, 2009 11:00 am
- Location: Germany
.
baaad Phantom. Having a bad day is NOT a reason to get all grumpy on the forums.
baaad Phantom. Having a bad day is NOT a reason to get all grumpy on the forums.
Last edited by ThePhantom032 on Fri Jul 30, 2010 5:02 pm, edited 1 time in total.
Still ready to teach anyone who asks nicely whatever they want to know about playing alleg. Contrary to popular opinion I do not eat newbies. Voobs taste much better.
Why are people being cryptic with "new things coming soon?" It is called CSS, it will replace ASGS. It is currently in alpha testing. From what I know its release will most likely be after R6 but before R7 (a few months.)
One thing to consider here, if I changed the code to if a game where launched with autobalance=auto then every client and the server just throws asserts and crashes, it really wouldn't matter because we don't use it because it doesn't take into account team size. If this were quickly and haphazardly coded up the worst case scenario is no one likes it and it doesn't get used i.e. the same thing that happens if we do nothing.
I understand you guys did a lot of work on Allegskill, and I agree it is the best system available. Let us use the rank you gave us to try to balance games and let the comms worry about herding their cats.
One thing to consider here, if I changed the code to if a game where launched with autobalance=auto then every client and the server just throws asserts and crashes, it really wouldn't matter because we don't use it because it doesn't take into account team size. If this were quickly and haphazardly coded up the worst case scenario is no one likes it and it doesn't get used i.e. the same thing that happens if we do nothing.
I understand you guys did a lot of work on Allegskill, and I agree it is the best system available. Let us use the rank you gave us to try to balance games and let the comms worry about herding their cats.
Xynth@PK
