Team Decerto vs DRAAKJES (5780 views)

4
Team Decerto nl
2
DRAAKJES nl
nl saKen
nl joshua
nl SQuid
nl L4mpje
nl mArk
nl Krii
ESL 3on3 Country Championship National Qualifiers
The Netherlands - Grand Final Tournament Tree

nl Mouse Control road to the final:
4:0 III.Musketiers
nlDraakjes road to the final:
4:2 Keyboard Warriors

Quote by TimbolinAIk denk dat het een interessante match zal worden. DRAAKJES is natuurlijk in theorie de zwakkere partij, maar het moet zeker niet onderschat worden. Hun teamplay is zeer sterk. Maar ik ga er toch van uit dat het een 4-0 overwinning van Mouse Control zal worden, omdat ze gewoon niet te stoppen zijn.


Quote by xarQiHet zal een zeer close game worden. Mousecontrol heeft zich de laatste maanden zwaar bewezen en getoond dat ze wel degelijk kunnen optreden als een team voornamelijk in nationscup als team NL hebben ze al heel wat teamplay opgedaan. Maar Draakjes is een 3vs3 team die niet te onderschatten is, ze hebben zich ook al meer maals bewezen dat ze het kunnen, ik denk dat het een 4-2 wordt voor draakjes.
27.03.12 23:00 CEST

Consider this more of a tech demo than an actual feature. We can't guarantee that data for all players is availabe, complete or accurate.
The techniques used to create these maps are bleeding edge HTML5 features and you can read more about it below the map. It also means that you need a halfway modern browser for all this to work.

Color Options
  • Every player has his own color on the map.
  • Do not assign players their own color; draw one team blue and the other team red.
  • Starttime is blue and as the maptime progresses it fades towards red. All events are colored depending on when they happened during the map.
  • Mouse(on.
  • [DRAAKJES]
  • Draw:
  • Map





So how does it work?

Gathering data
I start off by running the .tv_84 demos through Hannes' tv demo indexer - this is done anyway when matchstatistics are created. As a by-product (somewhat) we get coordinates for all kill events and player movements. Since player movement contains one point every 50ms or so we get a flood of points and use the Reumann Witkam algorithm (which was originally designed to compress GPS paths :) ) to compress the paths to about 15% of their original size (without any visible dataloss). The path is stored alongside the kills in our database.
How do ingame coordinates translate to the map we're showing?
The map you see is actually the commandmap which is included in the .pk3 of any map (with some exceptions like supply or adlernest where I put some ingame shots over the map). The .pk3 also contains the maps .bsp file which is the actual map. From this file I extract the worldspawn entitiy that describes the coordinate system used by this map and how to translate it onto the commandmap. After you know this you can just convert the 3d coordinates into 2d coordinates and put them on the commandmap-image. The canvas element described by HTML5 actually makes this very easy, more on that in the next paragraph. Click here and scroll up to the map - it'll show you how the game places its coordinate system.
And how are the maps actually drawn?
This is where HTML5 joins the occasion. It defines a new element - a canvas - which allows us to interactively draw on it using javascript. It uses its own coordinate system but it provides an interface to scale and transform it. Knowing the Enemy Territory maps coordinate system I use those to translate the canvas' coordinate system so it behaves exactly the same. So now I can draw any "raw coordinate" from the demo indexer onto the canvas and it'll show in the exact position where this event happened ingame.
Before that however your browser needs to know the coordinates. Here is where another HTML5 feature comes into play: localStorage. Like cookies it allows a website to store data on your computer - up to 5 Mb usually. When you draw stuff on the map your browser will query the website, receive all coordinates required, store them in your localStorage and then draw them on the map. (You can actually see that when you draw a path the 2nd time it'll be much faster than the 1st time).
Potential pitfalls
Depending on your hardware this page might appear sluggish. This is caused by the amount of data. Eventhough paths are already compressed they still contain hundrets of points for every player and several thousand for all players and all maps of a match. Additionally, if you use the "Time Gradient" method rather than a fixed color we also have to calculate the correct color for each segment of the path. Also, the canvas is not cleared when you draw new data; this allows you to compose a map with all sorts of data displayed differently. This means of course that when you draw a path and leave it selected when you draw again, it'll actually be drawn twice - so keep that in mind when you play around.