What would you guys think of an AI Competition? Like one where you're provided with a couple sprites and maybe sounds and you would have to design the AI of the characters. It could be in a Rule-O-Matic style where things like group-ai, enemy-ai, and NPC-ai could be punched factored in.

I think such a competition would be loads of fun, who would be interested in one too?

I'd rather have an ai-bot fight. Someone designs a vm with simple commands for attacking and then you code your own ai to make the best attack sequence.

I don't get it, what kind of competition would that be? I mean what would be the purpose and how would the winner be decided?

What would be cool would be something like RARS (Robot Auto Racing Simulation something or whatever). There was a racing simulation framework and the competition was to write AI that would drive a race car around a track the fastest way possible. These AIs were plugged into the framework, each controlling one car and raced against each other. You could have something different, like a shooter or a strategy game or something and the competition would be to write the smartest possible bots that would play this game...

jorram: Mm, that would be a lot of fun too. A bit more complicated though with multiplatform issues.
miran: The purpose and how the winners would be decided would be listed and decided randomly at the start of the competition. Rule-O-Matic style.

That would be cool. I wouldn't contend, but I'm sure I would learn a lot from the entries (assuming they were Open Source).

[url http://nn.cs.utexas.edu/NERO/]

I would like to have a RoboCode contest! It's for Java, it's GPL and we could have all the bots fighting it out at the same time.

Hmm... I would think it is better if you create a program which uses a library interface, and ask programmers to build a library fitting the one used in the program (that is, you need to create the functions the program uses) to do something (in example, a path search function, a hide and seek algorithm, etc).

I agree with RB, we should interface with a message system or something that way each bot would be on the same system but act differently, also the dispatch system would be pretty simple and could run as many bots at a time as needed. Maybe a goal based AI, like robot car that has to push a ball into a goal?

Well, you could do some sort of Client/Server based thing where the server acts as the "World" (maintains physics and such)... the Client can then recieve the sensory inputs, process them, then tell the server the proper "output"...

If what I am saying makes any sense...

That's what I'm suggesting with my message system, you get inputs (the messages), and return the output. For example messages could be MSG_START, MSG_WALL, MSG_HAS_BALL and outputs could be MOVE_FORWARD, MOVE_REVERSE, ROTATE_LEFT, GET_BALL.

I think a maze bot would be cool. Each bot is given a maze, not know until at the time of creation of bots, and they each have so much time to get to the end.

Well RoboCode fulfills every post requirement (except Rick's above) in between my last post and this one.

The network approach is especially nice because it can theoretically support any given programming language, as long as the network interfaces to that language are present. The problem with RoboCode is that it locks you into a single language. (AFAIK) It would be interesting to support any number of given languages...

But now we are quickly approaching fantasy land were we create some huge vision which never gets implemented. That way there won't be an AI contest.

It's better to use an existing framework than to create one specialized. In the later case the end result won't be as good as using an existing framework would have been. Also, when could this competition actually take place if a framework needs to be created first?

RoboCode used Java which is good, then everyone on all platforms can participate. It has some interesting features as well like a real time aspect. If you don't deliver an answer fast enough the bot is disqualified from the tournament. You will also have to rotate your radar to get signals of where the enemy is.

But using any existing framework would be nice in the case of some kind of bot-construction oriented competition.

Or we could create an interface and check who can develop the best "Go" AI by letting them play each other. It would be fun to.

I would like the RoboCode idea a lot except that Allegro, being a C library, lends itself to a large number of C / C++ programmers. Including myself.

As for the networking ideas, networking is a rather advanced programming area in C / C++ in its complexity which could potientialy rule out a lot of people who wanted to participate.

Personaly I like most either the idea of making a simple framework game, possibly through providing a few header files describing the proper interfaces. And then having everyone submit their entry in source format which would then be compiled by the contest manager who could make a movie clip showing the 'battle' or whatever it is.

Either the simple framework or simply providing some sprites and making everyone design the engine and the AI.

Edit:
Hm.. instead of the movie idea, the framework could be designed so that whoever wants to watch could just run a client program that would log into the server and watch.

Yes actually I like this idea much better then a movie.

What's the point with having to log onto the server and watch? This will effectively exclude all dial-up contestants without any real reason.

The fact that RoboCode is Java only doesn't have to be such a big obstacle. If you know your way around C++ you definitely can learn the necessary Java to make a bit in 2 hours.

But there are other existing frameworks as well. Ones that will enable you to could code in C/C++.

If we would for example compete in the game Go (for which a good AI solution has yet to be discovered) we could just make a controller class who controls the possible movements and scoring.

Then each and every contestant could code an AI class which makes a move based on the current state of the board. When everyone is finished we could just put all the contestant classes in a Vector (or other data structure) and let them compete against each other. Very simple way to compete but enormously challenging contest.

Something like what Miran described, or any of the tank/robot combat AI challenges out there, maybe.
Something like the OP, no.

It would be useful for me to see the source code, i'm absolutly rubbish at AI. So yeah, I think it would be a good idea anyway

I'd be in. I love writing AIs

Will it involve rotating things that are controlled by an AI? That would be extra useful

I don't think that there will be a competition.

Going with an existing framework is a must, otherwise there most likely won't be any competition as there are loads of work creating such a framework.

I think battle bots would be cool. Have a pool of abilities:

Basic Attacks
Counter Attacks
Special Moves
Defenses
etc...

Each player gets to choose a few of each and create some AI for their bot using the abilities they selected. Like if attacking bot uses frost bolt, then I know my fire spells will cause more dmg to it so use them from now on. Stuff like that would be fun. Could setup a tournament with that.

It could be just a simple framework though...

Well create one which is easy to interface with and interesting and I'm in.

Man, that was part of my compilers coursework (and coincidentaly, the something was "robot wars" , which inspired me to choose the topic for my thesis).

PS.: One week before 25th all the tickets to Buenos Aires were already sold

A few years ago I went in a comp at C++ Home in which a game was provided, and you had to program a player for it. I worked out the optimum strategy for playing against the sample opponent, but didn't realise that it wouldn't be optimum against every opponent.

I think a better method would be a simple lib, where you loop getting messages + processing them. You use that to compile your AI to a dll / shared object, which is loaded when it is your AI's turn to go.

Here is what I propose, a simple message system of inputs and outputs like any robot. It would be simple like move forward, rotate x degrees left, etc. Inputs would be that a sensor detects a wall or that the robot reached the goal. The actual board would be a simple maze with a goal, the robot would have somewhere like 4 sensors, 3 front, 1 rear, and circular in shape, it could simply be rendered as a colored circle with a line showing what direction it is pointed in. A simple game event would be something like this:

Input:
None
Output:
Move forward
... repeats for a while
Input:
Front Sensor
Output:
Turn Left 45 degrees
Input:
None
Output:
Move forward

Of course it will be storing internally where it has been so it doesn't run back over a place it hasn't been.

Then again a robot like this would never be able to solve a maze because it woudn't know where things branch off, but if you are smart enough designing it you could have it bounce off the walls as it goes in order to discover those branching walls.

So basically, virtual lego mindstorms?

Ok maybe that's too simple, but that's the basic inputs/outputs. Maybe I'm thinkign too robotic AI and not game AI, how about giving the players each goliaths and have them battle it out?

Hm, this is a valid point. I suppose both a video recording of the event and allowing people to log in and watch could solve this problem.

That and designing the engine to use low bandwidth.

Ok, so how many people would be interested to participate after a framework has been designed?

Fyi, the framework would include functionality to find nearest players / allies / enemies as well as iterating through all visible players and possibly visible powerups if they're going to be in the contest, a simple tilemap engine and interface, some form of direction and speed interface as well as contest specific weapons / actions. So it would leave pretty much only AI code left to do along with maybe a few sin/cos to discover which direction to move in, fire, and understand where the other players are located.

That is unless enough people who are participating would like the framework to be different somehow.

I bet you 5SEK that it will never be finished with the features you proposed.

It's based on experience with other complex ideas presented as "It's just this, and this, and this" but I hope that I am wrong as a competition would be very fun.

The framework I think would be insanely simple with a message system, all the base system has to do is dispatch a few simple messages, the rest is done by the AI, a simple linked list and a function pointer is all you need.

How about a battle tank game? Like the old atari classic, can't remember the name. You have a simple room with some walls, the bots start out on opposite corners and have to kill one another, we could give them 10 hit points or so and maybe even powerups randomly placed. The inputs would then be MSG_TARTET_IN_SIGHT and MSG_POWERUP_IN_SIGHT. There woudl be a small 30 degree "vision" area in front of each bot extending for some pixels.

I tried that A.I. stuff a few years ago, but it got way too expensive.
Everytime the computer failed to think, it ceased to exist....

Heh we could have the winning bot yell out "I did not murder him!" at the end

I like the tank idea, I'd even be interested in helping to create the framework.

My thoughts are, that perhaps we should use LUA as the language in which all the bots would be written. The program would expose a few very simple commands to the script, and call a single MsgIn() function for input.

My second thought would be not to have a server. Rather, for each "contest" all AIs would be packaged along with a randomnlly generated seed. If everything is kept determinsic or based on that seed, then that is all that would be needed for everybody to run/view the simulation on there computer.

It seems to me that would be simplest/cross-platform method of doing things.

Winston I ran over the same idea of seeds myself, and maybe it is a fesible idea. It would certainly cut down on the development time and effort of the framework.

I thought the networked idea would be cool and fun, with a little chat room embedded aswell. I suppose the question is how much effort / time do we want to put into the framework.

Another problem with the seeding is making sure that people aren't seeding things themselves. And it feels like theres something I'm not seeing that will mess it up.. But maybe there isn't.

The LUA idea sounds interesting. I think it might discourage people from joining the competition though due to having to learn a new language. Also I'm not familar with LUA but is it as powerfull as C / C++? How hard is it to make an interface from C to LUA? Would you have to reconstructed linked lists? What about data type incompatibilities?

It just seems like a bit much to worry about, but its an idea.

Oh and Winston, thanks for offering , we'll have to get together to design this thing.

Edit: Grammer fix.

Oh I see you want like a process of elimination? Where two bots go at it and the winner moves on to the next round with a different bot? Final bot left is the winner? It does bring up an interresting idea on seeding though as I'm sure some randomness will be involved, as long as srand is not used it could be ok? That or you could run the competition real time and record every event from each bot and play back the replays that way, then it doesn't matter.

My thought: Design for the possiblity of later adding it, but at least for the first version, leave it at a local level.

Well, people can put any seed they feel like into it. But, there would only be one official seed, and probably you wouldn't be able to get people's programs to try against until a certain time. So as to prevent you from learning too much about the other bots and training to kill them specifically.

That is a good point. I'm inclined to say that people really ought to learn LUA. But, do we want to trust just any C/C++ code running on our computers? Especially those of us with "inferior" operating systems?

I know that some people essentially just write low-level performance criticla function in C/C++ and then create the rest of their game in LUA. So, I believe while slower then C its probably just as capable.

Its the Zen of programing... Just about.

int FunctionCalledFrom(lua_State * l)
{
        string s = lua_tostring(l,-1);
        lua_pop(l,1);
        int a = lua_tonumber(l,-1);
        lua_pop(l,1)

       // do funky operations
   
       lua_pushstring("Allright!");
       lua_pushnumber(42);
       return NumberOfArgumentsReturned;
}

The only thing easier would be if Lua could call the C function directly. Some extra libs will even automate that process. (probably too complex for our purposes)

I've never actually needed to pass a list into or back from Lua (usually I do a lot of simple types, if the script wants to store them it can). Lemme check the docs...

lua_newtable(L);
foreach in list
{
     lua_pushnumber(index);
     lua_pushstring(value);
     lua_settable(L,-3);
}

Do you want some alternate contact information?

[edit]

Ok, you were thinking it seems more along the lines of a omniscient tank. I was thinking more along the lines of a limited sensory input. So, in my theory, you wouldn't be just able to point and fire at anything, you'd have to scan and locate it first.

Sure, which would you prefer. I have aim, icq, irc or phone. Email too but its a bit too slow.

Edit:

That was supposed to be "But maybe there isn't."

Hm this is a good idea. The system I had in mind was some form of dividing into teams and possibly dividing the winning teams again untill there was a winner. But your idea sounds more fair.

I'm wetimer on AIM

Actually the whole tank idea is what RoboCode is, except implemented much better than you ever will be able to do in time.

RoboCode started as a project at the R&D department of IBM and after a couple of years (this february) went to be GPL.

Why not use it instead? If we are still going to have to learn another language why not go with Java instead of LUA?

I think we're going to stick with C / C++ as they are the native languages for Allegro.

Just as LUA? Anyway good luck and start a thread about the competition when you are done with the framework.

With everyone's college time schedules and personal lives I don't see how this would become a successful competition. It is a great idea but unfortuantely I am busy with my college classes so I wouldn't be able to partake in anything right now. I even had to back out of joining SpeedHack '05 this year:(. If you get the rules together and this becomes an annual thing then maybe I'll do it otherwise I won't have time for it.

javascript >>>>>> LUA.

In other words, LUA has got to be one of the worst scripting languages out there. Popular != good.

Marcello

p.s. jsgen makes c++<->js interaction easier than pouring a glass of water

p.p.s. if the thing were written in java, you could link in rhino for javascript, and the java<->js communication is automatic via reflection. even easier.

p.p.p.s. in fact that is an awesome idea, something like this as a java applet would be perfect. people could upload/download their codes, edit/run in realtime against other peoples' without downloading installing anything.

p.p.p.p.s. so awesome I'd even be tempted to do it if I didn't have enough projects as it were. would be slick to do in processing with 3d.

Big Blue Mean Man say mean things about my favorite scripting language...

I like Lua.... Lua is like Ice Cream in the middle of August. Javascript is like sunglasses which make the world like dark and dreary...

At any rate, the current plan is to provide a C interface, but perhaps to allow some scripting language to be allowed in as well. Probably LUA, and if Blue Mean Face is nice to us we'll think about javascript, my precious.

I still like the server appraoch... Mainly because locking people into a single language sucks... sucks bad. Yes, it would introduce a large number of technicalities that would be hard to handle. And yes, it would mean "saved games" would be much harder to create (unless some sort of Client/Server based Random Seed Generator was used. Hmmm.....). But it would prevent "language lockdown" which is one of the most annoying things about almost all of these AI systems currently implemented.

As for "it would make it more complicated than necessary," I'd agree, but only to some extent. The languages that are used more often (read: C/C++/Java) would have more people using them, and hence would have more of a user base that might be able to contribute a "language specific" iterface for the given library. So, for example, a C++ interface could wrap all the necessary inputs/outputs into classes that automatically handle the networking stuff behind the scenes. Java could behave similiarly, as well as python, ruby, even PHP.

The coolness factor about this approach is that it allows people to even develop "interactive bots" that can interface with a GUI displaying stats for debugging, etc. or even allow human players to interact with the "bot world" to test their bots using their own inputs. Of course, this means the human would have to design a usable interface and make some sense of the inputs... but that could be fun all by itself.

Of course, implementing this would be a pain in the royal donkey, but it would be cool none-the-less. Especially if one could actually design the specifications of the bots or something (for example, number of inputs, input types, number of outputs, output types, etc.)...

Then again, I'm getting a little bit carried away

The problem with making this too extravagent is just that. Presently, I'd say stick with a single program which runs all the AIs concurrently, with a C++ and optionally a C interface.

It would be better to start small. A simple virtual machine with few opcodes (walk, punch, run) and a world map implemented as a bidimensional matrix should be enough. The bots sould be written as lines of opcodes and we would be able to see the result. If I have some time tomorrow night I could try to implement a demo.

If you want everybody to be in, let the first edition use C, and give people some time to learn LUA for the next time.

http://gameprog.it/hosted/guntactyx/

It's a fscking tough game though. Certainly if you plan to defeat roger and Krobot. My bot is i-bot, which was the best until roger and Krobot entered the compo.</shameless plug>

It's funny, but I cannot help myself thinking that my compiler teacher (and thesis tutor) would be saying "Try Haskell people!" he said it was quite simple to do it that way...

My idea for a good framework is to make it extensible. Write it in C++, with a basic loop. You have a simple TCP server embedded for basic control. You have a php page on the net someplace, where people upload their C++ source code (they use a simple library and use a class inheriting from a basic module). Server compiles it + tells the arena via TCP about the new module. The module gets loaded and added to the list of loaded AI modules. Then when you want to start the competition, the arena makes up a chart. Each bot goes to a random place, fighting another bot. Then they keep fighting and it keeps getting narrowed down, until you have one bot left.. the champion. The arena updates the chart of who is where whenever a match is finished, you could run multiple matches at once if you wanted. People can go to another php page, chose the match, and get the current rendering of what is going on (php talks to the arena via tcp for that too).

For my method, you wouldn't even need a VM. The main loop updates each sub-arena at whatever the update interval is. It would be turn based, the starting AI is randomly chosen (weighted by wins/losses). For each tick, the next ai in the sub arena gets a turn. You could have it narrow them down, 2 ai's per match, or throw them all in one arena and have last AI standing. You could even do capture the flag and other multiplayerish games. The possibilities are endless.

I may have to start implementing my idea just to see what I can come up with for code. It definately sounds cool. And, time barring, you could make a client which uses UDP communications so you can have a realtime view of the arenas (or zoom in and see one whole arena and see whats going on). Built in chatting and stats display would be nice for it too. Tie it all to a mysql database, and you can make a nice stats webpage.

Baf: The web display is near whats been planned for the framework. There is going to be a round-robin style tournament where once your beat, you're out. It would be awesome if we could have a graphical display of how the competition is going and where everyone is, updated by the server in real time. Something like this (but done in html / css / an image):

It would be awesome if you were interested in designing a system to handle this. If you are I could send your way the specifics of how it would all need to work (namely protocol stuff and how the server would submit the information).

Well, I'd be glad to have BAF write up a system where users can sign up and uplaod their single source files, whcih are compiled into modules, and automatically placed in a directory. The server can look at that directory and load all modules there. If there's a compilation error, it should be spit into the server somehow or something.

Steve Terry, Winston Ewert are on to something good.

Dustin Dettmer and BAF are complicating things beyond what they need to be.

LUA is a great choice, if you want TCP based remote clients, you don't need another line of code in your engine, you can simply write a LUA script which connects to an arbitary process via TCP.

However, there is no need to require the things to be written for a TCP framework, the competition should be a pure focus of AI, not who can write the fastest netcode...

LUA is simple to use with C++, simple to write code in, extreemly extensible, and extreemly powerful, even including OOP elements, on the lua site there is a free book you can browse to, and learn LUA, it's freakin awesome.

Not relevant to LUA, since popularity is about the only thing it doesn't have... But this is a good explination of why python isn't good.

No need, use LUA.

I'd love to be a part of the compo if it doesn't end up sucking/dying before the frame work's finished. It'd be neat to see fighting tanks on a randomly built tile map, or maybe a standard map that everyone knows about... I like Steeve Terrys message loop system, but it should be more powerful than you'd find in a robot, more like a game AI's interface. It should have as an input, anything it would be able to see on the screen/mini map if it were played by a player, and as an output a virtual joystick. IMHO. -- Seems like it would be fairly simple to build really...

Also it would be best to simply store the data, instead of random seed, and programs, IE, store the output messages for each robot, and anything that was originally decided at random.

edit:
Also it would be great if the "Tanks" was basically Atari's "Combat" or similar... blarg.

I think I may just spawn off my own rendition, using a message system, I'm currently working on a combat-like engine.

ST: Not that the engine/etc should be any more than trivial, but since I like your idea feel free to PM me if you want any help. Also what exactly is your rendition going to impliment again for the AI? LUA? C++ pluggable files? DLLs/Libraries?

I think lua files should be "easy enough" for the AI (either that or something like SmallC or Python). A web interface could be provided to upload new bots, create new bots, schedule tournaments, view "debugging information" or "replays" of your bot matches, etc.

I say we should go for it!

I guess I don't understand. Why is the web interface required again? We can do all of those things without one, we just need someone to be in charge, which we would need anyway if we were to have a web interface.

Debugging information for what? If you release your bot for the tournament and it bugs out, it's too late to fix. You just lost, possibly anyway.

Well, the web interface could be a "central tourney" center. It would provide automated testing of your bot against all other bots on file, as well as score information relating to various "maps", replays of these matches (the random number seed), and a global ranking of all bots. The debug facilty is mainly if your program for some reason "segfaults" or something similar and needs to be fixed. True, it may be too late, but some times these errors creep up without notice.

Maybe I'm having a miscommunication. I was thinking of having a "continous" competition that is held online (like a top100 bots list, top10 AI programmer list, etc.) with the occasional specialized tournament (with perhaps completely random map sets, new rules, new features to be tested, maybe a 24hr opensource bot AI contest or something similar).

The web interface is not necessarily required. It would, however, allow for a much more detailed medium of collaboration. You could accomplish all of these things without a webserver as well; however, it would seem to be much easier to achieve this first with a webserver, and second with a standalone "botnet" client or something.

But, once again, I'm probably overcomplicated again

I personally hate lua. If i were to delve into writing AI for a compo, it would be learning good AI in C/C++, so i could actually use it.

We're currently working on it (CGames, Winston, DDustin, and me). The web interface is one where you upload your AI module, it compiles it, tells you any errors, you can test it out, track your stats, see the current competition chart and standings, and admins can take care of administration / disqualifying cheaters, etc.

I think my interface will be nothing more elaborate than something like the Allegor GUI API of message passing and returns. I don't think it has to be any more complex than that and everyone seems familiar enough with that, all you need is one ai_proc callback for each bot. If it turns out to be a decent interface then I'll probably make it .dll or .so. Everyone can compile a bot.

Carrus85, if you ever finish let us know.

Baf, why do you hate LUA? Have you user tried using it?

ST: That sounds freakin' awesome.

I had a simple map going a couple of days ago but found some decent artwork to make it at least look cool as well. The tiles are 24x24 with little 24x24 tanks, I have 4 dedicated tiles (red, blue, yellow, and orange) for player placement and a simple... very simple level editor. The colored tiles give the starting places for the tanks, and I will take a grayscale tank image and convert it into the color of the tile. Orientation will be determined by what quadrant the tile is placed. The map is also 25x19 tiles and runs at 640x480 res. That much of it is at least in place. I need to then get collision detection going and the message event system I can steal off of another project I was working on.

Something I was thinking of: should I allow independent turret movement?

Michael - yes, in fact, I have. it was worthless then too. I personally would like a scripting language that is like C/C++, so i can make parts of my programs script for debugging and such the cmopile the static stuff in after its going.

As far as I'm concerned, most of the stuff SteveT described is irrelevant for an AI competition. Neat, but still irrelevant. I've drafted an interface for AIs as follows:

Background Information:
The world is defined as a grid of control points, which are spaced evenly apart. Every control point is an integer value which describes the ground level (height) at that point. Everything that exists in the world is called an Obstacle. Obstacles are all rectangular, and each have a hint descirbing what they are. One hint is 'static', which means that the obstacle will never change, move, or affect gameplay (other than getting in the way of bullets and tanks). Another is 'tank', which means that this obstacle moves, shoots at you, and should probably be shot at.

The Vehicle interface provides low level functions for controling the basic movements of the vehicle. The vehicle has two treads, a camera, and a barrel. Each of these four parts can be controlled independent of the others, but the as the chasis of the tank rotate, so too do the barrel and camera, at the same rate. This means that they have to spin in the opposite direction of the chasis to stay pointing the same direction. There is a facility to control the power to one or both of the treads, as well as spinning the camera and barrel of the vehicle.

AI Interface:
The AI receives messages from the server, and makes changes to the state of its vehicle. The AI interface automatically stores the parts of the world which it has seen, so an AI can reflect back upon this at will. The interface also maintains a list of the static obstacles which it has seen, as well as a seperate list of other obstacles. Entries in the latter expire automatically, depending on the nature of the obstacle (example: a tank won't stay long in this list, as it is assumed to be moving).

The AI interface also provides a higher-level abstraction over the vehicle class. It provides facilities to pilot the vehicle more simply, such as the ability to face a certain obstacle (or an angle relative to that obstacle), and automatically spin the camera or barrel to a specific obstacle and track it.

Technical information:
AIs will be run in each their own process. Pipes will be used to communicate between the server and each AI. AIs will be forcibly quit if they attempt to access data which they are not privy to (they will crash if they try to read/write data that isn't their vehicle's).

I think so, It wasn't in the original Combat, but makes for a much more capable tank, on the other hand, will it make programming the AI easier? since this is all about, who can make the best tank killer, maybe it should be true to the original combat? If you decide to impliment it, only allow the tank to know the direction the cannon is facing, and Give it the ability to rotate left/right, instead of letting it simply have an X, Y to auto aim at...

Have you tried the "::" operator in LUA? Or accessing the variable "this"? LUA can be object orientied if you prefer that sort of thing.

16 - Object-Oriented Programming (16.1 - 16.5 focus on OOP in LUA)

DDustin asked me to explain what I meant by having a rotating camera and if I was talking about an FPS tank game.

The camera spins independantly from the rest of the tank, spins quickly, and doesn't have any restrictions on the number of times it spins. The barrel spins independantly from the rest of the tank, spins slowly, and cannot rotate more than 180 degrees in either direction.

From the tanks point of view, the game is first person. This should be obvious. From the user's point of view, it doesn't matter. As far as I'm concerned, it can be text. I'm only interested in extracting the process the AIs go through and evaluating it.

The Vehicle interface provides this sort of control, however the AI interface will have the added ability to automatically aim at a given point or obstacle. This is because that it isn't the job of the AI programmer to do any trigonometric maths to decide where to put the tank nozzle. It's the job of the AI programmer to decide when to fire the barrel, and how to position the tank most wisely.

I see what you are saying about the AI Cgames, but what point does it come where the AI has too much information about its world, you don't just want it to run right over to the opponent and blast it. I think I'll work on some basics at first, like having the AI be able to set velocity and turret/track angle and sorta make it around the arena. I'll add higher level functionality if I see it fit later. I think you should give the AI "control" over the vehicle like what you are saying rather than simply telling it to roll forward, you would be able to set the velocity within some bounds as well as turret angle, the underlying system would then accellerate to that velocity or rotate to the angle at some constant. It would make for more lifelike tanks anyway

I don't think you understood what I said.

The AI only knows what the map looks like if it has seen that map.

It also keeps track of rocks it has seen, and other tanks that it has seen, but it knows that the tanks move and won't assume they are in the place it has last seen them.

Certainly. I proposed an even higher-level interface, however. I'm going from the point of view of: if this were an actual engineering project, what systems would the AI handle, and which would be written in other subsystems?

Ok so a fog of war type system, I know what you are saying and I was thinking I could leave that up to the programmer but I suppose it shouldn't be too hard to do really. Just a simple array mimicing the actual arena that can be marked with 0 for ground, 1 for wall, and 2 for tank sighting. Hopefully I'll have time enough tonight to begin working on the AI system or at least get it so that you can drive a tank around via the keyboard to see if you like the idea.

ST: he's being sillier than that, he wants the tank to ONLY be able the query the environment right infront of it, and to make it look around and remember such things on it's own!

It makes sense from an engineering/robotic standpoint, and sounds great, but we're not trying to emulate a RL-robot competition, we're trying to have a game programming AI competition.

Right but that makes it harder on the AI Programmer since now you tell it to aim at a point, and without doing trigonometry it doesn't know if the cannon is aimed at the point or not yet. Since the cannon shouldn't snap to where you aim it, but rotate slowly to that point... It would be better IMHO to let the AI handle this. Besides if the AI is going to be smart enough to dodge bullets that are comming from a long way off it's going to need to do simple things in trig.

And aiming the barrel is the simplest thing you could do, I think all you really need to do is call an ATAN2 and find out if you need to move it left or right, and then do so, if it's on that point them don't move it and it's ok to shoot.

(Dodging bullets is harder, but not by too much, simply query the environment for any bullet objects within a certain distance, see if they plan on crossing your path, turn ~90% perpendicular to the bullets velocity, and move forward or backward until it's no longer going to cross your path.)

IMHO, the tank should be able to query the entire map for static objects, and then query the map within a certain distance of it's self to see what objects are nearby that are not static, such as tanks, bullets, power ups, etc. Because this is supposed to be emulating a video game player, not an MIT robot.

Personally I think writing different AI bots to battle it out in a tactical board game would be much more fun!

Something like Chaos, Fire Emblem or X-Com for example!

Nah, board games are too easy to write AIs for, you can let the thing think for an hour if you really need it to... When it has to decide what it needs to do in a fraction of a fraction of a fraction of a millisecond to keep the game speed up, and still kick everyone's donkey -- well that's different

Your logic is flawed. Requiring speed eliminates offhand many possible solutions, thus greatly reducing both the strategy space for your opponents (meaning you have less potential strategies to worry about) and the strategy space for yourself (less ideas to seriously consider). Often problems that are interesting and important will be ignored because they are impossible to solve within the time limit. Rough heuristics & simple, hand-tuned state machines become The Only Way. So a millisecond AI is probably going to be very uninteresting, very specific to the nuances of the one problem it was tweaked to solve.

Of course, if the board game is too simple, and the time allowed too great, you get complete solutions to the game, which is also uninteresting. But with something with decent complexity and a reasonable time limit for that complexity (obviously this is very game-dependent, but it's probably going to be on the order of ten seconds, not a tenth of a millisecond), the AI solutions can be quite interesting.

I never thought of it like that.

Here is an arena and the tanks I made, does that look good enough for an AI competition? The turret and tracks rotate independently so you can drive and aim separately. As far as the underlying AI goes underneath you will have access to turret angle, track angle, and speed. What should the AI know about its external environment though?

Well, it depends. Do you want the AI to be complicated (some form of raytracing to determine distance to nearest object in a given direction, only allowing queries in the viewable area), or simple (tank given map as input, and all it has to determine where to go and when to shoot).

I guess it is a question of how complicated you want to make it...

Yes, it can only see objects right in front of it, and no, it does not remember this on its own, the AI interface provides this "memory".

I would never write a cheating AI, if that's what you're suggesting. And okay, but I have different ideas about this.

The Vehicle interface provides this sort of control, however the AI interface will have the added ability to automatically aim at a given point or obstacle.

And of course every high-level AI function is going to produce a message saying that it has been completed.

Right. So why not make the AI interface do this? It will simplify the actual AI code.

This seems novel. I think I will make it optional to have an already mapped world at the start of a match.

I agree and I disagree. It should emulate a video game player, thus I should be able to read all objects. Still if you emulate a video game player we got to have a real time element which throws out a contestant which uses up to much time.

Excellent idea!

Yes, this has been known... Tanks run in real time...

What does that have to do with what I posted?

Actually I have a sense of agreement/disagreement with what you said! so ha! Yes Tanks run in real time, and while it's feasable to say "disqualify that ai cause its killing the frame rate!" You could also consider that since it's all AIs versus all AIs which have no sense of time other than frames, and are indifferent to the amount of time that passes between a given frame and the next that maybe having slow AIs should be allowed?

... Ironic that the most given, simpliest of given things can spawn a debate.

I've already made my opinion made, awesome to see the area/tanks. Actually in a one screen environment, it should be able to query the entire battle field without any kind of sight limitations.

it's not a matter of complicated or simple, it's what kind of AI is this? If someone was building an "MIT tank-robot" and they had the physical ability to send in data based on the ENTIRE area, they would freaking use it. Here in a video game, it's no different, we have the ability to send the environment to the robot, and it's actually EASIER to send the whole environment than just a part. This is how the best video game AIs freaking work!

Of course not, and having information is not cheating. The player is given just as much information through the screen! And to completely eliminate cheating, an AI as I said earlier should only have the ouput of a virtual controller (or a similar interface to what the user is manipulating through the controller, for instance in a mouse based game, you probably wouldn't give the AI a mouse, and a fake interface, but just the code to use that interface (Think an RTS game), while in an action game (mario bros style?), the player has a jump button, the AI should probably only have a jump button instead of being given ability to call jump directly, what if the AI calls jump twice and you're code doesn't stop that from happening? the easiest way is to impliment virtual controllers, and just set the AI's jump button = pressed, and then after the AI function returns, you read his virtual controller's state, and act on it as if it were a human player. -- This prevents cheating.)

That's all the AI needs, an ability to query the interface (via function calls?) an an ability to manipulate a virtual controller.

Why bother with a message queing system and automatic aiming when they're really a part of the AI? If you're really going to give auto aiming, I suggest you let them pick an X, Y point in the physical game world, and let the cannon move towards that point until it's aiming at that point, and likewise, a variable (or a function that can be called) to see if such and such an angle, from such and such a position, is aiming at such and such a position.

if (aiming_at(this.x, this.y, this.cannon_angle, that.x, that.y))
{
  //etc...
}

It offers so much more power to the AI programmer than a crappy message queue based system.

edit: obviously, the AI should be able to set, this.cannon_desired_angle, or this.cannon_aim_at_x/aim_at_y (or something named more intelligently) to any value, and the auto aim should kick in, or if set to -1, should kick off and allow manual control through a virtual controller. (or possibly an AutoAim variable that can hold the modes: off, mode 1 (desired_angle), mode 2 (desired coord).

Also if done intelligently, the metrics of these functions could be duplicated (and useful) for actual tank steering... in the end though, how do you want your tank to behave? Do you want to be forced to use these functions, or could simply writing similar style functions on your own as an AI programmer and dealing with a pure virtual controller work better? It's all preference.

Because if every AI is going to implement them, we may as well do the work for the contestants. This isn't designed to make the competition any easier, but to make the focus more on the actions of the tank itself rather than the actions of the parts of the tank.

This is what I am implementing.

That is exactly my logic in allowing both the direct Vehicle access, and the high-level AI functions.

er.. that was funny. I was going to say that I felt the idea below would be easier on competitors, but its also by you! Imagine that..

Well anyway my points and counter points are as follows. The second quoted suggestion of providing a 'move cannon left' and 'move cannon right' interface is (I believe) easier on the competitor then setting a desired angle and checking if it has been reached yet. The only issue with using this system is how to handle the acceleration of the turret turning. If we incorporate acceleration of the turning mechanism, then it will be very hard for the competitor to say how much they want to move right or left.

Should they provide what amount to accelerate by? This makes it rather tedious to try and stop exactly on the spot that points the correct direction. This tediousness is enough I believe to disqualify this idea.

Should they simply provide an amount to move the cannon by? This means there can be no turret acceleration (unless incorporated by competitor), but simplifies everything a good amount.

So what the issue boils down to is this. Do we want to incorporate turret acceleration? If so the target direction and finished flag system would probably be most suitable. If not, then added ease of use could be provided via 'move left' and 'move right'. The issue of whether or not the amount to move left/right should be variable I think can be decided after the move left/right option is picked.

I think that whatever system is adapted for the turret could also probably be used for tank direction. Unless enough people feel that realistic control of moving each side at variable speeds is prefered.

Important, read below and respond

Lets do an informal vote, who prefers that turrets accelerate over simplicity of API?

I liked my original post better, also, but it seems that a compromise must be made, and so I offered one.

I'm not sure I understand. Why does the speed at which the turret moves need to change?

The question is how realistic do you want turret turning. In real life if you push on a turret to move it, it starts moving slowly and gains speed the more you push it. As it does if a motor turns it. Theres also a terminal velocity for turning which isn't too high.

The question is should the turret simply move at the same speed whenever its requested to move left/right or should it speed up and slow down like things do when you push them in real life.

I don't think it should be as complicated as all that. It's a game, who will care?

If you do decide to impliment such a thing, it should be coded into the game, and not dependant on the AI.

So Michael's against acceleration, any other votes?

Two different ideas seem to be presented here.

You earlier posted the AI would have control over how much to rotate the turret by thus letting the AI simulate turret acceleration. And now you're talking about general turret acceleration...

If ST does for some silly reason decide to impliment turret acceleration, I sure hope he has enough sense to see that this is something that should be controlled by the game engine and not something that the AI can choose to work with based on its own whim.

Ie, you provide a mechanism for the AI to turn the turret, X degrees left or right. If the AI wants to turn faster it can simply put in a bigger X allowing it to cheat! when the desired effect was to actually simulate real turret rotation... Also you can't rule out accidental cheats (cheating caused by bugs in the AI, etc) also the way you described realistic cannon movement could be implimented different ways by different AI programmers, this seems silly altogether, if it gets implimented, it needs to be at the engine level and transparent to the AI coder. They should not have to impliment their own "realistic cannon movment" code.

Hm I think you misinterpreted what I had laid out. I meant for it to be assumed that anti-cheating would be implemented along side whichever design was more popular. Anti-cheating would include bounds on how far the turret can accelerate and / or how far it can move in one cycle.

The specific details on non-cheatable code were left out for clarity.

Right, but the whole point is that you want it to act like an actual tank turret, and regardless of if you impliment bounds on how far they can move it, most people will just abuse it and move at whatever speed they feel like within those bounds. If you want it to start out slow, get faster, and then snap to a stop like it should because you feel that it should feel realistic, then you have to enforce this.

edit: My point is that if you let the AI coder do whatever they want with this, it's not going to have to original realistic effect you envisioned, but just a silly API that everyone abuses. If you want it to do what you said, it needs to be embedded in the engine.

edit 2:Example: The max bound is 5 allegro degrees per frame. (there are 256 allegro degrees in a circle, this is discussed in "Sin and Cos, your friends", or whatever that article was called.)

What if I always rotate by 5 allegro degrees, there are no rules that say that this can't be done, so it's ok. It won't speed up or slow down like you wanted it too. Hence making the whole idea of having that in there pointless... Everyone would always rotate by 5 degrees. (expect in the rare chances that another amount would be prefered.)

On the other hand, if you enforced such a thing in the engine, everyone's cannons would move the same, accelerate the same, etc, which is fair, and is the ideal way to impliment this sort of thing...

edit: And realistically, an AI programmer shouldn't really care about such a thing, so if implimented it makes thousands upon thousands of times more sense to do it in the engine rather than let each AI programmer rotate the turret up to 5 degrees either direction to enforce realistic turning movement. And either way it's implimented, when I write my AI for the compo I will NOT want to be concerned about such things... (in otherwords, I vote not only against it, but if it is implimented, that it not be accessable through the API but just happen in the engine. -- I just think that the whole idea is silly.)

An AI Competition That Might Actually Come To Pass:

• Turn based (timelimit for pondering)

• Full map info available - possibly "fog of war"

• Clearly defined set of things that each AI may do each turn (maybe through some kind of Action Points?)

• All AI's based on the same superclass, for easy integration into a "Battle Zone" program

My 0.2 €

Well it sounds like STs program is almost ready.

ST is it too late to request a feature or two? These features would greatly help the developers, they just came to me.

1.) It would be awesome to have an output console, for debugging of our AIs. Maybe something that can be turned on or off, and then within the AI we just call a function, pass a string in, and it goes on to the screen... It would be a very nice feature for the developers to have.

2.) Also what would be nice is the ability to have a human opponent in the same area to battle with our custom built AI so that we can see if our AI is worth beans or not before declaring it finished.

Mine has just the artwork and no collision detection yet, I've given lots of thought about how the AI should work but I don't want to commit to any one way until I know the way I choose will work and be right. Per request I'm uploading my sources and tiles, tanks move with up/down/left/right and Z/X. My next step is actually implementing collision detection against the tiles, I'm probably in need of a line circle collision algorithm and I need some way to store the lines with the tiles, the tiles aren't simply passable/non passable so I can't just flag a 1 or 0 for each. If you look at the tiles you'll see my predicament.

Michael, A console would be great, it doesn't have to be complicated but yes just a simple string output per AI that would go to a console box, almost like a chat, should it be shared among all AI's or each have it's own dedicated box? Shared makes it much much easier.

Also about the allegro degree thing... if you notice in my example if you rotate away and then back to 0 there is a slight but noticable loss of precision, you move nearly forward again but not quite, you still have a small offset every few pixels and I can't ever seem to get it back to 0 degrees again. FYI in the source I was using float but was forced to use fixed for the track angle, that's why turret is still float, but I'm thinking fixed will be ok for all of it if we can figure a way around the precision issue.

Before we can even get started on AI we need to develop the fog of war code, collision detection, sight code, console code etc. Once those are working then the AI elements can come into play as far as what is fed in and what is fed out, really it shouldn't be difficult at all once we know the other elements work.

Anyway we have the map and tiles, it shouldn't be too hard to get the other elements going.

Yeah ... I've been lazy ... what else is new

[edit]
Also the map editor it is really really simple, L for load and S for save, it only saves one file at the moment (arena.map) so be sure to use L before S otherwise you wipe it out. Left click to place the tile, up and down to select a different one. The tiles with the colored diamons are the player starting point, so far the game will only support 4 players max at a time.
[/edit]

[edit2]
Meh giving some more thought we could split the tiles up by 4ths then lines wouldn't be needed, it would just be a smaller grid. Each tile would have 4 squares, each passable/non-passable which shouldn't be hard.

Also does anyone want to build an A* algorithm for this? Would A* be overkill? I don't think so you need A* for AI, just so that it can intelligently get around obsicals if it wants to, the AI would not really have control over the algorighm but rather it could say it wants to go from point A to point B and the sytem would handle that.
[/edit2]

I haven't looked at the tiles but is there a reason you can't just do pixel perfect collision detection?

Shared consoles should be fine, it would be nice if you could mute some of the AIs however by pressing 1-4...

How so? Why can't you just use the allegro routines to convert the float to a fixed?

I vote against fog of war, and directional sight.

I feel so.

For the basic environment, I recomend:

The AI be implimented as a function which returns an integer, and takes no arguments.

The integer that it returns should be a virtual controller state (IE Bit0 means button1, bit1 = button2, etc)
That will give you up to 32 different buttons that the AI could be pressing which should be enough for any
keyboard/controller.

All information should be avilable through calling other functions. The following things should be queriable:

How Many Tanks are there? (returns int)
How many bullets are there? (returns int)
Which tank am I? (returns int)
Info about tank X (takes in integer, returns variables regarding the position, movement speed, other information about a specific tank)
Info about bullet X (takes in integer, returns variables regarding the position, movement speed, other information about a specific bullet)

//If these things vary from map to map:
How big is the map? (returns w & h as integer)
How big are the tiles? (returns w & h as integer)

Is the tile at position X, Y, passable by tanks? (takes X, Y, returns BOOL)
Is the tile at position X, Y, passable by bullets? (takes X, Y, returns BOOL)

(and you really should divide the map into small enough tiles that they can either be passable or not passable.)

Any other functions with extra features can be added without changing the existing "API".

edit: These make sense to me, since it's what the player sees, and how the player would interact, and that's really what an AI should emulate. But I am open to compromise. An AI compo is no fun if everyone hates the rules...

Hm, Steve Terry you realise that there are now two versions of the same thing going on? . Owell we'll see what happens i guess.

You can follow the other effort at a framework at the following address:
[url http://websvn.bafserv.com/wsvn/allegai]

Who is building the other?

Well primarily myself altough CGames and Winston Ewert have said they would pitch in. Baf is doing servery stuff and designing the interface to upload entries and view the standings etc.

I realize there are two versions, two is better than one. I like the more user side version rather than a networked version, it just got too complex to ever be completed so I went my own route.

Well I don't like the idea of the network one for a couple of reasons.

1.) Lag, and it with introduce oddities that your AI will have to deal with that it shouldn't.

2.) You have to have an interface built in your game to communicate over TCP/IP -- there's no reason for this... AI's don't need to contain network code... If he wanted something like this so bad, why didn't he just impliment a way in software to send a string/stream message, or a packet?

3.) the game becomes true real-time, in the one I've been discussing while it runs in real time, to the AI it might as well be turn based, since all AIs get executed once per frame... Who knows with the network one, by the time your data round trips to/from the server the game environment could be drastically different... (Sort of a sub-issue of lag I guess...) Basically the AIs running on machines with the fastest connections/fastest processors would always have better chances (More turns).

Michael, from what I gather the network one will be executed entrely on the server in a turn based manner, I just have no idea how they are going to output it, simply saying this or that bot won is no fun

Just a simple network uplink, then feed location/sprite data to the clients. Basically, they upload their bot, then you send them the level and images(if needed) and then you have location info about the AI and all projectiles, etc. to send to all the clients.

thematrixeatsyou pretty much sums up what is being implemented for "AI Arena". Except a few extra security features.

What "thematrixeatsyou" and ST said are completely at odds with each other about the network server... Which is it?

edit: re-read, nevermind!
I get it, you can view live... That's silly. You should just be able to download a replay version, or an avi or something.

Michael: an AVI would be a foolish waste of bandwidth. We are going to make it so that a user can download a replay after the match OR connect directly to the match to view the game.

Plus for testing, you upload your bot then you can run around the arena shooting at it and see how it will react, lets you have more exact testing of it

Why do you have to upload your bot for that? Why can't you just test it on your local machine?

Yeah, I don't know about all that. Sounds amazingly overkill. The whole "anti-cheating" thing is really a very poor reason, as the AIs can't get the location of the memory anyways, and any scanning of memory will easily be picked up.

(They can't get the location of the memory because for one it's a different process, and for two it isn't a global/statically allocated variable which points to it)

Ya the testing server vs local on-computer testing program has been in a little bit of a dispute. I've started leaning towards the local testing program personaly.

Why wouldn't local testing be allowed? If they hack it, etc, their AI wont work with the actual competition version of the executable...

I don't understand the issue.

The issue is it would be possible to hack it so that it did work on the competition 'executable'.

How?

If they only submit one source file, and you're not passing pointers to them, with the type of input/output scheme I've already mentioned, it's unhackable.

Well for one example one could allocate a new variable on the first cycle, find the difference between the address pointing to the memory they want to access. Once they have that number they could make their 'release' version find the correct address by allocating said variable and subtracting the pre-discovered amount.

There are a few other known cheating methods but rather then try to block each one of them one by one it is much safer to just restrict access entirely.

Anyway, above is the issue. As for my opinion on whether to do the test-server or not I've been leaning against the idea due to the added complexity. It also just feels safer as its hard to restrict code and make sure its safe to execute (ie someone could write code to DoD the pentagon and it would be the server doing it).

I think the most lucrative approach is to simply let people test on their own computers and look over the code before the actual competition to check for cheats. In addition extreme cheating should be obvious since the tourney is being watched.

I'd say the more variables in the game to consider, the more interesting it would get.

The test servercan also be there for people to test against each other. And they couldn't write code to DoD the pentagon, it would all be run in a chroot and the import symbols of the compiled program would be checked my the compiler system before it ever got loaded.

That's silly talk...
if you pass a parameter by value (not by pointer) a copy is made! the address of that copy should not reflect the original value's address -- I could be thinking in VB too much, if I'm mistaken, the obvious exists, copy the variable manually...

That's just really silly...

edit:
you could also make all your request for information functions something like this:

void get_tank_pos(int tank_id, double * x, double * y, double * d);

and copy the values of the existing variables over the top of the variables they pass in...

In my system, each AI si a different process. They only have access to their AI objects and their Vehicle objects. This is not DDustin's system.

Who said anything about passing parameters? The cheat described said nothing about parameters.

I don't understand how the can get the addresses of variables that they don't have access to in the first place.

If all of the variables they use are declared in it's own function theres no way it can get the address of anything used outside of it's function!

Pointer math

All of the pointers will be to your own variables in your own function.

Say you do create a static variable, and make a pointer to an alloced block of some sort that was new that frame, ok.

Now you do it next frame and take the delta.

Ok

That delta could be any size depending on the amount of staticly allocated data the other ais are using, as any non-statically allocated data is free upon exiting their code blocks...

you could scan this region, and make memset to 0 as a jamming signal (mess up any allocated data the other ais are using...) but you can't really do much else other than mess with the other AIs without risking a crash...

since the program data is located elsewhere the pointer math doesn't really help you... you might be able to find something interesting by doing a really intelligent scan of the programs allocated memory for value matches that the functions are returning to you, but even that could risk a crash, and would be really obvious to spot in code.

So, will my prophecy come true? I am ready to join the contest! When can we start it?

DDustin and I have split projects. We are still communicating (I have a subdirectory for my project in his repository), and will maintain AI compatibility (AIs will work in both apps), but we decided that the goals of our projects were too different.

My API documentation (just updated) is available at http://cgamesplay.com/files/aia. We are communicating on irc://irc.freenode.net/allegro-ai. The Subversion repository is at http://svn.bafserv.com/svn/allegai, and you can view it at http://websvn.bafserv.com/wsvn/allegai.

Hmm, who's team am I on now?

Whoever's you want to be on. I have the intent to write mine entirely myself, but still converse with you guys.

My code is going in the same repository (at least for now), and is under the zlib/libpng license. If DDustin's is a similar one, I can help myself to whatever code I'd like It would be nice to be able to use one client with either server...

Btw, the protocol looks insane

This is turning into a "write your own AI competition" competition!

All is going as my prophecy said it would. My Nostradamus-fu is strong!

don't speak to soon!