Guild Wars 2 Forum - API Development

Additional WvW stats?

I am currently working on a PHP application that pulls WvW stats and performs various calculations (such as projected match end score), which will show the results in an analytics type format (still a WIP). While the current WvW stats provided by the API provide a lot of flexibility, there are some stats missing that I think would be useful for showing players how their servers compare to their opponents and servers in other tiers. More importantly, I think weighing these statistics can reveal balance issues between the server match-ups that otherwise go unacknowledged.

For example, we currently have match time, time for each tick, score, kills, and deaths to extrapolate information from. With that, we can easily calculate stats like score per tick, percentage of score that comes from kills, and the kill-death ratio. But what if we want to know how much of the score comes solely from the +PPT without the score from capturing objectives like sentries? What if we want to find out the percentage of kills that are a result of war stomps? What if we want to show the total number of times each side has claimed keeps, towers, etc. so we can show the effectiveness of their PPT (total score from PPT divided by total number of objectives claimed)? We currently have no reliable method to parse out that type of information from the scores without making repeated API calls every few minutes and storing the data, which requires a lot of additional work.

Would it be possible to provide this type if data in addition to the currently provided information, and provide the same data on a per-map basis like it does currently for score, kills, and deaths?

Additional WvW stats?

in API Development

Posted by: Aidan Savage.2078

Aidan Savage.2078

As for score, objectives have a set score, dont they? If so, it’s just a matter of sorting out what objectives a given side has, itemize the points, and then just do the resulting math.

Additional WvW stats?

in API Development

Posted by: perseco.8321

perseco.8321

Aidan Savage.2078:
As for score, objectives have a set score, dont they? If so, it’s just a matter of sorting out what objectives a given side has, itemize the points, and then just do the resulting math.

That will give you the current +PPT (which is not what I’m looking for), but if you want the average for the week, you have to store the data every tick and then average it out to find the average +PPT. My point is there should be a better method for retrieving that data without having to repeatedly make API calls and store the data.

Additional WvW stats?

in API Development

Posted by: Lawton Campbell

Lawton Campbell

Web Programmer

So, while I agree, there are some pretty large technical hurdles to providing non-current data. As a short primer, the data’s path looks roughly like this:

1. The map instance servers running the WvW maps keep track of the current state.
2. Periodically, the current state is flushed and persisted to the per-datacenter singleton orchestration server.
3. The orchestration server re-emits the entire map state to a pool of backend WvW API servers which mirror the current state.
4. The API frontend servers query the backend WvW API servers to handle requests.

The problems are twofold:

The orchestration server is, from my seat, immutable. It’s a singleton and controls pretty much all of Tyria, so any change to it is rightfully accompanied by hand wringing and many sleepless nights. Sentry and ruins state aren’t currently sent to the orchestration server, so the API will probably never be able to emit that data, nor is the score (PPT vs. PPK) breakdown.
Both the API frontend and backend servers are completely stateless and often restarted. It’s possible to make the backend stateful, but it requires a significant overhaul. This combination makes it infeasible to store anything other than the current state, which is mostly what the API exposes.

The good news is that we’re aware of the issues; the bad news is that I’m not sure when we’ll have improved them in a way that the API will benefit from. In the meanwhile, the periodic polling workaround kind of works, even if it’s a bit of a hassle.

Sorry :<