I think this has to do with the target selection step. I do not believe that the scramblers “communicate” with each other when choosing a target, and neither does the stack of pings share a health pool. They simply all point their guns at the first ping on the stack, dealing 30 damage to a 15 health ping, blasting it away. Then they deal 30 damage to the next 15 health ping, also blasting it away. The same is true for the pings targeting, and since some scrambler damage is “wasted” on each step, they don’t kill the pings as optimally as possible.
I am not 100% sure this is correct, I only went and read the rules and doc section and interpreted it.
C1Ryan said: “… but a single shot will not spill over to another unit.”
@KauffK I think that you are partially right with your answer.
If there are 3 Scramblers and let’s say 3 Pings, the first Scrambler will take 10 stability from the first Ping, the second one 5 stability to finish off the first Ping and then the last Scrambler damages the second Ping.
I think this might be the solution, but I have to double check this first.
A single shot will not spill over to another unit, but a unit will not target a unit that is ‘marked for death’ during the targeting step.
With 5 pings and 3 scramblers, 3 shots will be fired per frame. Each shot deals 10 so its takes 2 shots to destroy a ping. I would expect to see 1 ping die, then 2, then 1, then the last ping.
Testing this on playground, it appears to be working as expected, but there does seem to be a visual bug where the death animation is playing but the ‘unit count’ number is not being updated until the pings take a step.
I am looking into these specifics now as well because I am writing a “turn simulator”. I believe that the docs are not nearly detailed enough to actually capture how damage is dealt.
Consider the following example: There are 10 pings in range of 100 scramblers. How many frames need to elapse before they are destroyed? If targets are chosen consistently and simultaneously, then the answer is 10. If damage is dealt simultaneously, and targets are chosen inconsistently (e.g. the targeting rules are not enough to define a unique target, and there is no consistent internal rule) then the answer is anywhere between 1 and 10. If damage is not dealt simultaneously, then the answer is 1.
It seemed obvious that damage should be dealt dealt simultaneously, otherwise the rules are not complete, but this is not the case. I just checked in the by-hand mode, and a stack of scramblers will destroy a stack of pings in 1 frame. I think that this is a serious problem for anyone that wants to write an accurate simulator – when damage is dealt, it affects the targeting of subsequent units, which means that there needs to be a set of rules to specify /who chooses a target and deals damage first/.
Whether the ordering of attacks makes a big enough difference to matter is a separate question.
EDIT: After seeing @RegularRyan 's answer. How is it determined how to mark a unit for death? The order attacks are made matters. If there are 2 pings, one with 9 stability and another with 1, both in range of a destructor and a scrambler, the outcome depends on who shoots first.
Attacks are concurrent. Units “marked for death” attack regardless of having 0 hp.
Edit: It appears to be undefined. When my team was testing this during the live event last week, we found that two units can destroy each other in a specific test case and assumed it was a defined behavior. Have yet to see a situation otherwise, but my best guess is that dead units aren’t culled until after the turn. Haven’t tested for what types of units attack first though.
I agree that it is a problem that we have a number of undefined behaviors.
I want to resolve this as soon as possible but my current priorities are:
Winning the C1 Ryan challange
Resolve the pathfinding bug
Pushing out the next matchmaking changes
A few other chores and tasks
So im pretty booked, but will try to encourage another engineer to take this. If not, I can probably handle it next week. For now, continue to share any undefined behaviors anyone comes across.
Good news for myself is that after making some changes based on feedback here all the tests I set up for my simulator are passing – it probably isn’t a perfect recreation but hopefully close enough
Nobody will blame you for slacking on this action point . At least not from the community…
Actually I was wondering, what is the format of the C1Ryan challenge? Maybe there is a forum post about it that I missed?
Quite a few of us seem to be working on action-phase simulators. I wonder if it might be beneficial for everyone if we cooperated a bit more? I know it’s a competition, but all of our simulators will eventually converge to the same thing, and it seems to me that the challenge is (or it should be) more about what you simulate and how you use that information than how advanced your simulator is.
Also, how fast are your simulators? Mine can run maybe 5-15 simulations before hitting the time limit.
@Thorn0906 I think you should create a separate forum post about this. I think I now have a working turn simulator as well, and would be fine with publishing it on github if it isn’t against any rules or code of conduct. Similarly to you, I can do around 1 simulation in 200ms – my pathing algorithm is quite fast, but I think there is a huge bottleneck in choosing targets.
I created a new post. I also did some profiling and found that the top few functions taking most of the time are in_arena_bounds, get_locations_in_range, get_target, get_attackers, and my own get_encryptors, which is the same as get_attackers. So, small functions in game_map and advanced_game_state. I optimized these some (e.g. in_arena_bounds can be separated into two parts, so only half the computations have to be performed), and that helped a lot.
Its just going to be a single elim, same as most of our competitions, except I will be participating in it. I’ll probably put my algo up like a day before so it has time to reach #1 on the leader-board before the competition. It will definitely be interesting to see what the maximum reachable Elo is in the current ecosystem.
Its actually a pure-random algo that is capable of making any move in the game, i’m just banking on this being the branch of the multiverse where that strategy pays off.
I really hope this means that you’ve got everything in place to crank up the matchmaking rates, because at the moment I’m pretty sure your algo couldn’t get to rank 1 even with 24 hours worth of consecutive wins.