Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: MetagameInstance empire scoring system #153

Open
2 of 5 tasks
Maelstromeous opened this issue Sep 17, 2020 · 0 comments
Open
2 of 5 tasks

WIP: MetagameInstance empire scoring system #153

Maelstromeous opened this issue Sep 17, 2020 · 0 comments
Assignees
Labels
discussion Issues requiring extra discussion p3 Minor issues

Comments

@Maelstromeous
Copy link
Member

Maelstromeous commented Sep 17, 2020

So, upcoming for the project is Seasons, which I want to implement a scoring system for in order to point alerts for each faction.

However, we can still use this score to judge how well and how fair a faction has been in an alert.

Scoring Objectives

  1. Punish empires with high population averages, being more severe the more pop and less territory they had (zerged without actually getting anything). Reward empires with low populations but have retained their territory (meaning they held their ground)
  2. Punish empires who target particular factions throughout the alert via capturing their bases
  3. Reward empires who use team-player support, e.g. revives, heals, repairs, ammo supplies etc.
  4. Do not factor in total number of kills or deaths into the empire scores, the metagame is meant to be about strategy and teamplay, not farming ability. We will however use empire-to-empire death rates to factor in rule 2.

Therefore, empires who have played reasonably fairly (e.g. not dominate entire conts with 40% pop) and have been efficent with their population will benefit the most. It will also punish a singular empire throwing an alert by just attacking a particular faction, resulting in getting double teamed.

Implementation

Score calculation 1: Pop vs Territory ratios

Taking inspiration from the old Alert Dominiation Score system, thinking along the following formula:

  1. Calculate the average population % for each empire.
  2. Retrieve the end territory %
  3. Award score based off: (territoryPercentWon * inversePopulationPercentFrom33)

Scenario 1: One team gets outpopped and double teamed

VS: 38% territory, 37% pop avg
NC: 22% territory, 28% pop avg
TR: 40% territory, 35% pop avg

VS: 38 * (33 - (37-33)) = 1102
NC: 22 * (33 - (28-33)) = 836
TR: 40 * (33 - (35-33)) = 1240

In this scenario, NC got utterly f**ked over by both VS and TR due to low pops. TR managed to creep the lead over VS by 2%, having slightly less pop and therefore scoring more. NC however aren't fully trashed by this result and are rewarded more than they would if they had full pop. If they did have full pop, they should rightfully get less score due to quite simply just loosing hard. If they had 33% pop with 22% territory, they'd have 726 points.

Scenario 2: One empire gets outpopped but held their ground, loosing slight territory

VS: 32% territory, 29% pop avg
NC: 36% territory, 35% pop avg
TR: 32% territory, 36% pop avg

VS: 32 * (33 - (29-33)) = 1184
NC: 36 * (33 - (35-33)) = 1116
TR: 32 * (33 - (36-33)) = 960

In this scenario, while VS didn't win, they won the scores, simply because they were outpopped but yet retained their share of the map despite this. TR had the most territory and the same % as VS, resulting in them being very inefficent and have been punished hard here. NC had slight overpop and won the alert, but were less efficent with their pop.

Scenario 3: Even fights all round, pop equal, VS outplayed other empires

VS: 35% territory, 33% pop avg
NC: 32% territory, 32% pop avg
TR: 32% territory, 34% pop avg

VS: 35 * (33 - (33-33)) = 1155
NC: 32 * (33 - (32-33)) = 1088
TR: 32 * (33 - (34-33)) = 1024

TR was slightly overpopped, NC was slightly underpopped. NC gets more points than TR in this case despite having equal territory % due to slightly more efficent population usage. VS quite rightfully get most points here as they had perfect pop and won the most.

Scenario 4: VS bossed the alert despite being underpopped, NC did very poorly and had most pop

VS: 38% territory, 29% pop avg
NC: 29% territory, 36% pop avg
TR: 33% territory, 34% pop avg

VS: 38 * (33 - (33-33)) = 1254
NC: 29 * (33 - (36-33)) = 870
TR: 33 * (33 - (34-33)) = 1056

Here, NC did extremely poorly despite having the most pop TR did afterage with nominal populations. VS Had the least pop but got the most territory, therefore being rewarded well for this effort.

Prereqs:

  • Collect population information regularly
  • Collect territory % end result
  • Collect combat metrics on a empire-to-empire basis (e.g. VS killed X NC, VS killed X TR etc)
  • Collect and aggregate experience events relevent to the calculation

Code implementation theory

  1. Create a new handler which attaches to the MetagameInstance endActions.
  2. Using the above metrics, calculate the score (score calculations below)
  3. Update the metagame instance with the new score.

Score calculation 2: Double teaming via captures

WIP - Rough concept in examples

Create a pool of capture points, e.g. 10 per capture. Distribute this pool based off ratios of how little / much a empire has bulled another.

Calculation would be something along the lines of:

  • Total bases captured in the alert, divide by 3 to get an even distribution of a perfect "even" fight
  • Total bases captured by a faction, devide it by 2 to get "even" balance for what they should have captured, the more varience an empire has, punish the most.

Scenario #1 - VS and TR bash each other's skulls in, leaves NC mostly alone

Total captures: 23
500 points in the pool, divided by 3 means 166.67 points up for grabs by each empire.

  • VS captures 10bases total, 2 NC, 8 TR (unfair, heavy bias towards TR)
  • NC captures 5 bases total, 2 VS, 3 TR (fair-ish, got utterly rekt)
  • TR captures 8 bases total, 7 VS, 1 TR (unfair, very heavy vias towards VS)

Calculations:

VS unfairness(1) distribution: 2 / 8 = 0.250
VS point award: `166.667 * 0.26 = 42

NC unfairness(1) distribution: 2 / 3 = 0.666
NC point award: `166.667 * 0.666 = 111

TR unfairness(1) distribution: 1 / 7 = 0.142
TR point award: `166.667 *0.142 = 24

(1) Unfairness calculation is lowest number / highest number to always get a number lower than 1. Perfectly fair = 1. Always to 3 decimal places.

Score calculation 3: Team support

WIP, but rough concept essentially being certain XP event types (e.g. revives, repairs etc) contribute to a pool of score. Round down the result.

E.g:

Revives are worth 1 point per 10 revives an empire does. Engineer repair ticks (times it shows up on your screen) are worth 1 point per 100 ticks (numbers HEAVILY WIP)

Example:

VS = 1487 revives, 12333 repair ticks
NC = 3452 revives, 8865 repair ticks
TR = 2343 revives, 23545 repair ticks

Calculations:

VS: (1487 / 10) + (12333 / 100) = 272.03 (272)
NC: (3452 / 10) + (8865 / 100) = 443.85 (443)
TR: (2343 / 10) + (23545 / 100) = 469.75 (469)

Prereqs:

  • Aggregate XP ticks per faction
@Maelstromeous Maelstromeous changed the title MetagameInstance empire scoring system WIP: MetagameInstance empire scoring system Sep 18, 2020
@Maelstromeous Maelstromeous added the discussion Issues requiring extra discussion label Sep 18, 2020
@Maelstromeous Maelstromeous added this to To do in Aggregator 3.0 Beta via automation Sep 18, 2020
@Maelstromeous Maelstromeous added this to To do in PS2Alerts v3.0 Beta via automation Sep 18, 2020
@Maelstromeous Maelstromeous added the p2 Disruptive issues but not show stoppers label Sep 18, 2020
@Maelstromeous Maelstromeous self-assigned this Sep 18, 2020
@Maelstromeous Maelstromeous removed this from To do in Aggregator 3.0 Beta Sep 25, 2020
@Maelstromeous Maelstromeous added p3 Minor issues and removed p2 Disruptive issues but not show stoppers labels Sep 25, 2020
@Maelstromeous Maelstromeous removed this from To do in PS2Alerts v3.0 Beta Nov 22, 2020
@Maelstromeous Maelstromeous added this to To do in PS2Alerts v3.0 GA via automation Nov 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Issues requiring extra discussion p3 Minor issues
Projects
Status: No status
Development

No branches or pull requests

1 participant