AI (some discussion and ideas).

[Chesso]

I'm looking to implement a basic enemy into my game (with some sort of AI).

I have found myself a basic image of a slime enemy (most people familiar with RPG's have probably come across this enemy in many games although slightly different in appearance for the most part).

I am currently re-colouring, animating, shadowing and attempting to add other adjustments and details to it.

Some of you have pretty much seen the basic idea behind the game (you gotta collect or smash some blocks, heck it could be part of castle or anything but it's still the same idea).

And the enemies I want to add will just try to make this task a little more annoying and/or difficult :P.

So the slime enemy itself (I might have a small and a large version, but same AI), but it will be a very basic enemy (perhaps replaced later but I need something to build from and test to begin with).

I'm not even sure if what I'm planning could even be considered an AI, but I basically want to build something for it now, like perhaps it will follow a specific path (e.g. going so far left and then going so far right, repeat) etc.

I'm not looking for any material on AI in general but some discussion, ideas and how to implement from a theoretical or psuedo-code point of view that may be fitting for this little guy :P.

[tanffn]

As I don’t know your game, it would be helpful if you can upload a sketch of the screen. The sketch needs to show the player, obstacles/elements and “enemy” of a level.

I simply don’t understand what you’re trying to implement.. :?

[AthenaOfDelphi]

Chesso,

Sounds like just the kind of thing I was going to implement in our competition entry.

I figured that I would have enemies 'patrolling' on pre-defined paths (or predefined areas). If they spotted you (I implemented a simple line of site system) they would then use A* path finding to get a path to your current location... if they spotted you again on their way, they recalculated their path. If they then lost you, they stood on the spot and looked around for you for a while before returning to a predetermined point and restarting their patrol behaviour. Otherwise, they would pursue you across the map until you either lost them, killed them or they were unable to get past an obstacle.

In reality, our enemies ending up just wandering around the map due to a lack of time, but I figured that the following plan would work...

1. Patrol an area (A), path (P) or stand guard (G)?
2A. Define the area that the enemy can patrol
2P. Define the path the enemy can patrol. This requires a starting point and a series of way points. You can either have the system precalculate the direction or you can use A* path finding to get a path to the next way point.
2G. Define the point where the enemy stands and the directions they look. This could be as simple as they stand here and periodically, they turn to face a new direction... you could be evil and make that action random so players can't spot patterns.

Obviously, these decisions will most likely be made in the editors, so you need to define some data storage for this. You can of course mix these up. The enemy will wander along a patrol path. At a point, he wanders around an area for a while before continuing on a path. He then reaches the end of a building where he stops for a period and looks around before going on his way.

To implement this I planned on having a statemachine built into the base enemy class that implemented all of this. It had various states to indicating whether the character was roaming, patrolling, guarding along with the direction they were facing/travelling. My A* worked by saying go in this direction for X steps. When it got to 0 it popped the next path component from the list and continued.

Sorry theirs nothing in the way of pseudo code, but just some thoughts I had when planning on implementing enemies.

[Chesso]

Athena, you do have the right idea in mind but for this game I do not need it to be anywhere near that complex (in the future however I would like to try my hand at building games that involve more complex arrangements like this).

This particular enemy only really needs to a follow an absolute pre-defined path and not stray from it at all (or perhaps have slight variations if it hits a solid object, although I'm not sure what to do on that one).

Either that or a mix of that and going after the player if he is in a certain range (defined in pixels) and yeah line of sight for enemies would just be awesome to make and play around with it but that much isn't necessary for how it is for now.

This game isn't something I planned heavily from the beginning, as usual it just a very small part of an idea that popped into my head, I started it, and just built and changed things from there, it could end up as an MMORPG for all I know (although I highly doubt it lol).

The most difficult factor for me, or the problem of starting to build the AI is how on earth I should handle it.

This enemy will be a sprite as apart of TSpriteEngine (for collision with the player and it's DoMove procedure). But what do I need to do in order to have him walk one way a certain distance and then come back the other way and repeat.

I mean I could certainly think a few long winded and messy ways of using a ton of booleans and variables to count time and just automatically swap the enemy around but I feel that there is probably a better way of handling this.

Any thoughts on that?

To explain the game a little more, well if you check my BLOCKBASH thread in the uhh "your projects" section I think and you will see basically the kind of game it is, although it has changed considerably since (size, graphics and some inner workings), but the idea and how it works is still the same.

[AthenaOfDelphi]

Hi Chesso,

In terms of getting your enemies to follow a predefined path, then you need to come up with a way of defining the path... do you have a level editor?

If it really isn't any more complex than that and you have a tile based map, you could do something like this...



POSITION AT START OF PATH

WHILE ENEMYALIVE DO

CASE ENEMYSTATE OF

MOVINGNORTH :
ENEMYY:=ENEMYY-1;
END

MOVINGSOUTH :
ENEMYY:=ENEMYY+1;
END

MOVINGEAST :
ENEMYX:=ENEMYX+1;
END

MOVINGWEST :
ENEMYX:=ENEMYX-1;
END

ENDCASE

STEPS:=STEPS-1;

IF STEPS=0 THEN
GETNEXTENEMYMOVE(ENEMYSTATE,STEPS);
ENDIF

ENDWHILE


Thats a real simple idea... GETNEXTENEMYMOVE returns the new enemy state and the number of times it has to go through the state machine, but I'm sure you get the idea.

If you want to do something a little more complex then you would need to add states to the state machine and provide the necessary control mechanisms to read paths from your level data and switch states as necessary.

So... heres a zip file containing the code I put together for the first few stages of the 2006 PGD competition. Its not great and its probably nothing like what you want to achieve, but it may give you some ideas.

unitOREEnemyClasses.zip (http://ore.outer-reaches.co.uk/files/unitOREEnemyClasses.zip)

For anyone else that may be about to comment on this code ;-) I don't want any comments about the quality or optimisation of it because I know its not particularly good :-P It was the first enemy AI for our competition entry and I've posted it only to give Chesso some ideas.

fState.pathfinder was a link to my A* path finding implementation. This was a seperate thread with three path finding job queues. Low, Medium and High. When an element of the engine wanted a path, it would submit a request to pathFinder along with a callback... pathfinder would get to work on a first come first served priority basis... when it was done, it would run the callback and provide a list of moves to the 'client' that requested the path.

The code is clunky, its not great and it certainly doesn't implement everything I wanted to do, but it did provide enemies that would wander around the map (going only where they could go without going through objects).... if they spotted you, they would pursue you until they lost you for a period and then they would just start roaming again.

To use it, I can't remember how it was setup... I think you created an instance of the object... positioned it and then called doMove to do all the processing for that enemy. As I say, it wasn't great, but it may help you get some ideas.

[Chesso]

Thanks I'll check that out as soon as I can and have a crack at it.

For this enemy I'll probably use the DoMove procedure of the sprite engine to calculate any movement and movement AI, and then DoCollision to handle anything concerning solid objects to switch to a new path or w/e.

[pixin]

finaly an interesting subject for delphix,i always found a problem to move my character in professional way,but i think that path finding is very dificult for me that's way i stopt programing my own pacman game, but any way if someone post a very easy tutorial about AI, pathfinding or precalculated movment may be a will finish my pacman :)

[AthenaOfDelphi]

Hi Pixin,

For Pacman, you don't really need path finding as such. Traditional Pacman ghosts were always pretty dumb wandering aimlessly around the maze. So you don't have to worry about say A* pathfinding.

I've knocked together a really quick example of two ways you might go about doing it to try and give you some ideas. The two move routines 'move' and 'advMove' both have their flaws. The ghosts seem to stick around the outside of the maze. With the 'advMove' routine, you could change the weighting of the 'choices' the ghosts have by resizing the 'choices' array and adding the relevant directions to it. Thus, you could increase the chances of them taking a turn in the maze where one exists... this would help get them back into the center of the maze.

PacmanPathfindingExample.zip (http://athena.outer-reaches.com/pgd/PacmanPathfindingExample.zip)

To see the example in action, run the EXE, click the squares to create a maze (each click cycles from gray, dark gray, black and back again). When you're ready, click 'Launch Ghosts'.

[Chesso]

Actually, I have read that pacman went a bit further than that (the original that is).

For example, one ghost would find the shortest path to pacman and pursue him. Another would move based on pacman and the chaser and where they are heading to try and block him off, and the other would be mostly random but away from the others and sticking mostly to that section, as pacman will need to go there eventually and he'll have his shot.

Not sure how they pulled that off back then but it's a very smart idea lol.

[pixin]

AthenaOfDelphi thank you a lot for your help and your code too :) i really appreciate, i see the result and they are moving the same as my character, in random way or like robot, wich is not what im looking for, now im looking at your code, wich is not very easy for me(as im a starter in delphi), so i need a little time to handle it or may be to improve it, i have some thing for you, soo keep in touch i will contact you soon :) again thanks a lot for your effort, god bless you..

[jasonf]

I hate to be a pedant, but this isn't a DelphiX question. Could someone please move this thread to the AI section and remove this post?..

Cheers

[Chesso]

Well, my question was kind of targetting UnDelphiX/DelphiX.

It does after all handle things differently no matter what you want to do, data on how to do AI is kinda useless if you don't know how to implement into what you are using :P.

[jasonf]

Not really, your AI implementation will use DelphiX as a sprite handling and graphics rendering component set. But essentially AI and even the more advanced movement of your sprites is outside of the scope of DelphiX.

The basic movement of sprites is closely tied into the Delphix mode of problem solving as it's closely tied into the sprite engine by the properties it exposes, but that would be as far as I would go with that.. everything else is a question for a different forum.

AI questions can be generally applied to more than one engine as their appropriateness is determined not by the engine you use but by how you've structured your game mechanics, your mapping system, your sprite control mechanism, your pathfinding system. None of which are covered by DelphiX. You have to implement these things yourself.

All the AI system needs to know is how to get around your map, how to distinguish good guys from bad guys, where the powerups are, what constitutes a threat.. nothing to do with graphics, sound or input at all.

No-one with an AI question at a later date would dream of looking in the DelphiX forum for an AI answer.

Your question regarding a simple AI for your game is a good one and deserves a place in the AI section as other developers would undoubtably look for a similar answer in the future, perhaps long after DelphiX has pushed up its last daisy.

You're making some good progress on your game by all accounts and from what I've seen from your demo. I think you've pretty much got all the basic DelphiX answers you need. The questions you're asking now are a lot more advanced and specific to other - more useful areas of the site.

My game uses Jedi-SDL, but I wouldn't look there for help with my AI.

Sorry if I've laboured on the point or seem patronising, I'm not having a great day so far (don't ask) and you may be getting some accidental flak.. sorry about that. It's not intentional.

[Chesso]

Oh I definitely see your point, I was just initially using the process of elimination, normally getting help from someone who was once in the same boat can be more helpfull than answers from someone who has only been in luxury liners (they know nothing about my kind of boat) :P.

I think I just made that saying up >_>.

[savage]

Moved to the AI forum

[jasonf]

Yeah, I know what you mean. However, you'll find that everyone here's been in the same boat at one time or another.

I'm actually a noobie when it comes to AI, it's one of the major tasks I've got left on my game... thing is, I'm leaving it until I've got a complete understanding of what I need to do... which means finalizing some of the currently fluid ideas I've got at the moment.

But it's safe to say that the final AI system will have a lot of useful things inside which may be portable to other applications.

Path Finding.
the actual laying of the path for a sprite/drone to follow.

Path Following
Moving the sprite from one node to the next in a series of pre-defined nodes.. this can also include additional path finding to get from one node to another in a more accurate way..

Rules System
Based on various inputs, decide the best output.
I'm not entirely sure how to do this. I've seen rule bases alg's written using a simple list which is parsed each turn. Some of the items in the list have wildcard flags against the inputs. Rules are punished or praised depending on the result so eventually, according to the theory, only the most successful rules should be executed.
I think the hard part will be determining which of the inputs are actually relevant to the rule and whether it should be punished or not.

but then, my game is pretty complex.. even though from the outside it looks simple.

[Chesso]

I have an idea, if not already done (although I can't do it myself obviously lol).

Is there anyone here who could write a sample game (with source) that displays how to do different AI?

Maybe just some basic stuff like having a sprite follow a basic one way or the other path, to sprites that can find the shortest route to a location.

I dunno really, but an app with source that shows some basic and different kinds of basic AI would be a great help, or atleast I think so.

[jasonf]

well, you've got 2 ways to make your sprite move towards a target.. and depending on the complexity of the maze, you can either do one or the other to different levels of success..


1. Pacman style AI.
Basic rule based AI. Makes decisions at junctions towards or away from player (depending on whether the player has eaten a pill or not) if the AI hits a corner he goes in the direction of the corner, but not back on himself unless he hits a dead end.

2. A* style algorithm...
Quite complicated, best designed for maze style games where getting lost in the maze would look stupid. It finds the shortest route possible based on the parameters it's given.. it can handle hills and other obstacles and can find the shortest path or the least expensive path. Uses a bit more processing power though. There is an example on this site for A*, there are also loads, bucket loads, monsoons of examples on the net about it.

I think your game needs a version of #1


The most simple AI in the world is

if enemyx<playerX then enemyX++
if enemyx > playerx then enemyx--

etc..