Modus Operandi vs Adversus (8385 views)

au shaggy
au haste
au ringo
au trac1d
au maxxxx
au chevron
xx coach:
au Demanufacturer
au Dersaidin
za HM
au Iceman34
au Noname-
au riCo
au Ike
xx coach:
au Mahadeva
GameArena Grand Final

Can Adversus follow up their minor premiership and become the first team to take back-to-back GA ET titles. Will Modus Operandi take revenge after their season 7 falter, and show us why they've been a stalwart of ET over the years? We'll find out this Sunday!

In the GA grand final, both teams nominate a map of their choice. The first team to take two rounds on a map wins the map, and teams must win two maps to take the title. If both teams take a map each, the match will move on to the tie-breaker map. Adversus have nominated SW Goldrush TE, while Modus Operandi have chosen Supply Depot. The tie-breaker map is Beach.

Gamestah's Ej & BoB will be calling their eighth consecutive GA final, and there will be hundreds of ETTV slots available in order to watch the action.

(shamelessly stolen word for word from au Rogue: here)

--

Shoutcast @ http://www.gamestah.com/file/view/714
17.12.06 11: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.
  • mo*
  • teamadv/
  • 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.