Inconsistency in time per turn

I currently have 2 algos uploaded that are duplicates of each other. When playing against the same opponent one loses 9 more health due to damage from time out. Admittedly I should optimize my algo so that it takes 0 damage from time out but I would think that the timing should be consistent for the same algo given the same board conditions. Is this expected behaviour?

The 2 matches in question are and


I had the same issue last season

currently I feel that there is quite an issue with this. My algos take also way more time damage than normal (They used to take none and I did not change the way I manage time, nor the managing core of my algos)

@arnby - I agree that something is dramatically different and it’s having an adverse affect on some top algos. Right now it’s benefiting me as my new algo is seeing some opponents whittle themselves away in close matches, so hopefully they can fix whatever is going on soon.

yeah I’ve had a little trouble against some of your mazes due to time. The maze defense has historically been noticeably slower for my pathing simulations, which may be an unintended benefit of the defense haha.

Although my same programs about a week ago seemed much faster, even in similar situations. Maybe the server is under some sort of heavy load recently?

Even Raptor loses this match on time.
7-0-2019-16-20-19.replay (4.6 KB)

Heh, that could be my fault to be honest, that version of raptor was very unoptimised :sweat_smile:

Me and @KauffK where having a great game here:
both just slowly killing ourselves…


oof ouch owie, mah health points :dizzy_face:




Never thought I’d see a Jojo’s reverence here :joy:


Hey, haven’t posted on this thread but this is probably related to the server issues causing games to crash as well, with the root cause being that our servers have been having a bad time. Working on it.

1 Like

Has the server slowdown returned? I haven’t seen any crashes yet but I’m starting to lose identical matchups due to timeout. Substantial differences between identical versions of mine from several days ago vs today, between 11 and 20+ additional timeout damage taken. Turn-by-turn comparison seems to show that all turns are around 1.5 to 2 times slower. For resistance to slowdowns I tried to keep turns to around 3 or 4 seconds during complicated decisions, but similar turns today are between 5 and 8 seconds.

I also saw a couple turn zero crashes again this afternoon.

@C1Ryan - Guess it’s time to turn the server off and on again? :slight_smile:

1 Like

Oh, yep I’m seeing some on my algos now

Now all the top players on the leaderboard are getting roasted by your programs @n-sanders 'cause they all suffer disproportionately from the slowdown :rofl:

Yeah, I hadn’t expected my quick and dirty algo mashup to start tearing it up quite that much :smiley:
It was intended to be for intel-gathering purposes, but I’ll enjoy the bragging rights for at least a little while.

Also, it’s clear there are a couple top algos that don’t track their own time per turn to abandon deeper searches when they run low on time.

Yeah, the slowdown seems to manifest in different ways depending on how people are using their simulators. For the ones like Oracle, which I’m pretty sure just keep searching until time is up and then go with the best thing they could find, they don’t typically time out but they do make worse moves, and thus can sometimes be beaten in that manor.
Meanwhile, other ones cough like mine cough aren’t performing open-ended search, but are going through a deterministic predefined (but large) set of options to evaluate and thus don’t have any non-destructive way to abort when time is out. This approach seemed okay when the run time is budgeted into the design, but when 3 second turns become 9 second turns the next day that approach starts to break down.

Yeah, I think Oracle and Lazy both do open ended searches (which I give huge kudos to). I’d hope they’ve done a bunch of work in prioritizing those searches though.

My heaviest algo will sim upwards of 250 sims in a turn (that’s my bear-cave line of algos) depending on how many cores I can spend. I’m guessing it’d be similar to what you describe as a deterministic predefined set of options. But my timeouts interrupt in such a way that I can use whatever “best” simulation I’ve discovered thus far and I’m exploring in a breadth-first manner. I do appreciate rust’s out-of-the-box performance gains over python though. I definitely don’t know python well enough to optimize it for performance.

Ultimately I hope C1 is able to get a long term solution in place - I’d much rather all our algos are running at their highest level of performance.

Also, I’ll be glad once we’re past this stretch of so many duplicate algos running around. I totally understand why people do it (and have done some myself), but I don’t think the algo ratings system handles it well when wins or losses are being stacked against duplicates.

Yeah I’m personally guilty of the duplicate thing lately. With the slowdown on top of the general non-determinism of several top algos, I feel like I have to see each new version perform at least 3 or 4 times to get a good idea of how well a change it actually stands in the elimination tournament. It’s all a game of probabilities now.

1 Like