#sicced.et vs Good Bad and Ugly (4025 views)

4
#sicced.et de
2
Good Bad and Ugly ee
de bitch
de Achi
de Knutbert
ee Angel Eyes
ee dR flaSh
ee aNdr3
Opencup Fall 2008 3v3 Divison 4
27.10.08 21:00 CET

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.
  • sicced
  • gbu^
  • 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.