GM-Salt Wrote:Neither suggestion would be significantly harder to code than the other. Another way would be to do a hybrid of the two where if it picks a support job it could first check if another of the same job is available, and if not then look for other support classes to put in the other team. We could also try to balance it so teams get about an equal number of trans and non-trans classes. Or balance it based on how many bg points you have accumulated, since persons with higher bg points are more likely to be experienced bg players than persons with low bg points.
But any of those ways would be relatively complex to code right. The picking algorithm can't just go "oh I just randomly picked a sinx, and hey there's another sinx that signed up so lets place that one in the other team" because that would affect who gets left out of the fighting when more than 14 persons sign up. If two sinxes and one priest signed up the sinxes would both have double the chance of the priest of getting into the fight, since if one of them got picked the other would too. This would be very unfair.
That being said, it can be done fairly too, if the code was split up into two stages, one deciding who gets picked and a second stage that assigns and balances the teams, instead of doing it at the same time like its doing now. But neither suggestion would be a simple fix if we want to do it right.
Changing the picking algorithm will be considered, but I can't promise anything, and right now there are other things are higher priority.
1. First of all, thank you for the reply.
2. Personally, I disagree with the following: " Or balance it based on how many bg points you have accumulated, since persons with higher bg points are more likely to be experienced bg players than persons with low bg points." because it will be unfair for people who actually trained and played harder -> if this was coded people who has higher BG points would have to keep on carrying their team, and personally i think that would be more of a dis-incentive for people to play properly.
Again, i'm looking more at the "what" rather than the "who". But i'm open to other ppl's suggestions; if the majority of BG-goers feel that they want to be scrutinized based on "who" they are, then who am i to say no?
3. It is very good to hear that any of the proposed solution is just as easy (or just as hard) to code. However, initially i referred to flag-identifiers based on what is already coded without having to perform arbitrary judgements on what classes are "support" and what classes are "offensive".
Take HWs for instance; before mvp cards and without bragi, most HWs can only SG to zone people out, keep SWs up for defensive reasons, and basically act as a zone defender. If you die to a HW without any of the above conditions, you are either lagging so hard you can't even pot or get out of the way or you're just not potting enough. But if they have a certain mvp card, they hurt that much more and you might actually die. Should they be "support" or "offensive"?
Then there's LKs. DPS wise they are out shined by the likes of WS, champ, sinX, and even HWs probably. Yet they can be quite a nuisance and can actually kill you if you get careless and let them actually get close enough to you. "Support" or "offensive"?
And what about clowns and gypsies? Thems are cute and cuddly bragi slaves or SP song slaves until they land a coma on you...
Snipers too... chiseling you with FA and/or trying to SC you with easily pottable DS damage... but then they get a bragi and you're seeing chicks flying around your head as you fall flat.
it's not that i think these decisions aren't hard to make, it's more that they will be somewhat arbitrary and some people might not agree with them.
4. thank you very much for explaining what issues might come up. TBH before you stated it, i kinda thought that it wouldn't be a problem. But now i know that it is indeed a problem because the team picks are done instantaneously so there's no room for a second iteration that would be necessary to define who actually gets in and who gets on which team. I agree that this will not be easy to code unless we phase the entry process into two stages (with a gateway in a small closed map for example), and that would make even more room for errors.
again, thanks for at least taking the time to reply, it means that you do have your heart at the right places even though you might be busy with other stuffs
-w-
