Page 1 of 1

AI Discussion

PostPosted: 20 Feb 2010, 17:15
by svenskmand
Regarding the AI, then although I have never participated in development of a game before, let alone AI development, I think that all we need is to maintain a all pairs shortest path for the map to do pathfinding, and then use a finite automaton with probabilities on its edges to represent each creature, where the probabilities change according to the creatures needs, which we also would store.

What do you think about that idea?

PS: I could try to formalize/explain the idea better and then post it here

Re: AI Discussion

PostPosted: 20 Feb 2010, 17:38
by andrewbuck
This is basically how the AI currently works, although the pathfinding is a bit different than you described. Paths are computed only when needed, this is done because, due to the digging, the game map is constantly changing meaning you would be constantly recomputing the "saved" paths. I plan to do some caching on this in the future to speed things up but it is not too bad right now.

As for the creature's decision making it works exactly as described. The creature basically has a stack of actions to carry out. When the creature is created the "idle" action is pushed onto the stack. Any more pressing stuff (digging tiles, attacking, etc) gets pushed onto the stack (what gets pushed is random and the probabilities change based on conditions). During a given turn, what the creature actually does is determined by the action currently sitting on the top of the stack. This allows complex actions to be broken down accordinly. For example if the creature has "attack" on the top of their stack they try to find an enemy to hit. If the nearest enemy is too far away they can push a walk action onto the top of the stack with an intended destination next to the enemy creature. Once they get there the walk action is popped off leaving the attack action now sitting at the top again, only this time the enemy is (hopefully) within range.

The stack is not "truly" a stack though since it is possible to peek at stuff below the action on top. This allows you to modify the top command slightly, e.g. if the action under the top "walk" action is "digTile" you can just walk there. However if the next action down is "attackCreature" you may need to keep changing the walk destination as the enemy creature moves around.

-Buck

Re: AI Discussion

PostPosted: 20 Feb 2010, 20:11
by svenskmand
Ok, but then why change it? Does it not work properly now or what?

By the way how large are the biggest game maps? 128x128 tiles or even bigger?

Re: AI Discussion

PostPosted: 20 Feb 2010, 21:11
by andrewbuck
There are absolutely no limitations on the size or shape of the map. It does not have to be rectangular, it can contain "holes" where there are no tiles, and it can have "islands" of tile that you cannot reach from any other portion of the map (unless you teleport there or something like that). It could also be modified during the game (i.e. adding new tiles as you dig near the edge, or deleting tiles somewhere else). This would mean that instead of having levels, you could just add on new sections of map after certain goals are met. I strongly dislike artificial limitations unless they are necessary to make the game do-able, however I have been able to work around all the normal restrictions on map shape without any major difficulty.

As for the AI, there isn't really a plan to change it. What i meant to say was that it is getting to the point where I cannot add much more to it and it will take an AI expert to make further significant contributions. Some of these contributions may mean a complete redesign of the structure of it but it is not "planned" at this point. I made a couple minor improvements to the claiming code today, however I just cannot make combat work decently and this is what is really holding up having a playable game.

-Buck

Re: AI Discussion

PostPosted: 20 Feb 2010, 21:32
by Bodsda
andrewbuck {l Wrote}:There are absolutely no limitations on the size or shape of the map. It does not have to be rectangular, it can contain "holes" where there are no tiles, and it can have "islands" of tile that you cannot reach from any other portion of the map (unless you teleport there or something like that). It could also be modified during the game (i.e. adding new tiles as you dig near the edge, or deleting tiles somewhere else). This would mean that instead of having levels, you could just add on new sections of map after certain goals are met. I strongly dislike artificial limitations unless they are necessary to make the game do-able, however I have been able to work around all the normal restrictions on map shape without any major difficulty.

As for the AI, there isn't really a plan to change it. What i meant to say was that it is getting to the point where I cannot add much more to it and it will take an AI expert to make further significant contributions. Some of these contributions may mean a complete redesign of the structure of it but it is not "planned" at this point. I made a couple minor improvements to the claiming code today, however I just cannot make combat work decently and this is what is really holding up having a playable game.

-Buck


Is it the combat AI that you are having issues with?

Bodsda

Re: AI Discussion

PostPosted: 20 Feb 2010, 22:01
by andrewbuck
Bodsda {l Wrote}:Is it the combat AI that you are having issues with?


Yes. I tried to do a field based approach which is what the Field class is for. Basically allied creatures are surrounded by a positive field, and enemies are negative. The closer you are to a given creature the stronger the field is. If you want a creature to "charge" you make them try to walk towards the negative field and to "retreat" you walk towards the more positive. Each creature calculates the field based on the allies and enemies it knows about (through sight, etc). This works pretty well and makes the fighters charge toward the enemies but when they get close they start... well... dancing, is the best way I can put it. They just oscillate back and forth whilst beating the crap out of eachother. Once one of them dies the survivor goes and finds someone else to kill and the "dances" with them.

The end result is a combat simulator that kind of works but very poorly. I think this is a good way to do it, and there are other games like OD which use a field based approach like this, but I am unable to get it to work decently. It basically just needs some love. :)

-Buck

Re: AI Discussion

PostPosted: 20 Feb 2010, 22:15
by Bodsda
andrewbuck {l Wrote}:
Bodsda {l Wrote}:Is it the combat AI that you are having issues with?


Yes. I tried to do a field based approach which is what the Field class is for. Basically allied creatures are surrounded by a positive field, and enemies are negative. The closer you are to a given creature the stronger the field is. If you want a creature to "charge" you make them try to walk towards the negative field and to "retreat" you walk towards the more positive. Each creature calculates the field based on the allies and enemies it knows about (through sight, etc). This works pretty well and makes the fighters charge toward the enemies but when they get close they start... well... dancing, is the best way I can put it. They just oscillate back and forth whilst beating the crap out of eachother. Once one of them dies the survivor goes and finds someone else to kill and the "dances" with them.

The end result is a combat simulator that kind of works but very poorly. I think this is a good way to do it, and there are other games like OD which use a field based approach like this, but I am unable to get it to work decently. It basically just needs some love. :)

-Buck


My initial thoughts are, why not break away from that function once the initial action is fulfilled, like this
{l Code}: {l Select All Code}
while
{
    if (doINeedToCharge)
        {
            while (!(nextToEnemy))
        {
            charge()
        }
        {
            if(targetInRange)
                {
                    attack()
                }
            else
                {
                    break
                }
        }
}


Ok, so my psuedocode is not great, but you get the idea. If hes in range, kick his ass, if hes not, go find his ass, then kick his ass. Basically, break out of your movement function when you get into a 'combat stance', check for target, if hes there, throw a punch then check if he is still there.

Obviously that is an overly simplified version of what your after, but I think breaking it off into a separate fight function would eliminate the pirouetting pets.

Bodsda

Re: AI Discussion

PostPosted: 20 Feb 2010, 22:24
by andrewbuck
Yeah, that is probably what I need to do. I'll try to work on that later today.

-Buck

Re: AI Discussion

PostPosted: 20 Feb 2010, 22:32
by Bodsda
andrewbuck {l Wrote}:Yeah, that is probably what I need to do. I'll try to work on that later today.

-Buck


I was also looking through your todo list. I think I might be able to implement a few of them, like the client colour selection and possibly the terminal 'load' command issue. Don;t know how helpful im being - its kinda daunting stepping through your code when I have little C++ experience, but hopefully this will increase my knowledge. I know if this was in python I could be hacking away happily for hours :)

Bodsda

Re: AI Discussion

PostPosted: 20 Feb 2010, 22:45
by andrewbuck
I think I may have already fixed the load thing, (make sure you are on the development branch in git). But feel free to hack away at anything you want to. If you want write access to the git repo I can set that up for you (if you don't already have it).

As for the client color selection I think I may have fixed that some time ago but I don't remember, there were several problems relating to that and I can't remember what I fixed and what I didn't.

-Buck

EDIT: By the way, I am on IRC today if you have any questions.

Re: AI Discussion

PostPosted: 20 Feb 2010, 23:05
by Bodsda
andrewbuck {l Wrote}:I think I may have already fixed the load thing, (make sure you are on the development branch in git). But feel free to hack away at anything you want to. If you want write access to the git repo I can set that up for you (if you don't already have it).

As for the client color selection I think I may have fixed that some time ago but I don't remember, there were several problems relating to that and I can't remember what I fixed and what I didn't.

-Buck

EDIT: By the way, I am on IRC today if you have any questions.


What network/channel?

I'll get the latest dev branch after the dist upgrade has finished

Bodsda

Re: AI Discussion

PostPosted: 20 Feb 2010, 23:09
by andrewbuck
The freegamer chatroom.

irc.freenode.net
#freegamer

-Buck

Re: AI Discussion

PostPosted: 20 Feb 2010, 23:19
by svenskmand
andrewbuck {l Wrote}:
Bodsda {l Wrote}:Is it the combat AI that you are having issues with?


Yes. I tried to do a field based approach which is what the Field class is for. Basically allied creatures are surrounded by a positive field, and enemies are negative. The closer you are to a given creature the stronger the field is. If you want a creature to "charge" you make them try to walk towards the negative field and to "retreat" you walk towards the more positive. Each creature calculates the field based on the allies and enemies it knows about (through sight, etc). This works pretty well and makes the fighters charge toward the enemies but when they get close they start... well... dancing, is the best way I can put it. They just oscillate back and forth whilst beating the crap out of eachother. Once one of them dies the survivor goes and finds someone else to kill and the "dances" with them.

The end result is a combat simulator that kind of works but very poorly. I think this is a good way to do it, and there are other games like OD which use a field based approach like this, but I am unable to get it to work decently. It basically just needs some love. :)

-Buck


As I am understanding you there is a field f at the place where the creature is standing, when the creature wants to charge f is less that some threshold t, so the creature seeks out the enemy, but when it reaches the enemy f is greater than t, and the creature runs away again. So why not just introduce t1 and t2 where t1 < t2, and then have the creature charge if f < t1, and run away if f > t2, then when t1 <= f <= t2 the creature can do other tasks, like attacking, this will also be perfect for creatures with range attack because you define a circular area with a circular part cut out, that is a projection of a torus into the plane.