[feature-request] AI tooling about liberation-circuit HOT 3 OPEN

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.

from liberation-circuit.

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!

from liberation-circuit.

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…)

from liberation-circuit.