@GentlemanJon, thanks for the comments. I'm hoping that a good combination of stats which amount for damage/frags, heals, ubers and caps would provide enough variation to cover most of the scenarios described on the thread. Ultimately, I'm only interested in the prediction power of the model, even if the successful combination of the weights/features would be hard to interpret for a human.

Well this is why I started this thread in the first place. To discuss the existing stats and figure out new/better ones. So let's first agree that automatically analyzing video stream data is cumbersome and should be the last resort. Extracting data from STV demos is also impractical, since nobody knows the structure of the network packets that are dumped into those files. So that leaves us with whatever we can get out of log files. This is what I'm trying to work with right now. And if this isn't good enough, well then, the next question is what would be needed instead? What other data would be valuable to have inside a log file? And once we identify that, it's only a matter of time before someone knowledgeable about TF2 server plugins can update them to dump this new data into the logs.

I'd like to know this formula as well, I didn't manage to deduce it by myself after reading that link. Hopefully @GentlemanJon is still around.

If you're 100% right, then people doing machine learning and artificial intelligence would be out of a job... I do get where you're coming from, however let me try to change your mind about this a little bit. The general argument that you're making is something like "it takes a human being to do X / to draw a conclusion about Y". Think of the task of diagnosing a skin lesion and identifying whether it is a malignant tumor or not. Up until recently, the first step of this process required a trained professional to actually take a look at the lesion and decide whether it looks suspicious and further investigation is required. Now, we've figured out how to train a computer to analyze images of skin lesions and look for clues (shape, size, color, texture etc.) that would indicate a potential malignant tumor. These systems are not perfect, obviously, however they're becoming more and more helpful and in the end, their utility is what really matters. The general idea for this and for my own TF2 app is this:

1. understand the type of reasoning that a human expert would use for a particular problem;
   
2. break that reasoning down into manageable steps and identify the clues (performance metrics) that are needed;
   
3. "teach" a computer to apply the same reasoning for that type of problem.

This thread is all about the second step in that list. I get it that you don't think that DPM or K/D ratios would be that much helpful in determining good play. But this doesn't automatically mean that the only way to do this is to have a dude analyze the demo/stream himself.

I could argue that this would NOT skew the results of the pocket, as it is his job to force the enemy medic during an uber exchange. Anyway, let's try to keep the discussion focused on the stats themselves, since their interpretations are always going to be up for debating. @mansfield7 posted a nice quote that sums this up earlier:

A simplification could be this: if a medic received damage withing the last 1 or 2 seconds before "chargedeployed" was triggered in the log file and his health is below a threshold (say, 50%?), it could be safe to assume that the damage has forced him to pop. If he receives damage from multiple enemies, there are two options here:

1. assume a force pop from the enemy who caused the most damage (probably the best option)
   
2. assume a force pop from the enemy who caused the last damage

Any thoughts?

If K/D and DPM aren't as accurate, can you think of any other stats that would indicate "a smarter game"?

Is there a "logs.tf" JSON schema available? It's easy enough to read the JSON files themselves in my app, but it would help me a lot to know its hierarchical structure.

I'm also working on an SQL database to store the [data](http://pastebin.com/a0fXRSYD) that can be found in a TF2 log file. An up do date ER diagram is linked in the first post on [this thread](http://teamfortress.tv/thread/17341/help-with-tf2-database-design/?page=1). If I ever pull this off, the stats you mention could be computed with a couple of SQL commands.

Does anyone maintain records of which matches are posted in which logs.tf links? The best I've done so far was to look on the match pages of the ETF2L web site. Someone usually posted a link to the log file in there.

Holy f... that makes things so much easier. Thanks!

You're right, in a way. But my point is this: yeah, you won. But why? What did you do to win? What made the difference? It's not about boosting egos or having numbers to show off after a win. It's more about finding strengths/weaknesses, things to improve and, most importantly, trying to predict the outcomes of future matches when you know how well/bad the team and its players did in previous matches.

@GentlemanJon, thanks for your ideas. Your "TF2 by the Numbers" series was a great source of inspiration for me when coming up with the idea for this app. You make a good point when you mention that some stats work better when compared on a full team basis, rather than per individual player. I'm going to have to think about this some more... Same goes for offclassing, it's going to be interesting to compare a team that function well with heavy offclassing (when snipers and spies do their duty) with a team that only relies on the classic line-up.

Everyone else, thanks for all the ideas and the great discussion.

Hi TF.tv. I hope you can help me with a few ideas for a little project of mine. I'm aiming to build a program that parses TF2 log files and tries to interpret them, basically linking stats like K/D ratio or DPM with the outcome of the match, wherever possible. This previous thread has more info about what I'm trying to do.

I know that this approach has flaws and limitations, however the data from log files is all I have to work with, so it will have to do. For anyone curious of what type of info can be found in log files, here's a sample with the types of events that are recorded in TF2 logs. I'm going to read those events and interpret them into stats such as those on logs.tf or sizzlingstats.com.

So my question to you guys is this: what kind of stats would be linked to good play for each class in the game? How does a player know when he's done his job or not, by only looking at these stats? I'm going to be focusing on 6v6 matches, but I want to keep off-classing in mind as well. For a start, this page has a number of great ideas, but I need more than that. I'm even looking for semi-serious stats such as "scout kills with direct pipes per minute" for Demoman. Basically, anything that can be learned from log files could prove to be useful. Thanks!

@Rigel, thanks for the link! I'll definitely take a look and use your project as a source of inspiration. I'll PM you if I ever get stuck with anything DB-related.

@ykpegedese, you used a bunch of abbreviations that I have no clue about. I assume DW is data warhousing? I know RDBMS, but I don't know what BI, SDE and ETL are.

The real purpose of that data is to store the inputs of a machine learning/data mining application that I will write. The role of that will be to create regression models that predict the outcomes of a TF2 competition based on the individual and team-based skill of players in previous competitions.

@shadowmatter, thanks for the comments. You're probably right, Statistics shouldn't really be an entity as all of its attributes can be computed when needed. As for the Events table, I'm gonna have to think so more about its structure, however your idea of "payload" columns which store JSON strings containing any arbitrary data is quite interesting.

Here's a second update to the ERD. I'll update the first post as well for any newcomers to the thread.

Cool, thanks again @mansfield7 for your comments. And @RussianGuyovich, thanks for the refresher on the logic behind the types of keys. Your post brought on a bunch of flashbacks from my undergrad courses. It's a shame I haven't been in touch with this stuff in a bunch of years now.