Hello everybody.
My name is Peter Xenopoulos.
Today I'll be discussing how professional esports teams
analyze and scout opponents, and how ggViz
helps them do so more efficiently.
Esports have come a long way.
In fact, they're starting
to resemble conventional sports.
Not only are esports organizations attracting millions
of viewers and sponsorship dollars, but they
are also hiring robust teams of analysts
and player development specialists.
However, despite all this investment, manual, video-based analysis
is still the main mode of analysis.
First, let's talk about the data in esports, the most
common of which is called a Demo file or simply Demo.
These files are essentially like a playback of a match.
A demo file can be produced in a few games like
Counter-Strike: Global Offensive (CSGO), which is the game we focus on.
Here we focus on CSGO due to
its large following and robust esports scene.
CSGO demos are often found on tournament or fan sites
and are generally really easy to acquire in CSGO.
They can be played back in-game, in a third-
party demo viewer, or even parsed and quantitatively analyzed.
Let's briefly talk about how teams analyze performance.
Many esports have game replays
that we just talked about.
In particular, pro players, coaches and
managers often watch these replays.
They do so with third-party viewers
that help improve the demo-watching experience,
such as providing a better user interface.
While watching demos, they usually manually record notes in
some application or even using a pen and paper.
They often try to ask questions such as
given the team has X, Y and Z weapons,
where do the defenders usually play?
The common problem here is
finding game states of interest.
Here's some feedback from top-ten staff in CSGO.
The use of demo files was unanimous from all
the experts we interviewed are analysts, coaches and
managers from top-ten CSGO teams.
The most common task mentioned by one
of the analysts was to determine how
a team would play under certain conditions.
One manager mentioned that doing so can be overloading since
a single demo can be an hour or more.
The coach identified his frustration
with the current anecdotal approach.
Since there is not enough time to analyze
a full collection of demos, finding game states
of interest is a clear bottleneck.
So now we'll talk about how to quickly
find similar game states and to do so,
we'll start by discussing navigation meshes.
The obvious question here is what
exactly is a navigation mesh?
In short, it's what a computer-controlled bot
uses to walk around in the game.
Let's see how this works in CSGO.
Basically, we start with the map which is
the ingame world, and this map is divided
into surfaces or areas in CSGO.
These areas are all quadrilaterals
and come in various sizes.
As you can see on the left, a collection of
contiguous areas makes a place that is assigned a human
identifiable name, such as CT Spawn, apartments or Bombsite A.
You can see examples by color in the middle.
Finally, these areas all make up a graph
indicating which areas are connected to one another
as you see on the right. We propose a simple
method to produce a token for a game
state based solely on player position.
On any given CSGO map, there are usually 20 to 25
places, so we count the number of players on each side.
In each place.
The vector is actually broken up into two sections a T
park and a CT park for the two sides in CSGO
this provides a token for a game state.
Overall, if we wanted to design a system to search
for similar plays, it would look like this we have
a target game state which we could actually just draw
out and apply some general high-level filters, such as for
the teams and the equipment that each team had.
Then we generate the token and
search for it in the database.
To return a list of game states
we can query using a sketch-based interface.
Searching for states is actually quite fast.
In our data set with many millions of
game states, we can return a list of
similar game states in just a few seconds.
If an analyst only wanted to search a data set
of a few games, it would take even less time.
And this is exactly what we did with
the ggViz system that was the back end.
So now let's talk about the front end.
On the left-hand side, denoted A, we
have the query view where a user can
draw player coordinates and apply filters.
In the B view, we have the results.
Game states are represented by a card that shows info
on the round in which the game state took place.
At the bottom of each card is a win
probability diagram showing the chances of winning for each
team at every second of the round.
The colored, non-black dot indicates where
the state took place in the round.
The black dot indicates a bomb plant.
On the right side, we have the playback view where
users can play back the round of the selected state
and observe events such as grenade throws, kills, and go
to those specific points of a round.
Finally, at the top, we have the heat map
view, which shows a heat map of where players
are standing in the result set from B.
This can be useful for summarizing team tendencies.
Here is an example of an insight
that one can derive using ggViz.
Here we have the bomb site positional heat
map for the Inferno CS Go map.
We place two CT's in various configurations, defending
the B bombsite under various conditions, namely how
much equipment the CT side has.
We see where the most commonly played spots are.
There are clear relationships based on the
different buy types, such as full buy,
semi buy, semi eco, and full Eco.
Such an analysis can help prepare teams for when
they want to take the B site, and they
can create these heat maps according to various opponents.
ggViz is mostly limited by the lack
of spatiotemporal data in games.
It only requires a discretization of a playing
surface, so in theory it could be extended
to most esports or even conventional sports.
Extending ggViz to other games would require
some bespoke filters depending on the game,
but this is fairly surmountable.
ggViz also has some limitations when it comes
to sketching game states in very vertical playing worlds.
One way to get around this is by having various slices of
a map, like in the example we see to the right.
Finally, we evaluated ggViz
using an observation-based design.
However, we believe going forward that it can
be useful to design a taskbased evaluation with
a larger sample size and well-defined tasks.
If you'd like to visit the full paper for
detail, you can visit the bitly link shown below.
If you're interested in parsing CSGO files,
please refer to the awpy library.
Thank you for your time and
I'm happy to take any questions.