I don't know. What do you want to use it for? It's basically all math and mostly derivative of previous skill systems like ELO that have been around forever, so there isn't really any IP involved IMHO.
I think in order to make even better use of the commander rating, the way a game is setup should be modded as well:
As it stands now, players are joining a team and start jumping around and building skulk-piles, until eventually someone jumps in and takes the command.
In order to make full use of a commander rating, it should be clear who will command first, and then teams should be made (either by forcing auto-teams or letting join freely and showing a win-percentage somewhere on the screen).
Maybe some mod could be made to the ready room, doors for commanders maybe?
I don't know. What do you want to use it for? It's basically all math and mostly derivative of previous skill systems like ELO that have been around forever, so there isn't really any IP involved IMHO.
Well it is a logical concern even if it is solely math as you say.
It's like. Words are free to use but a novel isn't. Get the pic ?
And about tenacity ?
encourage resisting until death instead of concede or "fast concede".
I don't know. What do you want to use it for? It's basically all math and mostly derivative of previous skill systems like ELO that have been around forever, so there isn't really any IP involved IMHO.
You could consider putting it under a Creative Commons license then, just to clarify what people are allowed to do with it.
This is probably the most important thread of the whole forum (aside from Mendasp's great NS2+ Mod). Could we get any info / status updates? Maybe you could tell what kind of support is needed, in case manpower or something else is missing.
This is probably the most important thread of the whole forum (aside from Mendasp's great NS2+ Mod). Could we get any info / status updates? Maybe you could tell what kind of support is needed, in case manpower or something else is missing.
Pretty sure it's already being implemented and we'll most likely see it in the next patch or the patch afterwards, or maybe no patch is even needed because it's done through hive/stat system
thats an awesome approach! it's not so easy to grasp though:
1a. the title "Faster convergence (not used)" confuses me, if the update rule in that chapter is NOT used, then which one is (since the earlier one does not cover commanders)?
1b. it might be a good idea to give a number for every formula for the sake of easily refering to it e.g. in these forum posts (i admit i rarely do that myself, but i think it should help considering you are refining the model in several steps)
1c. some simple numerical example would help to illustrate things
having a bit of experience with machine learning (although with more focus on classification), i'd like to bring up some points (not sure how valid they are, i only have rough theoretical knowledge about gradient descend and you probably have much more hands-on experience working for a company anyway):
2a. which other algorithms have you considered, what is the reason to use this one in particular?
2b. you might want to summarise some thoughts about space and time complexity since machine learning approaches can be quite demanding (although i have the impression that this approach scales quite well)
2c. afaik its good that you're using sums of logs to prevent numerical issues resulting from accumulation of tiny probabilities. i think theres one special case not covered though: sum c_i being 0 (e.g. when a team has no commander for the round, some servers enforce a start after a few minutes if the other team has a com) will result in division by 0, this should be easy to prevent by slightly adapting the formula, maybe laplace smoothing
2d. if i understood this correctly, you're using multiple team-joining/leaving-times as well as going/exiting-commander-times for every player. the data-base scheme seems to lack an ID to represent the same player in the same match entering/exiting twice or more, there is also no commanding. theres still an issue with possible spam too (players could use a script to spam re-joins) so theres still need to figure out in which way this should be limited / combined (e.g. ignore an leave-rejoin with <5 second apart unless the team has changed)
don't get me wrong btw: i love this approach and from what i understand it's a good choice for this problem. i just want to understand it better plus make sure there are no potential weaknesses/abuses in the system.
I've mostly stopped playing now, partially because of Just Cause 2 multiplayer being so damn fun, partially because exhausted in the hunt for good balanced games. Defo coming back if this turns out half alright.
moultanoCreator of ns_shiva.Join Date: 2002-12-14Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
Acedude got pulled off to work on other stuff a little while back, so I'm not sure if this is going to happen. Maybe this is something the CDT could take it on if there's still interest?
Acedude got pulled off to work on other stuff a little while back, so I'm not sure if this is going to happen. Maybe this is something the CDT could take it on if there's still interest?
I can say with confidence it's on the CDT's to-do list. When it will arrive, I can't say nor do I know exactly.
revisited the google doc again and finally felt like understanding it all, the model really looks like great design decisions were made.
with stack/teambalance issues apparently being the #1 complaints people have (at least from what i personally experience on servers), this could really improve things a lot.
As you see the playerinfo contains the playtime a player stayed at each team.
this was posted 20 days ago, so forgive me if the following is obsolete (i'd still rather post it just in case it's not):
i guess the example you posted is the only hive data that is sent, one chunk per player and match (which makes sense).
to weight earlier game time higher than later game time, this current scheme will not do though. if you take the total time on a team in that match instead of entry and exit time then you could at most compute an estimated entry and exit time, but averaging it kinda defeats the purpose of different weighting.
so i guess the scheme was (or is being) updated. but how are repeated joins and leaves on the same team being adressed? if you use the very first join time and the very last leave time, things will go quite wrong if people are switching teams more than once. if you simply send multiple join and leave times, people could abuse that to increase traffic so i guess a limit is needed some way or the other.
another very minor thing: only having a single commander time will not adress the rare event of a person commanding both teams at some point during the same match.
moultanoCreator of ns_shiva.Join Date: 2002-12-14Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
It might make sense to compute the weighted fraction on the server and then send it over just to simplify the database. You'll lose flexibility that way, but it's a lot easier to implement than pushing all of the timestamps to the sql.
Comments
As it stands now, players are joining a team and start jumping around and building skulk-piles, until eventually someone jumps in and takes the command.
In order to make full use of a commander rating, it should be clear who will command first, and then teams should be made (either by forcing auto-teams or letting join freely and showing a win-percentage somewhere on the screen).
Maybe some mod could be made to the ready room, doors for commanders maybe?
Well it is a logical concern even if it is solely math as you say.
It's like. Words are free to use but a novel isn't. Get the pic ?
And about tenacity ?
encourage resisting until death instead of concede or "fast concede".
It's happening!
Pretty sure it's already being implemented and we'll most likely see it in the next patch or the patch afterwards, or maybe no patch is even needed because it's done through hive/stat system
1a. the title "Faster convergence (not used)" confuses me, if the update rule in that chapter is NOT used, then which one is (since the earlier one does not cover commanders)?
1b. it might be a good idea to give a number for every formula for the sake of easily refering to it e.g. in these forum posts (i admit i rarely do that myself, but i think it should help considering you are refining the model in several steps)
1c. some simple numerical example would help to illustrate things
having a bit of experience with machine learning (although with more focus on classification), i'd like to bring up some points (not sure how valid they are, i only have rough theoretical knowledge about gradient descend and you probably have much more hands-on experience working for a company anyway):
2a. which other algorithms have you considered, what is the reason to use this one in particular?
2b. you might want to summarise some thoughts about space and time complexity since machine learning approaches can be quite demanding (although i have the impression that this approach scales quite well)
2c. afaik its good that you're using sums of logs to prevent numerical issues resulting from accumulation of tiny probabilities. i think theres one special case not covered though: sum c_i being 0 (e.g. when a team has no commander for the round, some servers enforce a start after a few minutes if the other team has a com) will result in division by 0, this should be easy to prevent by slightly adapting the formula, maybe laplace smoothing
2d. if i understood this correctly, you're using multiple team-joining/leaving-times as well as going/exiting-commander-times for every player. the data-base scheme seems to lack an ID to represent the same player in the same match entering/exiting twice or more, there is also no commanding. theres still an issue with possible spam too (players could use a script to spam re-joins) so theres still need to figure out in which way this should be limited / combined (e.g. ignore an leave-rejoin with <5 second apart unless the team has changed)
don't get me wrong btw: i love this approach and from what i understand it's a good choice for this problem. i just want to understand it better plus make sure there are no potential weaknesses/abuses in the system.
Could be wrong, but that's along the lines of my hunch.
So....Hera is becomming official since its been quiet for a loooong time?
I would be beyond extatic if this were true.
with stack/teambalance issues apparently being the #1 complaints people have (at least from what i personally experience on servers), this could really improve things a lot.
@Ghoul, you mentioned this was posted 20 days ago, so forgive me if the following is obsolete (i'd still rather post it just in case it's not):
i guess the example you posted is the only hive data that is sent, one chunk per player and match (which makes sense).
to weight earlier game time higher than later game time, this current scheme will not do though. if you take the total time on a team in that match instead of entry and exit time then you could at most compute an estimated entry and exit time, but averaging it kinda defeats the purpose of different weighting.
so i guess the scheme was (or is being) updated. but how are repeated joins and leaves on the same team being adressed? if you use the very first join time and the very last leave time, things will go quite wrong if people are switching teams more than once. if you simply send multiple join and leave times, people could abuse that to increase traffic so i guess a limit is needed some way or the other.
another very minor thing: only having a single commander time will not adress the rare event of a person commanding both teams at some point during the same match.