MATH: Calculating the DF factor

[dcode]

Hello everyone,

as mentioned in the 1.1 public beta announcement it's our final goal to be able to calculate the df factor for each map automatically. For that I created a first approximation:

1. Calculate the "weight" of each path segment
The weight of a segment means "how often does a creep come along". So, a normal path segment always has a weight of 1.0 while a segment behind a 50:50 alternate has a weight of 0.5. Underground segments are not reachable and therefore have zero weight. When there are stops, there will be N path segments with a weight of 1.0 (N*1.0 total).

2. For each buildable cell calculate the reachable weight by looking 2 cells in each direction
Around each buildable cell a range is approximated (5x5 square without edges) and the weight of every path segment in that range is collected into the final sum that will somewhat reflect the "usefulness" of that building cell. So, a buildable cell that reaches 3 path segments with a weight of 1.0 each will result in a sum of 3.0, meaning "the average creep path reachable from this cell is 3 segments (usefulness=3)".

3. [unsure] AI_df_raw=totalUsefulness/totalCells
Finally I flatten all the collected values by calculating the average usefulness of every single cell on the map.

Some values:
QUADCORE=6.703
RICHTUNGSWECHSEL=5.258
REDWORLD=3.734
VORTEX=2.175
SPEEDVECTOR=1.391
FLYINGORB=0.9375 (not so smart!)

A higher AI_df_raw value means that the AI needs to be stronger while a lower value means that the AI needs to be weaker to make playing the map fun. The final task would be to adjust the AI_df_raw values to match the real AI_df (income factor of the AI) by linear scaling.

However, I am not yet sure if this approximation really reflects the difficulty of each map. I assume it will be required to just focus on the "top X" spots on a map to make that work out (see FLYINGORB). What do you think? Any improvements?

Aber mit 1.05 konnte man super Coop-def üben...
Also die Rolle des Deffers im 2vs2 coop.

I think that it's a good idea to have a mathematic way to rate te maps.

But i am not shure about the way you do this...

In your formula, dcode, you seem to guess, that every tower-position is used (because you divide with the sum of cells).

Espacially in the beginning you use maybe 2-5 cells for towers, which are NOT layed on a "straight" path, but often in corners e.g.. Only at the end it might usefull to rate with every cell.

So, the value you got should maybe be a dynamic value.
For example for the first 10 rounds only the "best 5 positions" like corners are counted,
then until round 15 ...8 postitions, round 20 11 positions.
(just a few values which are obviously wrong and stupid....)

In my opinion the "dynamic" value is a better way, which of course reaches the value you suggested in round 100 or 150.

Just my two cents

[dcode]

You are right, I am also thinking about using only a couple of spots for the calculation. The calculated DF value mostly is some sort of "starting factor" for the AI, so that it might not be neccessary to make it dynamic in general. With that in mind, everything beyond the starting factor would be map specific and depends on the map's general characteristics.

I think next I'll try to use the best 6 spots or so and mix it with the map's general path length to form the factor.

[dcode]

Ok, I changed the formula accordingly. However, I'll need the DF factor of QUADCORE to linearize it. If anyone of you has some spare time and wants to help me finding it, give it a try I guess 200% is also too much for QC.

Current approach:
1. Calculate the usefulness of the top 8 def spots (SV=5.875, QC=32.375) and linearize it to ufnFactor=0.0 - 1.0
2. Calculate the minimum length (SV=31, QC=232) and linearize it to lenFactor=0.0 - 1.0
3. df=1.0 + ufnFactor/3 + lenFactor/3
4. Tweak it...

speedvector: 1 (100%)
redworld: 1.17165743609 (115%)
flyingorb: 1.341601739729 (135%)
richtungswechsel: 1.3199255295848 (130%)
quadcore: 1.6666666666667 (165%, unsure!)

I think it is a good idea to take the best positions into account. I played Stones the other day and - if i remember right - had a df factor of 1.5 and it was pretty hard. Of course i may have made some mistakes but while i had 1,5k income, i had to face a wave of 2-3 raiders and that was really hard to defend.

..

[dcode]

Actually the usefulness is calculated this way:

1. Weight all path segments on "how often does a creep come along". This takes care of alternate routes, so if a path segment always is passed through by one creep and additionally by another one with a 50% probability (e.g. a goto A,B alternate), it's weight would be 1.5 for example.

2. Around each building spot where a tower can be placed I test a square of 5x5 cells but without edges (as a very simple approximation for a tower's range) for reachable path segments. For every reachable segment I collect the weight from step 1 so that the usefulness of the building spot is the sum of all weights of reachable path segments in that 5x5 cells square without its edges.

What I've got now is a value between 0.0 (no reachable path segment at all) and probably a very large number for lots of reachable path segments / many path sements with large weight for each building spot.

3. I sort these values from high to low and return the sum of the 8 largest usefulness values (of the 8 most useful building spots) and divide it by 8. For simplicity I scale that factor to 0.0 for SPEEDVECTOR and 1.0 for QUADCORE. This is the ufnFactor of the map that I later on combine with the general lenFactor (also scaled for convenience) using the formula I posted above.

I am not sure how close this is to a real world scenario yet, but as soon as I know the real DF factors for let's say SPEEDVECTOR (shortest/hardest) and QUADCORE (longest/easiest) I could simply create a formula that linearily distributes all other map's df(ufn, len)=X between these two real values. Afterwards I could test the calculated values on some maps and validate or invalidate the underlying weighting of ufn vs. len...modify it...test again...modify it...until it's close enough to practice. That's actually what I need some "good" values that can only obtained by testing for...to tweak the formula to match them

There are just a few variables in this formula:
- A; The number of maximum building spots to take into account (currently 8)
- B: The weighting of the ufnFactor
- C: The weighting of the lenFactor

Ergo: df(map)=1.0 + ufnFactor(map, A)/B + lenFactor(map)/C

What I already know is:
df(SPEEDVECTOR)=1.0 based on ufnFactor(SPEEDVECTOR, A)=0, lenFactor(SPEEDVECTOR)=0

What I need to know is:
df(QUADCORE)=? based on (these would be to weak:) ufnFactor(QUADCORE, A)=?, lenFactor(QUADCORE)=?

..

[dcode]

The factor isn't meant to extend the time you play on SPEEDVECTOR compared to a normal game (which is very short in general). It's meant to reduce the time on longer maps like QUADCORE to be able to create some real highscores with a broad spread. The problem about really long maps is that it's a combination of luck, tower settings and a long time not doing anything before the game ends.

On SPEEDVECTOR, though, you can reduce the difficulty below 100% just for fun or for practice without playing for the highscore

Bimm, why does it seem pointless to you if you cant kill the first shark on Speedvector? In an normal all vs all game or random send, you can't kill the first shark either if someone saves a bit the money. I think the advantage of the new survivor mode is that you really have to think about where to put your towers and how much money you invest in building and upgrading them because otherwise you will be behind with you income. And that makes it much more interesting.

As dcode said, especially in long maps survivor mode is just really boring. Goal is to get up your defence as fast as possible and then sit and wait until the game is over.

..

[dcode]

The server always uses the exact same sending scheme for each map (at least it should). So it's not random and you can improve your highscore with every new try.

..

[dcode]

That's SPEEDVECTOR. Survivor mode should be a good practice for competitive games - and for everyone else who just wants to have some fun, there is the possibility to reduce the AI's difficulty to as low as 50%.

I really try but I don't get your point, yet.

..

The highscores will be sorted by rounds first and income secondary.

And second, if the AI is completed we will set the percentages for each map. Maybe we can find good ones for SV so that you don't die by the first sharks.

First question: What is DF factor? Where does the "DF" come from?

This is a very good idea.

I came to notice that many new maps that have been added to the map testing list do not have TBC values set, so I went snooping on the forums here, and this is what i found that i think is most useful.

I've been trying to wrap my head around this for a couple days now, and i have a couple questions/comments that could help clarify this equation for me.
(for the record i know this post is a year and a half old)

First, know that I have been trying this on SV, as it is a very easy first example for me to try. On SV, dcode stated that there are 31 minimum lengths to SV, i only count 29, but then i went into the SV zip folder, checked the creep path myself in notepad, and i found that the path is indeed 31 lengths long, as there is an extra 1 path at the very beginning and very end of the path. The issue, is there are only 29 target-able path segments. As the creep spawns, it is still off screen, as such, i think the first and last path segment should not count, as technically they could/should be considered 'underground' segments. So, I have reason to believe this 31* is wrong, but to acquire the understanding of this equation i will use the value of 31, just to see if i land the same number you got (1 (100%))

When Calculating the usefulness of the top 8 def spots, i used the 8 on the inner corner. my values for the usefulness of the top 8 def spots are as follows, 7 8 5 8 9 5 5 5 (52/8 = 6.5) (Sample 1) (the value calculated previously in this thread was 5.875.

Untitled.jpg (84.2 KiB) Viewed 17073 times

as you can see in the above image, i never got that value with 3 methods i tried, (Sample 2 & 3) so, I must be doing something wrong.
To reverse the equation might help in identifying what values were used in the previous posted equation.
5.875x8 = 47
Using the number 47, i messed around with the 8 separate values until their combined total was 47. (Sample 4)

Untitled2.jpg (30.71 KiB) Viewed 17073 times

That done, i will state the every path segment on SV has a ufnFactor (usefulness Factor [creeps cross that path once only] of 1. Therefore the usefulness of each of these 8 towers are ALL the SAME as their 'weight'.

Quote:
"I sort these values from high to low and return the sum of the 8 largest usefulness values (of the 8 most useful building spots) and divide it by 8. For simplicity I scale that factor to 0.0 for SPEEDVECTOR"
[QUESTION] This statement says this:???:
there are a total of 227 build spots on the map, most of these spots have a ufnFactor of 0. sorted form highest to lowest, he removed the 8 highest values, and divided by 8. (?) So, of the 227, 219 are used for the calculation, and the total of the 219, is then divided by 8 again? resulting in a rounded 0?

The next part I'm having trouble with as well.
Quote:
"Ergo: df(map)=1.0 + ufnFactor(map, A)/B + lenFactor(map)/C" "- C: The weighting of the lenFactor"

So.., the lenFactor of SV is 31(quoted) is it not? the weight of the length factor for SV is 31 is it not? 31/31 is 1, not 0.
I'm pretty sure I'm missing something here, but I'll wait for some answers before proceeding.

AGAIN, yes i know that this is an old post, but unless your about to tell me you (CreepTD) have no interest in perfecting this equation/method, I'll keep pushing.