W3MMD Standard

[GoogleCodeExporter]

The W3MMD standard leaves much to be desired as it only seems to have one 
field of "score" with which to store data.  Perhaps it can store 10 
propritary numbers with different info for each custom map.  I will use 
Battle tanks in my example of what I'd like to see tracked.    

kills   (int)
deaths  (int)  
won/loss (bool)
average weapon range (int between 500 and 1300)
tank chosen  (maybe a string of numbers)   ex.  (03121719)  means (light 
tank, heavy tank, sky forttress, titan)

I would like to see ghost gain a !statsall command so you could see that 
skill level and leaver percentage of all players.  It would also use this 
data in automatic matchmaking in this fashion.  1st - kick any player with 
less that 50% stay ratio (perhaps this would be configerable in 
ghost.cfg).  2nd Put top two players, based on kill ratio*wins, in slots 
1,6.  3rd - take rank 3,4 players and put them in slots 2,7.  Continue 
this patter until you have players with no stats and leave them alone.  I 
will post this on Ghost++'s site.  

Here are some examples as to why my skill formula might work out.  

Joe is a feeder.  He's played 25 games and his kill ratio for all of them 
is 10/100.  However his teams were always good and he managed to win 20 of 
the 25 games.  

JoeAFeeder
Kills 10
Deaths 100
Wins  20
Losses 5

Joe's Skill would be .1 * 20 = 2.

IRElite is a great player.  He's played 25 games as well and his kill 
ratio is 200/50.  IR likes to play public games on the light forces and 
his team always seems to have lots of feeders giving his 5 wins and 20 
losses.  But that doesn't change the fact that he is a great player.  

IRElite's Skill would be 4 * 5 = 20.

IExplode is an average player who likes to exploade and tends to break 
even on kill radio 100/100.  Sometimes his opponents know how to use tp 
breakers and sometimes they don't so his team only wins 50% of the time.  

IExplode's Skill would be 1 * 13 = 13.  

Original issue reported on code.google.com by ico...@gmail.com on 9 Aug 2009 at 10:14

[GoogleCodeExporter]

perfect formula, better to have it in dota games too, but it has assists 
parameter

Original comment by bazarov...@gmail.com on 9 Aug 2009 at 2:26

[GoogleCodeExporter]

So playing around with this some more, I'm seeing a need for a matchmaking 
score vs 
a leaderboard score.  Since there is no good way to get team vs team going on, 
the 
win/loss ratio is nothing more than a curiosity and has nothing to do with an 
individuals skill.  So for the matchmaking skill, number of games played 
(experience) should count for something.  Even if someone doesn't have a great 
kill 
ratio, if they've played lots of games, I'd rather play with them than someone 
with 
few games and a higher kill ratio.  

In this sample table, Adj MM = (Kills/Deaths) * Games * 100.  The last 100 is 
to get 
rid of the decimal points.  You can see that players 1 and 2 are ranked the 
same 
despite the large difference in kill ratio.  Howerver, player 1 had to play 625 
more 
games to be considered as good as player 2.  

Leaderboard score ranking would be based strictly on kill ratio.  The board 
would 
sort first by kill ratio and then by number of games played.  Even though 
players 2 
and 4 have the same LB score, player 2 would be ranked higher because they 
maintained that kill ratio over more games.

Kills   Deaths  Ratio   Games   Raw MM          Adj mm          LB Score
5000    12000   0.42    700 291.67          29167           42
200 50  4.00    75  300.00          30000           400
100 100 1.00    25  25.00           2500            100
400 100 4.00    50  200.00          20000           400
26  78  0.33    20  6.67            667         33
56  70  0.80    30  24.00           2400            80
120 80  1.50    35  52.50           5250            150

Hopefully a !Stats <player> command would provide the following.  Games played, 
leaver %, and Average Kill Ratio.  It'd be nice if ghost kept a table of 
updated 
stats at the end of each game so that reading the data later wouldn't require 
10 
select statements and lots of math.  

Original comment by ico...@gmail.com on 9 Aug 2009 at 7:48

[GoogleCodeExporter]

u2 have to start a new topic about this on forum
about dota again - assists are very important too

Original comment by bazarov...@gmail.com on 9 Aug 2009 at 9:30

[GoogleCodeExporter]

Did they find out a way to determine an assist on DOTA?  Does everyone in the 
vacinity of a kill get an assist?  Sounds like a lot of work for the map coder. 
 I'm 
not sure that the Btanks map coder is going to add that since he has announced 
his 
retirement already.  I'd be more interested in giving a kill ratio boost to 
support 
players like traders/tinker who tend to die but not get kills.  Even so they 
are 
valueable.

Original comment by ico...@gmail.com on 11 Aug 2009 at 6:55

[GoogleCodeExporter]

The W3MMD system is completely generic and can track anything you want to throw 
at
it, whether kills, assists, deaths, or "number of pies thrown at clowns". 
Because of
this flexibility and the way GHost++ was designed it is difficult to allow 
players to
query their arbitrary statistics from directly within GHost++. I will not be 
adding a
flexible stats query to GHost++.

You're also trying to blur the line between the W3MMD system and the matchmaking
system. The W3MMD system is unrelated to the matchmaking system except by the 
fact
that the statistics gathered by W3MMD allow you to get an idea of how "good" a 
player
is and you usually want to know how "good" a player is when matchmaking.

In fact, the matchmaking system requires you to provide it with a single value 
for
each player, which we call the rating or score, which it then uses to match 
players.
What this score means is completely arbitrary, we just expect that someone with 
a
larger score than another player is more "good" than the other player.

The core GHost++ binary does not contain the ability to score players because 
it is a
very arbitrary process. As you've already discovered, hashing out the specifics 
of
determining how "good" a player is complicated, messy, and usually unreliable. 
As a
courtesy I've included two external binaries which permit you to use a default
scoring algorithm which is simple and well known - the ELO system. One binary 
is for
use with DotA and the other is for use with W3MMD since they use different 
database
tables.

There is no requirement for you to use these binaries to produce your scores. 
You are
extremely welcome to create your own scoring algorithm and use it in place of 
the ELO
system provided with GHost++. It would be very possible for you to use an 
algorithm
such as the one you've described here, assuming the map you're interested in 
actually
uses W3MMD to keep track of values such as kills and deaths.

If you wish to discuss this further I suggest you use the GHost++ forums 
although
you're welcome to post here. I may not see it though as the issue will be 
removed
from the main list as soon as I change its status.

Original comment by hogantp on 13 Aug 2009 at 1:39

• Changed state: WontFix

[GoogleCodeExporter]

As an additional note, the reason GHost++ uses a "messy" database structure for 
the
W3MMD data is because it must be able to store a large variety of statistics 
which
are not known in advance and which are different for each map. If you wish to 
store
your W3MMD statistics in a more readable format I would encourage you to create 
some
new summary tables in your database and populate them using the data in the 
W3MMD
tables. You will probably have to keep track of which games have already been 
added
to your summary tables and you will probably have to run the generator as a 
scheduled
task.

If you are planning to do a lot of querying of the W3MMD data or storing even a
modest number of games this will probably be necessary because the default W3MMD
table structure is NOT designed for summarizing statistics. Instead, it's 
designed to
allow arbitrary statistics within a single set of tables.

Original comment by hogantp on 13 Aug 2009 at 1:47

[GoogleCodeExporter]

Concider using an eav model for the database structure:
http://en.wikipedia.org/wiki/Entity-attribute-value_model Both fast and 
flexible.

Original comment by Fraak.Gr...@gmail.com on 2 Oct 2009 at 8:56