[feature-request] AI tooling

[229c9cf0]

Hey,

I'd love to throw metaheuristics (genetic algorithms etc.) and machine learning at this but right now that's not really possible. Here's what I think that would require:

• a way to start a match non-interactively from the command line, passing…

  • map settings
  • custom game timeout
  • templates to use per player (ideally a folder of uncompiled templates, otherwise you'd need another way to non-interactively compile them)
  • optionally a log file name (but stdout would work too)

  …which would automatically start a game, run it, then exit

• machine-readable output of the match details & results, i.e. a log file containing

  • game result
  • information on actions, state, events per tick – enough data to
    • (externally) compute/assign scores to all actions taken
    • compute a result score that's more fine-grained than just -1/0/+1 for loss/tie/win, e.g. based on number of processes alive, data available, …
    • infer what was visible to whom (if that's easy to compute from the data, that doesn't need to be included explicitly, otherwise events should be tagged with info on who could observe what)

(When looking at the network of this repository, I noticed that there's a Lua branch by Melvin Zhang. While I haven't yet looked at that in detail, from a brief look at one of the mission folders, it looks like that might greatly simplify this – just pass the path to such a folder via the command line and then Lua can do all the setup stuff. With a bunch of callbacks into Lua, it could then also do the logging, timeouts, and whatever else one might want to do.)

---

If that sounds interesting, I'd be happy to help or even do most of this (as time permits). (But right now, I don't really understand how the code works, so I'd need some help at least initially.)

[melvinzhang]

Procedural generation of ships and having them duke it out sounds awesome. I'd be happy to collaborate on this. I'm also in the process of understanding the code, so for the moment I'm starting with the mission setup part of the program and slowly switching them over to Lua script.

[linleyh]

I don't know anything about Lua, but this sounds like a good idea.

The first part - allowing the game to be started from the command line - shouldn't be too hard. It should be possible to accept command-line input and feed it directly into the custom game setup functions. I don't know anything about accepting or processing command-line input, unfortunately.

The second part - keeping detailed records of the game - might be a bit more complicated. With 60 frames per second and dozens of processes buzzing around, that's a lot of data to keep track of and the game might be complex enough that that kind of quantitative information would be difficult to get anything useful out of. It's an interesting idea, though!

[229c9cf0]

I don't know anything about Lua, but this sounds like a good idea.

I've been using Lua for over 15 years as my main programming language, happy to help with my accumulated knowledge. ^,^

I don't know anything about accepting or processing command-line input, unfortunately.

For command line arguments, that's the main( int argc, char **argv ) part – an array of strings and how many there are. The hardest problem is usually passing the information around (through multiple layers of init code), not parsing it. Here, it looks like passing argc/argv once to init_at_startup is enough – it can then process that after initializing defaults and reading the init file. (Though maybe a different order may be better, so that when the user is asking for --help (or /?), it doesn't even boot allegro and just prints out a list of known options.)

For non-interactive games, one could also read match descriptions from stdin (one line per game), that might save on boot/shutdown times and cut down the number of needed command line options.

The second part - keeping detailed records of the game - might be a bit more complicated. With 60 frames per second and dozens of processes buzzing around […]

When the game is running non-interactively and you only care about the log, it doesn't matter if it's stuttering / lagging. (Unless that affects the game logic, but that would mean it would break on very old / slow computers already. That'd be fixable, though.) If logging is conditional, when disabled the cost should only be a few conditional jumps (that are easy to predict for the CPU because that flag is either constantly on or constantly off). So I don't think this will be a problem.

(Also, I think I read somewhere (manual?) that the user code gets run about 4 times per second per process or something like that? So there's actually only 4 ticks per second that matter to AI (probably), plus events as they occur.)

(Another approach would be to have a completely different mode (maybe even as a separate executable) that doesn't do graphics at all and just writes logs as fast as it can. But that's more work and it may not be necessary…)