# Enemy AI

6 replies to this topic

### #1 Random TerrainONLINE

Random Terrain

Visual batari Basic User

• 26,270 posts
• Controlled Randomness Replay Value Nonlinear
• Location:North Carolina (USA)

Posted Thu Mar 17, 2011 9:49 AM

I created this thread so it can be linked to from the bB page. Please post your Enemy AI tips here so they can help current and future users of batari Basic.

Thanks.

### #2 AlbertOFFLINE

Albert

The Factory

• 31,404 posts
• Location:Sweatshop

Posted Thu Mar 17, 2011 10:02 AM

I thought this said "Enemy Al" and I was a bit concerned.

..Al

### #3 Random TerrainONLINE

Random Terrain

Visual batari Basic User

• Topic Starter
• 26,270 posts
• Controlled Randomness Replay Value Nonlinear
• Location:North Carolina (USA)

Posted Thu Mar 17, 2011 10:10 AM

I thought this said "Enemy Al" and I was a bit concerned.

..Al

The dangers of not using Verdana as the default font on a message board.

### #4 RybagsOFFLINE

Rybags

• 13,523 posts
• Location:Australia

Posted Thu Mar 17, 2011 10:13 AM

Repost by request from the other recent thread:

Quite a lot of old game logic is just a mix of randomness and "seek player" type of thing. Obviously a game will usually be too hard if the enemy constantly heads for the player, so you can do stuff like only change direction periodically, and make that direction change a mix of randomness and seeking.

Then you have the arcade Pac-Man "Head him off at the pass" philosophy - don't necessarily head for the player, head for a position that's near where the player is.

And you have Asteroids Deluxe "prediction" logic where the enemy saucer will sometimes shoot at a position where the player is anticipated to be if he keeps moving at current speed/direction.

So, for a simple algorithm for an enemy you might have a few variables that you periodically change:

Timer - this counts down and at zero you load a new timer value, which can be random. When the timer hits zero, you then make a decision to change other variables.
Velocity X/Y- dictates direction and speed of an enemy. This changes when enemy hits a boundary, obstacle, or timer counts down. You can decide randomly whether the new value is random, or is set to a strategic value based on "seeking".

Randomness - a threshold value that dictates what percentage of an enemies behaviour is random and how much it's based on strategic seeking.

On top of that, you might also have set paths that are followed and broken on certain conditions, e.g. randomly, or if the player wanders within a certain range.

To add a little further info - you might also have trigger points where a player might pass, and they can be used to alter the way a particular enemy/s behave.

### #5 man vs. 2600OFFLINE

man vs. 2600

Combat Commando

• 8 posts

Posted Wed Apr 20, 2011 5:43 PM

I was playing around with some really basic enemy AI today and built a small enemy wanders around on his own program that includes some collision detection based on parts from move_around_rooms. Hope this is useful.

### #6 theloonOFFLINE

theloon

• 8,110 posts

Posted Fri Apr 22, 2011 10:22 AM

I've learned it's handy to incorporate a "stuck" routine in my enemy AI. Sometimes just heading toward a player will leave the critter just banging into the same wall. I increment a variable every turn the monster stays stuck in one location. When a certain threshold is reached I tell the monster to move in a new direction or change behavior.

Edited by theloon, Fri Apr 22, 2011 10:23 AM.

### #7 Atarius MaximusOFFLINE

Atarius Maximus

Stargunner

• 1,662 posts
• Location:St. Louis, Missouri USA

Posted Fri Nov 18, 2011 12:25 PM

This is my first attempt at writing an Enemy AI routine. It's not absolutely perfect, but it works fairly well. The enemy will always follow the player until it hits a wall. If it gets stuck on a wall for too long, it will choose a random alternate path to try and get around the obstacle. The demo has a player sprite you control and an enemy sprite that will follow you. If you stay still for long enough, the enemy will eventually find his way to you.

The biggest area this could be improved would be the logic used when the enemy chooses a different path. It's completely random right now, but checking the current position of the player and heading in that general direction would make it better. The problem is that heading directly to the player isn't always the best path to take. It would be easier to code it if the playfield was always static, but I was looking to do something that would work with any playfield configuration.

Putting in a very complex playfield would probably make this sample code much less effective. The distance traveled when an alternate path is chosen would have to be tweaked, as well as how many turns are taken and how long that routine runs before switching back to the simple "head towards the player" movement. I'll post again when I've had more time to work on it, but I wanted to share what I have so far.

Any thoughts, comments or suggestions would be appreciated.

Steve

#### 0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users