Add map winrate analysis to the main page

[petrvecera]

The idea is that we know the map name and we can get the winrate for the specific team composition from the database. We could display something like this (attached image) under the main table - btw this is just suggestion, if you have better idea feel free to change it to your liking!

How you can get the data is showed in the app.ts file in the render folder. The database will return object like this

You will need to build a faction matrix key, for example OOxBB: It always starts with german players and than allies. The keys are like this:

const raceIdsShortCuts: Record<number, string> = {
  0: "W",
  1: "S",
  2: "O", // west-german or oberkommando
  3: "U",
  4: "B",
};

There are functions for building these strings packages/functions/src/libs/analysis/composition.ts:21 however I am not sure if they are compatible with your data - maybe yes. They take PlayerReport array data from the API - I would recommend copying that function.

To calculate the winrate - the data saved there are for AXIS. So if we have for example OWWxBSS: {losses: 50, wins: 67} it means: Axis: losses 50, wins 67 Allies: losses 67, wins 50

Winrate Axis (67 / (50 + 67) Winrate Allies (50 / (50 + 67)

---

And I just got an idea that we could display how common is the composition they are plying: We could could total games for each compositon and maybe display something like: Your composition OOWxBBB is 24 most played out of 36 possible team compositions.

^^ but that would be just cherry on top.

Please hit me up if you have any questions / or if you won't have time to work on this , I could take a look on it next weekend maybe.

I think this feature will completely shoot our app to the moon - because it's something no other app like this have!

[JohannesMerkt]

Love this concept will look into this

[JohannesMerkt]

Do we have access to data about the win chance based on play time? E.g. in early game (sub 15 min) allies win 45%, mid game allies win 55% of the time ...

[petrvecera]

Do we have access to data about the win chance based on play time? E.g. in early game (sub 15 min) allies win 45%, mid game allies win 55% of the time ...

We don't have that, only games which ends in the particular time slot

Hm I don't think we could measure faction matrix for each gametime category - that would be too much data, but we could certainly in future start measuring wins for axis or allies during those times.

[JohannesMerkt]

We shouldnt collect this kind of data. If it was already there I could have made use of it.

[JohannesMerkt]

For the map stats wouldnt it be better to take all matches up to the last patch? Or does this take up too many resources?

[petrvecera]

It would be better to do just the month. The custom range analysis isn't that demanding but if you would do ~1000 / day of them - it would pop on the billing + it takes some time to calculate, example https://coh2stats.com/map-stats?range=range&type=4v4&map=8p_redball_express&fromTimeStamp=1631750400&toTimeStamp=1643673600

[JohannesMerkt]

I think it might be better in any case to try to use firebase in the main process rather than in the render process. That way we can make one request to the map stats a day (or even fewer than that) and cache the response on the harddrive. Since this data doesnt change significantly over the course of the days and can be reused everytime a new match is found.

Edit: Oh actually if we cache the result. We could also just request the timespan from the last request to today and sum this response up with the cached one to get the full data again. This should work since we are just interested in the win losses on maps per team composition

[petrvecera]

@JohannesMerkt it has to bee in the render process because the firebase SDK is not made for NodeJS. There is NodeJS SDK which is this one https://github.com/firebase/firebase-admin-node but it's admin - it's for servers / should not be running on clients.

But I think the render layer can push the data in REDUX and store them there right? Personally I would not worry about this - 1-3k requests / day for the stats would be completely OK.

To give you and idea https://console.firebase.google.com/project/coh2-ladders-prod/firestore/usage/last-30d/reads We currently have around 25-35k reads from the firestore, the limit for FREE reads is 50k/day. More than that we would be paying.

My sentiment is - if we can easily optimize for lesser reads / avoid lot of reads - that's nice! But we don't need worry that much about it - even if we would go beyond the free quota the price is like 0.06$ / 100k READS - which is pretty low, but could be nice to stay free.

Btw firebase SDK supports cache but I've never used it with web, only mobile apps - and offline https://firebase.google.com/docs/firestore/manage-data/enable-offline