New ideas for AI in games?

[User137]

If you want to be complicated, you can use TCP. But as i said before, you can make applications communicate with eachother in console. Readln(), Writeln() and maybe Flush() are all that are needed for the bots. I assume most pascal based languages can read and write to system console?

The game host application may need some process threading, or other fancy thing i haven't experimented with much. TProcess class on fpc?

And of course the consoles themselves can be hidden from the user, so the communication is invisible.

[Ingemar]

If you want to be complicated, you can use TCP. But as i said before, you can make applications communicate with eachother in console. Readln(), Writeln() and maybe Flush() are all that are needed for the bots. I assume most pascal based languages can read and write to system console?

The game host application may need some process threading, or other fancy thing i haven't experimented with much. TProcess class on fpc?

And of course the consoles themselves can be hidden from the user, so the communication is invisible.

Hm, so maybe bots could just be CLI Pascal programs communicating with the server over a pipe? That sounds farily doable. The server could have a nice 3D view (so it can be recorded to a movie), and it opens all bots using a list of file names, communicating with some predetermined commands.

Each bot probably should be limited in how many commands it can send per second, or at least what actions it can take. There should be some time from a command until you get a result (so if you ask the bot to "look" it takes some time until you "see" something).

Sounds fun.

[pstudio]

Well I don't know if I would call it complicated. It depends on what socket libraries are available. Personally I use Oxygene for Java so that is quite easy, but I haven't used FPC or Delphi in a long time, so I don't know what kind of support they have.
Yes it is possible to use readln and writeln. As I see it, it really depends on what sort of data you want to send and how good a socket library you have available. But I suppose it would be nice debug feature, if a bots console output could be shown during testing. In the end, it depends on who is making the game and what that person prefers. IMO that person would also have to provide a template for each pascal dialect, so that contestants don't have to write the functions for communication with the server, but they only have to focus on writing the ai. Ideally the would only need to implement one method:

procedure TBot.DoMove(FGame: TGameMetrics);
begin
...
SendCommand(...);
end;

[Ingemar]

Well I don't know if I would call it complicated. It depends on what socket libraries are available. Personally I use Oxygene for Java so that is quite easy, but I haven't used FPC or Delphi in a long time, so I don't know what kind of support they have.
Yes it is possible to use readln and writeln. As I see it, it really depends on what sort of data you want to send and how good a socket library you have available. But I suppose it would be nice debug feature, if a bots console output could be shown during testing. In the end, it depends on who is making the game and what that person prefers. IMO that person would also have to provide a template for each pascal dialect, so that contestants don't have to write the functions for communication with the server, but they only have to focus on writing the ai. Ideally the would only need to implement one method:

procedure TBot.DoMove(FGame: TGameMetrics);
begin
...
SendCommand(...);
end;

There are some complications, and you hint a bit about some of them: A common, portable interface has to be written if there isn't one already. And it has to be suitable for the problem.

But the big complications are in setup and performance. I would say that performance is the biggest issue. If my client runs from my computer and connects to a common server, how do we know that the competition is fair? What if I get a different netlag than others? If the game is turn-based that is not quite as much a problem, except if the game gives up on a slow connection and ignores its commands because they are too late.

[Super Vegeta]

Since this would be an AI game, I think speed shouldn't really matter. Instead of using deltaTime or whatever time unit relateable to real life, the game should be using some abstract ticks/cycles as time units, waiting for response from every script before proceeding to the next cycle. Every bot would thus get the same amount of calculations/decisions done in the same amount of time and slowdowns wouldn't matter computation-wise, they would only slow down the rendering (if any).

[pstudio]

There are some complications, and you hint a bit about some of them: A common, portable interface has to be written if there isn't one already. And it has to be suitable for the problem.

But the big complications are in setup and performance. I would say that performance is the biggest issue. If my client runs from my computer and connects to a common server, how do we know that the competition is fair? What if I get a different netlag than others? If the game is turn-based that is not quite as much a problem, except if the game gives up on a slow connection and ignores its commands because they are too late.

Well, I imagine that whatever technique would be used (TCP, write/read ln...) the competition would run locally on a computer, which logs and possibly records the games. That means both server and clients. Ofcourse this add the restriction that all bots must be compilable on the same platform, but I don't know if that really is an issue. How likely is it to use platform dependent code in an AI for such a competition?

Regardless of that, I also imagine, that it would be best to use a turn based game for such a compo. It should make it easier for people to program an ai if they don't have to consider making real-time actions. You can further add a time limit so your bot is only alowed to spend a maximum of lets say 1 second to calculate a move.
You could also give a set of action points each turn which the bot can spend on actions so for instance movement costs 2 points and fire costs 5. If you are given 10 points each turn you can then for example move twice and then shoot.
If you use a turn-based game you would also have to decide whether the turn shift between each player, or if all players make their moves simultaniously each turn.

But it all depends on the game ofcourse and if there even is enough interest in such a competition? Would anyone really bother making a bot game if there is only two/three people who are interested in participating?

[pstudio]

Crazy idea
I was just looking at the Worms clone Hedgewars and noticed that it actually uses Free Pascal. It may be possible to hold an AI contest where we create bots for the game.
Some benefits:We don't need to create a game. It's already made for us and in good working state.
You'll be supporting an open-source game. If your AI is any good it may be inlcuded with the game.

There would be some drawbacks like it is only FPC and may be a tad to advanced for a first AI challenge. Furthermore it may be too easy to make the perfect shot for an AI. At least I've experinced that the already existing AI can make much better shots than I can. But as I wrote before, this was just a crazy idea ignited by the fact that I just discovered the game uses Pascal amongst other languages.

[imcold]

Not crazy at all, I've commited some AI change a few years back. It took some time to grow accustomed to the code, of course, but it's doable.

[User137]

If not just the local country's programming contests i've mentioned earlier, but i also participated in Google's unofficial "Ants" AI contest with pascal, when it was still in beta. Site seems to be up still http://aichallenge.org/
All these contests use console writeln/readln style. Google's Ants is specially different from other ones i did, in that there can be as many as 8 AI's playing in the same game. The game hoster does some automatically simulated games every now and then, and then posts statistics. But i'm not asking anyone to do competition as complicated as that Much less features still can make a good contest.