You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new matchmaking code does a great job of allocating games to new (high sigma) bots. However, a lot of the early games are duplicate effort. For instance, I submitted new botcode last night, and got results from ~20 games in just the first couple minutes, which is incredible. However, all of those games were very similar and against very similar types of opponents, and in several cases, the exact same opponents. I think it would be better use of worker resources to run games in series, rather that in parallel, so that the results of each game can be used in choosing opponents for subsequent matches.
I'm unsure of the "right" way to address this issue (@Janzert suggests it may require a schema change). However, I'm wondering if at the time of game start, an entry in the games table could be inserted with the current timestamp (this row is then updated with the relevant info at the conclusion of the game). The purpose of the initial insertion is to get a timestamp associated with each bot with a game "in progress", and then when choosing bots for new games, you could exclude any bot with a timestamp within last N (60? 120? 180?) seconds -- or with a recent timestamp and incomplete results, suggesting that game is still in-progress.
The file with the relevant code:
Halite/website/api/manager/ManagerAPI.php
The text was updated successfully, but these errors were encountered:
The new matchmaking code does a great job of allocating games to new (high sigma) bots. However, a lot of the early games are duplicate effort. For instance, I submitted new botcode last night, and got results from ~20 games in just the first couple minutes, which is incredible. However, all of those games were very similar and against very similar types of opponents, and in several cases, the exact same opponents. I think it would be better use of worker resources to run games in series, rather that in parallel, so that the results of each game can be used in choosing opponents for subsequent matches.
I'm unsure of the "right" way to address this issue (@Janzert suggests it may require a schema change). However, I'm wondering if at the time of game start, an entry in the games table could be inserted with the current timestamp (this row is then updated with the relevant info at the conclusion of the game). The purpose of the initial insertion is to get a timestamp associated with each bot with a game "in progress", and then when choosing bots for new games, you could exclude any bot with a timestamp within last N (60? 120? 180?) seconds -- or with a recent timestamp and incomplete results, suggesting that game is still in-progress.
The file with the relevant code:
Halite/website/api/manager/ManagerAPI.php
The text was updated successfully, but these errors were encountered: