So when making AI for a game you don't want to make artificial intelligence so much as artificial stupidity. If the enemies have perfect knowledge it puts the player in a terrible position and can make the game incredibly hard. With MicRogue I needed to make enemies that the player could anticipate. I also allowed the enemies to move into dangerous positions. I had tested a couple different types of enemy AIs using a paper prototype system.
For this example I am going to use the Rat. It is the basic unit in the game and gives a good base that the other enemies are built on. In the picture below you can see how the Rat moves. Its able to move in the cardinal directions North, South, East, and West.
The first thing an enemy will do is calculate the linear distance from each new position to where the player is. It then saves them in order clockwise starting with North. so in the below example the rat has calculated all the distances to the player and saved them in order as 50, 32, 50, 64.
Any locations that have a wall or another monster in them are saved as a distance of 1000. The reason will become clear in a second.
The Rat then goes through the list and chooses the lowest number from the group, and moves in that direction. I could have created a much more robust pathfinding system using A* but the levels are rather small and this system works out rather well. No need using a bulldozer when a shovel will do.
The only problem that arose is when an enemy is met with two tiles with the same distance, as in the image below. The Rat would always select the East direction because that comes first in th order (North, East, South, West). The quick fix I added was adding a random decimal to each position. A small decimal would not effect the distances because of the small number, but it would break the tie between two positions with the same distance.
That about wraps it up. I use this system for most of the enemies. I mostly change the pattern which the enemies check for movement.
Have you implemented A* successfully before?
No. I have not had a reason to do that yet. I have made a few small seven day roguelikes. But for them I just used a flood fill path finding. It's not the fastest, but it was easy to do so I just use that. I usually make games with smaller play fields, so path finding ends up being pretty easy.
Well I implore you to take the time to learn it.
1)You learn a valuable skill you can implement into larger games and this is a perfect start.
2)With practice, It doesn't take long at all to make it from scratch (within a day)
3)The actor will run in and out of "cul de sacs" because of the score system (which is why you only have straight walls of two I'm guessing) so it hinders level variety.
I know your levels are small but your brain will thank you.
Policyalmanac.org my favorite tutorial
Yeah. I will eventually learn it when I need it for the game, but it didn't feel necessary for this one. The reason I only had straight walls was actually because of the gameplay. I didn't want the player to be able to get caught in a dead end, so I always gave the player little loops to move around. Originally the levels were completely open but I needed to add some columns for the player to hide around.
I will take a look at that tutorial though. Maybe I can mock up some A* this weekend.