Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 34

Thread: New ideas for AI in games?

  1. #21
    Quote Originally Posted by WILL View Post
    I'd love to have a PGD Challenge that is all about AI.
    How about something like this:

    There is a defined arena and set of rules. We need to write a bot that will be fighting in that arena against other bots? AIs could be loaded to the main game via a DLLs. Of course someone would have to prepare the main application - The Arena.

  2. #22
    Quote Originally Posted by wodzu View Post
    How about something like this:

    There is a defined arena and set of rules. We need to write a bot that will be fighting in that arena against other bots? AIs could be loaded to the main game via a DLLs. Of course someone would have to prepare the main application - The Arena.
    The only problem with that approach is cross-platform issues. Could one make a cross-platform solution? The easiest way is to use scripts, but a PGD challenge should ne in Pascal. Pascal Script? (If I could only figure out how to use it.)

  3. #23
    I would probably go with a client server approach using TCP. The main game, the arena, will be the server and will wait for bots to connect as clients. This should allow for all the Pascal dialects to be used on all platforms. You could then add a template for TCP communication for the most popular languages (FPC, Delphi and Oxygene) to make it easier for developers to focus on the ai.

    We talked a bit about this form of competition a while ago in the next PGD Challenge thread. Some of us were interested and some were not. Personally I find ai interesting and would be up for such a competition. If there is enough interest in it, I may try and create a simple ai game this summer which we can use for such a competition.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  4. #24
    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.
    Last edited by User137; 21-03-2013 at 02:18 PM.

  5. #25
    Quote Originally Posted by User137 View Post
    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.

  6. #26
    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:
    Code:
    procedure TBot.DoMove(FGame: TGameMetrics);
    begin
    ...
    SendCommand(...);
    end;
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  7. #27
    Quote Originally Posted by pstudio View Post
    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:
    Code:
    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.

  8. #28
    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).

  9. #29
    Quote Originally Posted by Ingemar View Post
    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?
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  10. #30
    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.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

Page 3 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL