Starting TC distribution help

[b2198]

Sorry for the time it took, I now only have time to work on this on my weekends, so that slows down the progress by a lot.

Anyway, first "working" version of the next step (choosing the "least unbalanced" combination of focal points to use as starting TCs) is completed.
I only tested in Riverside this time because the logic will have to be changed considerably in regards to distance (more on this later)

Tests:

FFA 2 players, 10 focal points


FFA 3 players, 10 focal points


FFA 4 players, 10 focal points


FFA 2 players, 15 focal points


FFA 3 players, 15 focal points


FFA 4 players, 15 focal points (might take a while to load, I had to spend some minutes compressing this one to fit in the 8MB Discord limit)


Notes:

• Combination score is calculated using an "harmonic-like" mean of the distance's standard deviation, score's standard deviation and the distance factor. The formula is currently this: score = 3 / ( distanceDeviation + scoreDeviation + 1/distanceFactor ). Doing it like this means that none of the 3 factors alone can push the score up too much, but any of them can bring the score down by a lot if they're too bad.
• For 2 players, at least for me, that seems a good choice
• Idk what a good balancing would be for 3 players, so not sure if these are good enough or not. Probably would have to be adjusted for some distance issues.
• For 4 players, it seems a good enough choice, but I still think they might be a little too close? Distance issues etc.
• Haven't tested with teams yet because there's yet no logic that takes that into account, will have to think about how to implement that later.
• Yeah, combination count doesn't scale very well (it scales in a factorial manner, so... ), so I think there should be a limit to amount of focal points, will test the performance to see what that limit should be (considering player count can't get past 6, I think it should be somewhere between 15 and 30, though with 30 the testing script would take ages when trying to make an image of a table with 197295 rows lol). Also this could be improved in larger maps by reducing the amount of focal points required, by changing the measured distance according to the map's size (so focal points would make a larger "score hole" when chosen).

About distance: now it's time to make the distance be measured in unit movement cost, instead of simple grid distance, but here I have many problems that I'm not sure how to solve:

• How to determine which unit should be used to calculate the cost? This one could be passed as an input, like a mix of light cav. and barcha longa, for example (a mix of their trnWalkTerrain, I mean). Probably will need a lot of tweaking too.
• This one is my main problem right now: in other variants (and in the future in AoS too), players can choose their race/country/culture/etc., but afaik the tc generation happens before all players join the match, so it wouldn't be able to account for different races/etc. having different units with different movement costs. @Stratego (dev) is it possible to move TC generation for after all players join, instead of when creating a match?
• After the above problem is solved, how would the algorithm calculate for many different races/etc. in a game? I mean, each of them might have units with completely different movement costs, so how would distances be checked between focal points, or even for finding the focal points themselves?

[b2198]

Ok, and back here I am, after almost 2 more months...

Progress wasn't very big, just improved some parts of the logic, like:

• Distances for both focal point calculations and combination choosing now use "unit" movement as a reference, so they now take terrain into account heavily when checking how far things will be from each other.
• Distances for focal point calculations now take into account the map size (for combination choosing they were already doing that)
• Water bodies now properly reduce scores of water tiles with "other obstacles" in them

Along with some considerable refactoring to the code to make it easier for myself (and for Stratego, in the future) to read, fix, improve and/or extend it.

I'll now be trying to implement the next steps with as few "extras" as possible, to make a first minimally working code ready to be tested in-game as fast as possible. That means the quality of the overall algorithm will be considerably inferior to what it could be in the first patch where it gets added, but will be getting improvements from there on, instead of beforehand, as to make it able to be tested in-game earlier than it would otherwise.

One of the things I'll do to try to achieve that is reduce testing to the simple case of 2 players, 1v1, no pre-placed TCs and/or spawners case for now to make things simpler for now (will go back to testing with more player configurations and actually implementing the full logic for pre-placed TCs and/or spawners later on, just skipping those for now to make things faster).

Some good news are that starting positions for this specific case seem reasonably good, so that's a plus

Anyway, here are the current test reports:

Riverside:


Tropical Islands:


Tropical Ocean:


Perilous Realm:


Indogletser:


Aerolian:


Great Greenfields:


Previous steps (that are already completed):

1. Create a score system that checks for some properties of tiles and groups of tiles and decide individually how good each of them is.
2. Combine these scores into a single score that tells the overall quality of every tile in the map
3. Implement the code that calculates focal points (basically "candidates for starting locations") in the map
4. Implement the code that takes every single combination of focal points for that player count and compares them against each other, trying to find the best one
5. Change distance calculations to be based on unit movement instead of simple grid-distance.

Current step (that will begin now): Implement the code that calculates player "territories" (areas over which players will likely have control early in the game)

Next steps:

1. Implement the code to generate the "nearby TCs" for each player (the TCs that are usually 1 or 2 turns away from your builders at the start of the game)
2. Implement the code to generate the "territorial TCs" for each player (the TCs that are likely to be taken and defended by that player early on, due to being inside their "territory")
3. Implement the code to generate the "contested TCs" (the TCs that are outside any territory and have a higher chance to be on the early frontlines, positioned in a way that tries its best to not favour any player)
4. Send e-mails back and forth with Stratego about how to actually integrate the code to the game's logic XD
5. Start tests in AoS
6. Improve a lotta things

[DreJaDe]

Not related but looking at this post lags my phone for some reason.

[Stratego (dev)]

awesome!

when you can send me the "skeleton" (without extras) i can put in so we can test in game the results! thanks!
maybe i can even put a devloper "switch" where you one turn on and of the newor old algorithm

daniel

[b2198]

This time impressively in less than a month (by 3 days lol XD).

The basic logic for territory calculation seems to be working well enought (apart from some issues that will need to be fixed later, mainly regarding water and mountains). I won't be posting the full reports this time due to them lagging the page, so instead I'll just post the new section I've added to them (and as far as I hope know, everything else should still be the same):

(The numbers represent how much it would "cost" to reach a tile in terms of movement)

Riverside


Tropical Islands


Tropical Ocean


Perilous Realm


Indogletser


Aerolian


Great Greenfields


These territories will be the base for deciding where to put the "nearby TCs" (the ones that spawn very close to your starting one) and the "territorial TCs" (the ones that the game thinks you're gonna get safely), and distributing the "nearby TCs" will be the next step I'll be doing.

[makazuwr32]

@b2198 any prpogress?

[b2198]

@b2198 any prpogress?

Oh, I forgot to mention it here, but I wasn't able to keep working on this, and sent it with just the starting TCs and territory calculation in a working state to stratego a while ago. I think he's waiting for the Unity version to become the main one to port the code to C#, since adding it directly in the Android version right now would be double work, but that's just a supposition on my part.