Catalog

What is in the dataset

Each match is published whole — every table derived from it, and a recording of every player's point of view in every round. This page explains how those parts fit together and lists every table.

Scale

These figures measure what is offered for download, not everything the company holds.

These figures are read from the dataset itself and could not be loaded just now. Everything else on this page still holds; reload to try again.

How a demo package is shaped

Everything derived from one Counter-Strike 2 match is published together as a demo package, named by its demo id. A package divides into three layers. The first two travel in the main archive; the third has an archive of its own.

“Layer” is the term for all three, even though video is not a medallion layer in the data-engineering sense. Only the bronze and silver layers hold tables, so only those two appear in the index below.

Why the video ships separately

A package is two archives and a manifest sitting side by side: a main archive, <demo id>.zip, always present and the archive you get by default, and a video archive, <demo id>-videos.zip, built separately and possibly not there yet for a given match.

When the video archive does exist it dwarfs the main one — hundreds of megabytes against tens of gigabytes. The two are kept apart precisely so that wanting the tables does not mean moving tens of gigabytes of video. You can take the main archives for every match in the dataset and never open a video archive at all.

Rounds and recordings

Every round of every match is recorded from each player's point of view, so the video side is measured in rounds rather than in files. These figures are read from each package as it stands in storage right now.

Reading the packages…

Matches are numbered for this list only. There is no page for a single package and nothing here links to one: per-package detail is deliberately not part of the catalog, and a researcher who wants it downloads the package.

How the parts link

Four keys hold a demo package together. Between them they cover every join the dataset supports, so what an analysis can ask is decidable before anything is downloaded.

demo id The single join key across the whole package

A uuid identifying a demo package and every file in it — the tables and the video both carry it. No other correlation key is needed to tie one match's parts together, and it is what tells two matches apart once you have loaded both.

tick The shared time axis, 64 Hz

The game's simulation step, and the clock every table is stamped with. Any two tables join on (demo id, tick); a second of match time is 64 of them.

steamid The per-player key

Where a table is per-player, it carries the player's steamid, so per-player tables join on (demo id, tick, steamid). In the wide per-slot tables the same identity appears as a column family across the ten player slots rather than as ten rows.

frame table The bridge from a video moment to a table row

Beside every point-of-view recording sits a frame table: one row per rendered frame, mapping the frame's index and its timestamp in the video to a tick. That is what lets a moment you can see resolve to the rows that describe it, and a row resolve back to the frame it happened on.

Frame tables ship in the video archive only, alongside the recordings they describe: a frame-to-video map is of no use without the video. They are original data rather than a projection — a frame's index, its presentation time and whether its tick is exact are artifacts of the rendering run and cannot be reconstructed from any table.

Every table in the dataset

Every demo package holds the same set of tables, so this describes the dataset rather than any one match. Row counts and sizes are totals across the packages that carry the table.

Loading the table index…

A table's own page carries its schema, what each field means, and a preview of real rows. There is no page per demo package: per-package detail is deliberately not part of the catalog.