PDA

View Full Version : New ideas for AI in games?



WILL
18-03-2012, 11:05 PM
Has anyone been doing any work with AI of any sort in their recent game projects?

AI has so many uses and doesn't all necessarily have to be all that advanced. For example you take Pong. If you want to make a single player game of pong to add a computer player you simply need to program the computer player's imposed reactions. If the ball is the to computer player paddle's right then steer the paddle right, if to the left the same.

Of course you should then have a degree of error so that the computer player doesn't always win. Say something as simple as a delay time before the computer can make another direction change or a value that it can be off by the ball's actual location in relation to the computer player's paddle. This part is trial and error and usually requires testing, but can be quite fun to work with.

AI doesn't really need to be any more than that for a beginner. You can go further and learn such things as path finding, state machines and as far advanced as training neural networks, but it all depends on what you need the AI player(s) to do in your game and at what level of difficulty you want them to provide your players.

What are you guys doing with your games that may or could require AI?

LP
19-03-2012, 01:26 AM
AI has been previously a very popular topic and in certain occasions there was even a degree that you can obtain in institutions. However, it didn't live up to the expectations and later was renamed to "Intelligent Systems" and now is an area of science that has limited applications, being more like a meta-science itself.

In games, dealing with AI usually ends up with using one of Seach Algorithms (http://en.wikipedia.org/wiki/Search_algorithms), probability sets, Markov chains (http://en.wikipedia.org/wiki/Markov_chain) and so on.

In my opinion, to achieve a good AI in games you need to translate expert's player knowledge into execution scheme that accurately reproduces the expert's decision making process. Of course, you can take advantage of processing power and apply search algorithms and exact physics calculations whenever possible to beat the player, something that is difficult to achieve in real-time for a human mind.

User137
19-03-2012, 11:15 AM
I'm building the game so that there's no distinction between Human and AI controlled player. TPlayer class might have MoveTo() command so that, whichever executes it, will automatically follow the set rules of the game. For AI you can map all options it can do at the time, and then select 1 of them. Might be combination of weighted and random choice.

In a board game you can try all those available moves (which is usually quite few), and the moves that would follow that. A scenario that leads to defeat would naturally set the weight value low, and a victory condition respectively high. In many games you can also value the scenarios "progressive weight". For example in a game where your goal is to move all pieces to opposite side of the board, then naturally scenario where sum of distances of all your pieces on board being smallest, is most valuable. Or scenario where enemy has less pieces than you may be more valuable than normal neutral state.

code_glitch
19-03-2012, 04:12 PM
Not in games I haven't. But in the last week I have been looking at artificial neural networks, which are indeed very interesting. The prospect of being able to implement one on todays hardware and multi-threaded concepts offers some interesting evolution in that field. However, due to how abstract it is, I've been toying with the idea of a multi-agent system which in my opinion is the better option. Something like having the game thread along with an independant AI thread that simply has a pointer to the TPlayer^.Input() function is interesting for multi-core systems.

paul_nicholls
19-03-2012, 09:32 PM
Well, I do have AI in my Boulder Dash game The Probe - the enemies have decision making as to when to turn, or go forward.

phibermon
19-03-2012, 09:33 PM
I've created and am in the process of improving generic AI components in JenJin. It currently covers techniques related to movement however I've done little on decision related AI such as state machines but have researched such techniques extensively. Currently I have various steering implementations, path finding and following, region biased constraints as well as extensive tie ins with various 'region' types in the engine (Terrain (spherical + flat), portal/indoor and voxel (think minecraft). As the engine is designed along side a WYSIWYG content tool, anything that can be visually configurable is so.

When I grace the AI portions again (I'm currently finishing off the GL2.x support, was only ES2/GL3/4 previously) I'll finish off the event hooks and it should then be possible to code state machines with scripts. Events can be triggered from lots of different things :

A Spatial entity entering the confines of a region
Coming within a given radius of a fixed point or another entity
User events specified in scripts
etc

You can also trigger timer style 'events' for paradigms that don't fit well with classic events IE you may want the bias for an entity to move away from another to scale with distance to that entity.

And obviously anything that's needed that I don't add can just be hard-coded/scripted in any game client code.

--

I will eventually look at options for using neural-networks as I believe it's something that a lot of people would like to experiment with however, they are not for the faint hearted and how they are used is not as direct as people would imagine. They do little more than bias state machine outcomes in most games and very few use them for direct control of an entities actions.

de_jean_7777
20-03-2012, 09:27 AM
In my current game project the AI is simple. All entities follow a set of actions. When an action is complete it goes on to the next action in the list. Some actions have simple decision making, which can result in jumping to another action (a random chance or so) The action state is stored individually for each entity. Actions can be chained, so they are performed simultaneously (e.g. following a path, and firing projectiles at the same time, while making a decision to change paths). With time I expand the number of action types, for now it's: path following, waiting at a point, teleporting to a point, and firing projectiles, timer to go on to next action, and random chance to go on to next action (a sort of random behavior at certain points). This is sort of simple scripting with limited number of actions, and works well enough for a simple top-down scrolling space shooter. I also intend to make some actions situation aware, like projectile firing, so that the enemies don't fire too many projectiles and swamp the player. The actions are configurable to a certain extent. The most tiring part is coding all the action lists and configuring them, so I made some helper functions and predefined actions to help.

paul_nicholls
20-03-2012, 11:17 AM
In my current game project the AI is simple. All entities follow a set of actions. When an action is complete it goes on to the next action in the list. Some actions have simple decision making, which can result in jumping to another action (a random chance or so) The action state is stored individually for each entity. Actions can be chained, so they are performed simultaneously (e.g. following a path, and firing projectiles at the same time, while making a decision to change paths). With time I expand the number of action types, for now it's: path following, waiting at a point, teleporting to a point, and firing projectiles, timer to go on to next action, and random chance to go on to next action (a sort of random behavior at certain points). This is sort of simple scripting with limited number of actions, and works well enough for a simple top-down scrolling space shooter. I also intend to make some actions situation aware, like projectile firing, so that the enemies don't fire too many projectiles and swamp the player. The actions are configurable to a certain extent. The most tiring part is coding all the action lists and configuring them, so I made some helper functions and predefined actions to help.

Sounds very cool! I don't suppose you could share some code snip-its or something? ;)

de_jean_7777
20-03-2012, 11:33 AM
This is the action type.


TEntityAction = record
{action and it's properties}
action, effect, properties: longword;
{action is complete}
done: boolean;

{direction}
vDir: TVector3f;

{distance traveled, speed}
distance, speed: single;
{minimum duration, max duration, start wait time minimum, start wait time maximum}
minTime, maxTime, startWaitTimeMin, startWaitTimeMax: single;

along: PEntityAction; {action to be performed along with this one}
next: PEntityAction; {action to be performed after this one}

{an associated path}
path: PPath;

{an associated projectile group}
projectileGroup: PProjectileGroup;
end;


This holds action data per each entity and action.




TEntityActionData = record
initialized, done: boolean;

distancemoved: single;
lineardir: longint;
actionTime, startWaitTime: single;
timer: TTimerData;
waitedAtStart: boolean;

vPos: TVector3f;
end;


Here is a simple move action.



procedure actionMoveDistance(var ent: TEntity; var a: TEntityAction; var d: TEntityActionData);
var
vmMov: TVector3f;
dist: Single;
begin
if(d.distancemoved < a.distance) then begin
vmMov := a.vDir * (a.speed * oxMainTimeFlow);
dist := vmDistance(vmvZero3f, vmMov);

d.distancemoved := d.distancemoved + dist;

ent.vPos := ent.vPos + vmMov;
if(a.distance < d.distancemoved) then begin
ent.vPos := ent.vPos - (a.vDir * (d.distancemoved - a.distance));
d.distancemoved := a.distance;

nextAction(ent);
end;
end;
end;


There is a lot more, but I think if I shown how everything works this would be one really huge post. I still need to expand this and improve the already existing code.

Eric
20-03-2012, 12:54 PM
I'm a fan of PID controllers in AIs (http://en.wikipedia.org/wiki/PID_controller) for a whole lot of behavioral aspects.
You can slap one on top of path-finding or other combinatorial logic to make it look more natural, along with delay loops to prevent the AI from having god-like reflexes.

You can use it to control a lot of things, from a pong bat, a tracking missile, a gun tracking the player, a monster moving across the map, a flock of targets, an airplane that doesn't cheat, etc. All the flight logic in AirBlast was done with PIDs, the AI having access to the same exact flight controls as the player, and it would use them to fly in formation, attack, evade, etc.

You can also vary difficulty by using more or less adjusted sets of parameters

But I guess the real advantage is that it can behave in a natural fashion, and works very well in simulated environments when things aren't "smooth" because of collisions, external events, terrain, etc (after all, it comes from real-world control feedback mechanisms).

They're extremely simple to code, and once you're accustomed, they're fairly simple to tweak manually.

I'm sure the vast majority of those that have ever coded a game have used (ofttimes unknowingly) at least the P, sometimes the PI variant. But when you know the theory and the limitations of PIDs, you can put them to use more effectively, and more creatively ;-)

They're surprisingly versatile, and can be applied to various fields, not just direct "first line" controls, but also f.i. to control tresholds or other fuzzy logic parameters (and have the AI entity switch between various behaviors according to them). It's one of those very simple logic bricks that has potential for great complexity, and can "smooth" the output of more hardcore graph-based logic.

de_jean_7777
20-03-2012, 07:15 PM
I'm a fan of PID controllers in AIs (http://en.wikipedia.org/wiki/PID_controller) for a whole lot of behavioral aspects.
Seems interesting. Though the math on the wiki page does not make it seem simple.

code_glitch
20-03-2012, 09:33 PM
Hmm, those PIDs do look interesting indeed, especially for difficulty manipulation... The concept is a lot like my first 'AIs' - a separate thread/timed loop every cycle that ran a similar sort of 'algorithm' per se.

Eric
21-03-2012, 07:47 AM
Seems interesting. Though the math on the wiki page does not make it seem simple.
Yeah, but don't be fooled by the sigmas and other fancy math symbols, there is a pseudo-code snippet that is probably a lot simpler to understand (for non-mathematician), and if you restrict yourself to the PI variant (drop the "derivative" and its use in "output" line), it becomes very trivial.

The pseudo-code doesn't contain it, but in practice you'll want to either clamp the integral term or dissipate it over time (dissipation works well IME for game AI purposes), and assuming your game loop already has so kind of fixed timesteps and you compute the output only once per frame, you can use something like that:



function TControllerPI.Output(setPoint, feedBack : Float) : Float;
var
error : Float;
begin
error := setPoint - feedBack;
FIntegral := FIntegral * FKdissipation + error;
Result := FKp * error + FKi * FIntegral;
end;


setPoint is the value you desire (an angle, a speed, a position...)
feedBack is the current value (or delayed value) in the game/simulation
FKp & Fki are proportional and integral gains (to be tuned)
FKdissipation is the integral dissipation gain (between 0 and 1, start from 0.9 and tune up or down)

And output is the command to send to the simulation (steering, pressure on accelerator pedal, etc.).
If things go in the wrong direction, just negate the output or your gains.

Alternatively you can also use


Result := FKp * (error + FKi * FIntegral);

Some people find that variant easier to tune.

For tuning, the wikipedia article gives good info in http://en.wikipedia.org/wiki/PID_controller#Manual_tuning and http://en.wikipedia.org/wiki/PID_controller#Ziegler.E2.80.93Nichols_method

Though for games AI, you don't need very good tuning (or it looks robotic)

You can cascade PID controllers, or have PID controllers feed into other PID controllers gains. That allows them to handle more complex control situations (like when there is a lot of inertia), or can be used to simulate an AI that is getting "angry" over time (by ramping up the gains, you can get jerky or twitchy-looking movements).

deathshadow
17-06-2012, 04:04 PM
In a number of ways, I think the more complex you make an AI, often the less 'real' if feels. To borrow from Terry Goodkind, you often have to keep the "Wizard's First Rule" in mind: People are stupid. Sometimes the simpler your logic, the more intelligent it feels to the player.

A great example of this is the logic of the ghost in Pac Man (something I studied a good deal in my clean-room implementation of it in 3/8ths scale) -- it's simple, but they often seem quite smart... When it's really a DUMB algorithm made up of a few simple rules.

1) ghosts cannot normally reverse direction.

2) ghost cannot turn 'upwards' in four specific locations

3) ghosts have three modes, scatter, follow and flee.

4) When switching between most modes they immediately reverse course. (the only exception to rule #1).

5) Exiting 'flee' does NOT change their direction.

6) in scatter, each ghost tries to go to it's home corner.

7) Follow rules:

7a) Red Ghost aims for player. At 2/3 pellets remaining speed +5%, at 1/3 speed +10% and remains 'stuck' in pursuit. (fast pursuit blinky is called a "Cruise Elroy" -- nobody knows why)

7b) Pink Ghost aims 4 tiles in front of the player, an overflow bug in the code makes it to that if the player is facing up, It actually aims up 4 and left 4.

7c) Cyan Ghost is a bit more complex. It's target tile is calculated by taking a point 2 tiles in front of the player, making a vector from the red ghosts position to that point, and then using the exact opposite as the result.

7d) Orange Ghost is more than 8 tiles from player, aim for player. Less than 8 tiles, return to home corner. He's fickle. This actually makes the bottom left corner one of the hardest because if you're within 8 tiles of that corner, 'clyde' is gonna stay there.

... and that's really all there is to it. My own Pac Man ripoff mixes it up by adding a random 1 in 6 of ignoring rule 2, and a random 1 in 6 of ignoring it's normal pursuit rules at intersections. (ok, I've got a thing for 1d6).

That's actually pretty simple... and so good, that every time a new game goes and uses the same basic logic, it's 'praised' for it's AI. Take the original F.E.A.R. -- it's 5 mode (pursue, lead, cover, flee and scatter) using remarkably similar logic in terms of following or getting ahead of the player.

Scripted logic feels intelligent -- because it has a plan -- throw in just a hair of randomness to make it less predictable, and you're golden.

You also have to work off people's perceptions -- the smartest "lag pursuit" will often feel dumb as a rock because it can't actually hit you, while the dumbest lead pursuit AI can be really challenging because it's always aiming not for where you are, but where you're going. Learned a lot about that in ACM school at Eglin. If you were making a combat flight sim that actually had physics (sorry Airblast, but... no) having the AI ride the throttle to maintain airspeed in turns, keep it's energy high while maintaining corner velocity, using altitude to trade kinetic energy for potential and vice versa, turning not at the player but lead pursuit -- these aren't 'complex' concepts; easy to implement and could easily make serious threats to the human player.

Though a lot of times it comes down to NOT trying to hollywood it; because blazing along as fast as possible in a dogfight will keep you alive -- much less idiotic nonsense like "Bang the brakes, he'll fly right by"...

LP
17-06-2012, 08:15 PM
In a number of ways, I think the more complex you make an AI, often the less 'real' if feels. To borrow from Terry Goodkind, you often have to keep the "Wizard's First Rule" in mind: People are stupid. Sometimes the simpler your logic, the more intelligent it feels to the player.
Actually, I think if you invest too much on AI, it will feel predictable or "wired". In real life, many things are based on very simple rules, or at least "simple" rules have major influence for an external observer (e.g. flowers open during the day and close for the night, etc.), so if you keep AI simple yet flexible, it will be quite joyful to play with.

This is why in some schools the entire "AI" theme was dropped and replaced by "Intelligent Systems", which lately have been displaced by database and math related courses, since in many cases the "classical" AI is either application of random theory or one or more search algorithms.


Scripted logic feels intelligent -- because it has a plan -- throw in just a hair of randomness to make it less predictable, and you're golden.
This also happens elsewhere: when you are reading a book, which you can think of as a "script", you are imagining the entire scene, characters and so on. I think, this is because typical situations that we can think of, can be scripted, and when reproduced, it is quite easy to mistake the scripted part with the actual reality.

Super Vegeta
17-06-2012, 08:54 PM
In a number of ways, I think the more complex you make an AI, often the less 'real' if feels.I'd say that one of the problems in having an AI that reacts to a lot of factors is proritizing them and predicting all the exceptions. An AI that contains a clause "if you have less than X hp, flee, else attack" seems a good idea - but then, this is clearly absurd if the unit is totally surrounded - it will get killed anyway, and if it continued to attack, instead of trying to run away, it would have at least dealt some damage (maybe even killed someone).

deathshadow
17-06-2012, 11:10 PM
I'd say that one of the problems in having an AI that reacts to a lot of factors is proritizing them and predicting all the exceptions. An AI that contains a clause "if you have less than X hp, flee, else attack" seems a good idea - but then, this is clearly absurd if the unit is totally surrounded - it will get killed anyway, and if it continued to attack, instead of trying to run away, it would have at least dealt some damage (maybe even killed someone).

That's where that bit of randomness thrown in can really help in terms of ignoring triggers. The majority of people when it comes to fight or flight, pick flight -- to incorrectly quote Heraclitus (actual attribution unknown):

"Out of every one-hundred men, ten shouldn't even be there, eighty are just targets, nine are the real fighters, and we are lucky to have them for they make the battle. Ah, but the one, one is a warrior, and he will bring the others back"

Or the wisdom of Zathras:
Ah, but for the one. No, not The One. Draal gave Zathras list of things not to say. This was one. No. Um, not good. Not supposed to mention One or The One. Oh. Uh, you never heard that. The One leads us. The One tells us to go, we go. We live for The One. We would die for The One.

(you know it's bad when you can hear a character talking an uppercase The)

Taking queues from NPC systems in RPG's can also help -- it's part of why CRPG's are popular. A 'fear' scale for example that's weighted/rolled against a characters willpower... a critical success being the equivalent to Patton's "Bravery is just fear holding on a second longer". Normal successes on willpower could add to a 'rage' scale that enhances the next roll... basically fail the roll, go into flee or 'cower' if cut off. Pass the roll, they hold. Hold until relieved... hold... until relieved..., critical success, they do a balls to the wall charge, no matter how stupid it is. Critical failure... well... Shell shock/Battle Fatigue/Operational Exhaustion/PTSD/Patton is gonna slap you silly back at the aid station. You do it on say a scale of... 2..12 via 2d6, so that critical success (12) and critical failure (2) are 1 in 36 apiece odds-wise, and you have a very simple system that turns a handful of behavioral states into a unpredictable but believable system.

I think most anyone looking for inspiration on AI and player behaviors can learn a lot from a pen and paper RPG system, especially since a computer can make tracking all those numbers and 'rolling' for results simple -- often simpler than the convoluted systems I've seen in some folks code for handling what enemy units do. Studying statistics is also a great idea, as, well, take that quote above abnout 'out of every 100 men'... You could implement that quite easily; giving you 100 guys with the same basic stats, but varying behaviors.

Ingemar
18-12-2012, 04:01 PM
AI has been previously a very popular topic and in certain occasions there was even a degree that you can obtain in institutions. However, it didn't live up to the expectations and later was renamed to "Intelligent Systems" and now is an area of science that has limited applications, being more like a meta-science itself.

I think the problem that the concept over-hypes itself already in the name. But I consider "AI" and "game AI" to be very different.

I wrote two whole chapters about game AI in "Tricks of the Mac Game Programming Gurus" in 1995, probably one of the longer texts about the subject at the time. But I didn't call it "game AI" because "AI" was such a hyped concept, I called it "behavior" and "environment". But it was about the usual stuff, basic behaviors (hunter, evader, patrol), path finding, FSMs, game state analysis...

Today I am teaching graphics and game programming, I have similar material in my textbooks, but now I call it "game AI" and I actually consider the concept a nice contrast to AI. Game AI is well known to be limited, so we don't expect wonders, which is a good thing.

My favorite game AI techniques are flocking and influence maps. They can really produce interesting and convincing behaviors. But do spice it up with some randomness.

WILL
19-12-2012, 08:17 PM
I'd love to have a PGD Challenge that is all about AI.

The thing I love about the whole topic, in some ways Ingemar is right (it's a bit overhyped), you can hack at it and as long as you make it look like it's doing something intelligent, or behaving intelligent, then you have a pretty good game AI. It's something that can be easy to get into, but can be hard to master.

I think such a challenge would have your players go against and try to "beat" it OR create non-player AI character/bots, etc that have to work with the player in some way.

Designing the challenge rules might be as interesting as designing the games that go into the challenge it's self. :P

User137
20-12-2012, 12:28 AM
Speaking of AI challenges, one just started on monday. Sadly it's hosted in finnish only. There's been many similar no-reward contests throughout the years, lots fun. They make up new game and rules, and let people use whatever programming language they want. You send source code only for the console application, and hoster makes binary of it on Linux test machine. Then they make them play against eachother and count points.

Currently up is: http://www.ohjelmointiputka.net/kilpa.php?tunnus=valtapeli
Not sure if google translates the page well, but i'll explain idea shortly. 16x16 board, where players fill 1 empty cell per turn. At the end all solid areas are calculated, and you get exponentially more points the bigger the area is. So 1 big connected area would give most. Other AI/player is only harassing, trying to disconnect the areas of other.

wodzu
30-12-2012, 10:31 AM
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.:)

Ingemar
21-03-2013, 08:50 AM
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.)

pstudio
21-03-2013, 09:39 AM
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.

User137
21-03-2013, 02:54 PM
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
21-03-2013, 08:54 PM
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
21-03-2013, 09:33 PM
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
23-03-2013, 08:37 AM
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
23-03-2013, 03:10 PM
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
23-03-2013, 03:35 PM
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
25-03-2013, 04:08 PM
Crazy idea
I was just looking at the Worms clone Hedgewars (http://www.hedgewars.org/) 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
25-03-2013, 04:34 PM
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
25-03-2013, 06:54 PM
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 :D Much less features still can make a good contest.

Rodrigo Robles
26-03-2013, 10:02 PM
I participated in the last google aichallenge too. The last version of my bot uses learning to take their decisions. Unfortunately the results of my bot was modest. I read the post-mortem of the winners and found no one using learning, only specialized the algorithms for that requirement.
Learning is maybe the most interesting topic in AI, but in practice it can't beat an optimal algorithm...

pstudio
27-03-2013, 12:31 AM
I participated in the last google aichallenge too. The last version of my bot uses learning to take their decisions. Unfortunately the results of my bot was modest. I read the post-mortem of the winners and found no one using learning, only specialized the algorithms for that requirement.
Learning is maybe the most interesting topic in AI, but in practice it can't beat an optimal algorithm...
Yeah, that's my experience as well. All these modern AI methods where the AI try to learn to play is pretty cool, but they'll rarely come near custom tailored AIs. Some of my teachers at the university runs the Mario AI Challenge (http://www.marioai.org/) which is focused on these more modern AI learning methods. However they failed to specify that in their first challenge so the winner was a relatively simple AI agent using A* (https://www.youtube.com/watch?v=DlkMs4ZHHr8) to find the optimal path.

There's a reason why commercial games use custom AIs'. It works and is often more simply to implement than learning methods. I do believe that learning methods will gain a greater importance in commercial game AI, but it will only be as part of custom AIs and in optimising parameters. An AI based purely on learning is probably just to hard to do.