u/Vivid-Zombie-477

A while ago I made a depressing post stating "there is no signals of a good progammer anymore" since everything can be faked with AI.

Well, in my opinion, nothing actually changed from the pre-LLM era since people could steal other works even back then. Cool repo? Fork. Interesting blog? Ctrl-C.

The actual difference is competition. There are simply more people who are willing to cheat now.

So, what are the high quality signals of a good programmer? I think there are 3:

1. Projects with real users. People HATE vibe coded projects. If people stared/bought your project that instantly tells me it's either interesting or solves a real problem. If it's another calculator then of course none is going to use it.
2. Blog. Sometimes, your projects don't get a lot attention and that's okay. If you learned something when building your project or encountered an obstacle - it's a great reason to make a blog post and talk about it. I assure you, vibe coders won't be able to write blog posts because they didn't solve a problem, and AI written text is easy to spot.
3. Personality. When making a site or blog, make it yours. Look at this blog for example - https://faultlore.com/blah/ . Some may say it's ugly, some may say poetry should not be in the "About me" section, but it's 10 times better than a vibe coded site with template description.

I wanted to do precise aim and visibility analysis so I needed to know what a player sees - including if only part of an enemy is visible and smoke checks. I have tried to train AI to get players outlines, but it had problems detecting when only small parts of players is present - e.g., only head is visible when jump spotting. Also, it was slow.

So I ended up making my own demo format that includes player hitboxes and volumetric smokes. I think it's awesome because it opens a lot of features I want to try:

- Aim analysis. One of the original goals. Aim is very context depended metric and this format can be used to analyze not only how many bullets have hit the target but how far away each bullet was from hitting enemy, what was the chance of hitting the enemy based on inaccuracy (spread), and how hard was it to hit the enemy (only head is visible vs full body).

- What parts of the map a team currently sees. This is what the video example shows - the map is colored to show what part of the map each team has vision on. This can be further improved to anti-strat pro teams by combining what the team sees across many rounds.

- Where enemies can be. This is my favorite and I didn't touch this idea yet. Given what your team sees - we could know where enemy can and cannot go. This creates even more features - like finding the gaps and timings opponent team doesn't expect, prefire accuracy based on the positions enemies could take, and many more!

- Reaction time. If we now know the exact time enemy became visible to a player we can calculate when the player started aiming towards the enemy.

I want to keep developing on top of this so I'm looking for financial support. I would love to work with a pro team to create tools for anti stratting, help tracking individual players form, and scout new players. I'm also happy to open source the project and host the demos and stats of pro teams with API if I get a sponsor.

What's wrong with Valve's .dem files? Doesn't it already include everything you need?

Well, you see, Valve's demo format is optimized to contain as little information as possible - most of the things you see on your screen when watching a demo is actually calculated by the game engine itself, not stored in the demo format. Here's few examples:

- Eye position. You cannot get eye position by parsing valve's demo format. It's true that the format includes eye angle (in what direction you look at) and a player position - but that position is actually at foot level. Instead, the game calculates height of the eyes depends on what keys you pressed - e.g., if you spam crouch button your eye height would constantly change with different speed (fatigue mechanic).

- Player animations. Once again, demo doesn't store every pose in the demo format - client computes the animations on the fly based on what movement keys the player pressed.

- Volumetric smokes. This is why every demo viewer has detailed mollies but smokes are just circles. Mollies are cheap to store in the demo (only a few 3d points are needed to represent spreading) and important (they do damage), meanwhile the smokes are represented in the game as many many small voxels (cubes) and can be computed locally given the map geometry - so they are not included in valve's demo file.

Therefore, Valve made those trade-offs to reduce demo files size by including only networkable data (what server sends to client):
- Demo files are heavily tied to a game version. If valve updates game engine logic you won't be able to watch a demo recorded in the previous version of the game.
- When you click on timeline it takes some time to compute animations/smokes from the start of the round.

This limits demo analysis a lot - you would basically need to re-implement the entire AnimGraph 2 and other logic yourself that could break after the next game update.

How do HLTV and Leetify work then?

In case of HLTV it's simple - HLTV mostly uses networkable data for their Rating system and stats like KAST. Kill-feed, damage, and round start/end - are all included in the demo. Tracking how many players are still alive is trivial. For example, as far as I understand, HLTV's "Firepower" metric is based only on kills, damage and multi-kills.

- "Leetify! Leetify calculates aim rating!". This is where it gets interesting. Leetify and similar mass-market stat-trackers don't simulate animations and smokes - it would be too expensive to do this for millions of users, instead they use educated guesses. They ignore uncertainty like when you shoot in the direction of a smoke, calculate how many bullets actually hit a target, and use approximation of a hitbox for time to damage. Yes, they used a huge cube to calculate your reaction time just a month ago.

Leetify is honestly a great tool for an average player - you can compare yourself to donk! However, with all approximations it does - it makes it unreliable to compare players of similar skill level. Especially high level players.

^(I know how sensitive reddit when it comes to AI usage so I didn't use LLM to fix grammar. Sorry (not sorry) for bad English.)