Dan's Crazy Ideas #5 - Persistent data storage

Admittedly, my ideas get less and less “crazy” as time goes on. Idea #4 (Chess clock) was actually a pretty good one, if I do say so myself. Same with this one. More evolution than revolution.


Every single contest and multi-player game consists of a collection of discrete battles. Each battle is an isolated point in an AI’s portfolio, but there’s no common thread to tie them together. The AI starts out each match with a very limited set of information, and has a short life span in which to learn and adapt. All the real learning and adaptation must be done manually by the coder outside of the arena.

Wouldn’t it be cool if AIs could store information about the matches they’ve played for future reference? Imagine an AI that can recognize a starting board layout and learn from what worked and didn’t work the last time it was in a similar situation. Picture an AI that recognizes when it is pitted against its nemesis and behaves (and even trash talks) appropriately.

Helmet. So, at last we meet for the first time for the last time.


Provide the following information as input at the beginning of a match:

Game engine VersionNumber
My UserId, AgentId, LeagueNum, CurrentRank
Opponent(s) UserId, AgentId, LeagueNum, CurrentRank
Path to DataFile

Then, at the end of the match, provide a “cleanup” opportunity for each AI (if not crashed) to write final information to DataFile. You should probably state a maximum size for DataFile in the game specification, and some kind of consequence if that size is exceeded (i.e. lose the match, and / or discard the modifications and revert to the compliant file.)

Strongly desired

If this is implemented, it would be very beneficial to be able to download (and maybe even upload) the DataFile from the IDE so that you can debug / tweak behavior.

Extra credit

This opens up the possibility of some interesting meta gaming opportunities. For example, perhaps you could let each AI read its DataFile and size up the arena and its opponent(s) and then give it some options about starting parameters. What position do you want to start in? Maybe even character / weapon selection?

  • danBhentschel

I strongly disagree with giving any information about the opponent, as it could allow setups to intentionally throw matches by having people cooperating together, or worse, alternate accounts.

I don’t have an opinion on data storage, though to me it’s a bit redundant as I personally already use stderr for that purpose. Speaking of which, I wouldn’t be against a slightly higher character limit per turn in there… And while we’re on the subject, also increase the limit for code size. :slight_smile:

You’re right, of course. That’s too bad. I (obviously) hadn’t thought about that.

It’s already possible now, if you program your AI to send signals with the moves it makes, but it’s much more challenging, and error-proned. Bummer. Can’t think of any good way around the issue ATM.

  • danBhentschel

Hi there, data storage would be a great improvement and we already had discussions about it internally. I don’t know yet if we will code it or not (actually we have some other priorities but it’s definitively an interesting topic).

But I’m really curious, @reCurse, how do you use the stderr to simulate data storage? Our system isolates each battle so how can you save data from one battle to another?

I just realized my comment about data storage may be misleading so I will rephrase.

Most matches I play in the IDE are saved locally by capturing the stderr and stdout to my hard drive. I can then analyze this data offline and make adjustments in code based on that, which I believe is the best you could make out of a live persistent storage on CG.

So in a sense it’s already possible to do that, just not during a submit. Given the limited time the bot is running while still playing a good game, I don’t believe you could make useful live analysis of matches. But I could be wrong. :slight_smile:

However having stderr available (securely) outside the IDE would be a lifesaver to help debug weird timeouts happening 1 game out of 100.

And please increase the stderr and code size limit a bit if you can. :slight_smile: