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.

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>

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.

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.

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

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!

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 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.

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?

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

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 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?

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.