Tournament Fairness and Resource Distribution

Hi Guys,

I do apologize that I’m only sending this now but the engine changes was quite short notice so I have limited time to tinker.

I ran 4 differently seeded maps where I only played my own bot against itself in a 4V4 setting.

Worldseed: 52323, 31726, 91825, 19288

My results for the above always had my player A bot win.

At first I reasoned seed plays a big part, But that does not explain how my bot with the exact same population growth for the vast majority of the match would end with Player A bot having 100 000 stone Player 2 had 50 000 while Player 3 and 4 both at 25 000

Because of storage limitations positional advantages are almost completely limited (depending on the strategy and level of a bot)

Then I traced the way the engine works and realized that:
This AddAction Function in Botobject.cs line 50 triggers individually for each bot,

So I did something weird, I added a 200 MS delay to my player 1,2 and 3 bot, and suddenly my player 4 bot (who sent commands first) won, Went from last place to firstplace by adding a delay,

This means that the current engine advantages moves made quicker unfairly.
Especially a issue if different languages have different processing factors.

So the conclusion is the bot that submitted moves first gets all the spoils.

The most probable solution is to wait the full 200MS, only process moves at the very end. (So that you can assume all moves are in),

Then you can calculate the total amount of “legal units” inbound to a node from every player.
Then you can assign a percentage to every player and example say if players sent the following units to nodes:

30,40,20,10 then its 30%, 40%, 20%, 10%.

And either the resource distribution is split or the base current Nodes are.

As this is an issue of fairness I do feel it supersedes any code freeze.
My own bot isnt very hard on time. But you definately do not want people who use AI libraries and time based processing to walk into a deathtrap either.

I still believe in fair.
This is very important. The solution should not be too complex, Mainly because you can assign weight to every player.

In the end I had to test my earlier question of:
What happens when two players sends units to the same node.

What happens to the weight if the 1st person who sent the command for their units to completely mine the node (100 units), and to the 2nd second person who sent the a command of 30 units to mine the node.
Then bot one get 100% and bot 2 get 30% of the resources? The engine does work on a first come, first spoils strategy as they are using a queue to process commands. So a person who have a crazy quick AI processor will always have advantage to a badly designed AI processor in that 250ms. It’s all still based on time, who can get their quicker, will get the spoils.

I do agree with the resource distribution concerns. But playing a large amount much games during the tournament would negate that concerns of a unevenly distributed field?
What random generated are EC using for resource distribution calculations?

Hi WillieTheron,

Thank you for reporting this. The team is investigating and we will evaluate the impact of this and whether it constitutes a change this close to the tournament.

1 Like

If person A sends 100 units and Person B sends 100 units, and theres a max units of 100 on the node.

Person A gets 100% and person B gets nothing.

In in some languages there could be a 10 MS processing overhead compared to others.
In cases like this the exact same level and efficiency of code will render the player whose language writes slower paralyzed in cases where 2 players target the same nodes.

Im confident in my bot’s processing speed.

But thats not what this is about.

A true AI would use 200 Milliseconds and then submit their moves.

When you send commands should not impact if you get resources.
**I would rather then say let the closest player to the target node get all the rewards which honors location.

And would allow us to play distant nodes in order to preserve future advantage.

Its merely a point of fairness.

if the engine gave 3 res to player 1 and 1 to player 2 for the same action then it would be deemed unfair.
And that would be fixed.

The same is happening here.

beyond fairness I dont care how bad a bug is. As long as it does not undermine fairness.

Thats my opinion, but im crazy serious about fairness as a constant

I think that unit allocation to the node (CurrentUnits) should only happen once the units start working, in other words after the travel time, and that whomever gets there first gets the loot. This would mean that sending units to a node when it’s already at max capacity would not be considered an invalid command because it might not be full by the time the units get there. This would by default prioritize the closest player to the node, since the further player would have to send units to the node several ticks earlier.

This raises a few questions of it’s own though.
What happens if 2 sets of units arrive at the node on the same tick? Maybe a weighted % split?

What happens if a unit arrives at the node but the node is already full? Or there are more units than capacity at the node? The excess units could possibly be returned to base immediately without any resources, or wait out the working time and return without resources. Alternatively they could queue for the resource and wait for an available spot but I think that could lock up units and introduce a lot of unnecessary complexity.

What happens to units traveling to a node and it is consumed entirely while they are traveling? Either send them back to base the moment the node is empty or the moment they get there.

They get what they deserve for using garbage languages ⸮

I am uncertain about this.

To explain my thoughts, We know that the most efficient bots will conquest their domains first.
This means that a slower bot will always have preference to their own resources.

In a very unique case we could have matches where a slightly less efficient bot gets saved by resource priority.
**This would add an excellent dynamic of sabotage, but be pretty bad for endgame where everyone is capped by resources.

The other issue I have is to avoid unit action blocking (taking res an opponent is going for)
I do not believe we should have access to exact enemy commands. Our own yes, but not enemy. Uncertain if its like this already.
And without access to enemy commands, It will be hard to know when units will arrive and leave from a base. So you will be blind most of the match,

This is only true for the current state of the engine where we have more units than we have actions. In a case where we have more choices than units this would change completely.

This could be my own preference so not really factual. This might not be too bad if we have a node have data “Units Completing (number of units and tick)” though this would require an intense rewrite of my own AI, which I can deal with.

I do feel a weighted % split is essential.
**but in the sense of if there’s a max units of 1000 units and two players sends 1000 units.

each player gets 500 units in and the rest are returned.

Feels right.

VERY VERY IMPORTANT, Any Weighted split should only be applicable to “LEGAL UNITS”

So if theres 1000 max units available and a player sends 5000 units, only 1000 should be eligible.
I dont feel Node Overload should be a thing.

Just some thoughts out loud.

Good morning everyone,

The team had a session about this issue yesterday and we concluded that we are not going to make any changes this close to the tournament. We will, however, look into this and any possible changes needed for tournament 2

Thanks again for raising this to us and good luck tomorrow!

Solid, No problems then,

If we know the engine state, we can adjust our code accordingly.

I am very likely advantaged by this state (though it does trouble part of me some).
Today my play then is optimization, lets see if I can cut my time usage by 50%, remove any and all actions that will hinder me, get down to that 1 Millisecond.

I carefully assessed the possibility to make a move at the start of a tick, but you kind of need to account for the updated board state. Lets see how this plays out.

One thing that never left me is my paranoia. Always assume that every bot will be near perfect…
Im amped for this tournament.