Hi.

I'm making a very simple first person shooter with OpenGL, of course with some enemies.
I need to "animate" them, so that they move around the world and shoot when meet the player. In other words, I have to realize a simple AI.

I'm completely new with the argument, so I'm looking for a good tutorial (possibly a practical one, with some samples and code).
Note that I'm looking for a very simple solution. Enemies should only explore the world, even randomly, and fight the player.

What do you sugget?

Thanks.

Hello Antar3s,

Well, your description of the AI makes it sound simple, but I think it will be difficult to solve it simply.

Is your FPS 2D? (Is it like Wolfenstein 3D) Also, it's relevant if it's grid based, sector based, or if the geometry is open.
So, alright that part is important when solving the problem, but right now I can think of a procedure to gradually achieve what you're looking for.

1: Make a function, or multiple levels of functions, ultimately deciding whether an AI can "see" a given point in your world. Ex. ai::is_visible(point_in_space)
By this, you can have the still stationary AI's shoot you when you come into their FOV within a specific range.

2: Use a pathfinding algorithm coupled with some random plotting of waypoints to make the AI's decide where to go.
Test this by actually drawing the paths; edges and nodes represented by lines and other simple geometry.
Eventually with a the value of the cost function shown above. Lot's of work for just the pathfinding! I can recommend A*.
It's good to be able to add your own nodes while testing, to see if your applied A* actually works, and how it will act in a certain situation.

3: Allow the AI's to move, and implement reconsidering their path at regular intervals.
This could be demanding; make sure pathfinding nodes are not created and destroyed unless there's time for it. Allow AI's to use one anothers nodes and edges.

Remember to create debugging options so the AI's don't gun you down while testing.
Also, it's nice to be able to reposition AI's, turn them manually and disable their movement even when you test their ability to move.
-Fat the bots suddently choses a bad path, and you can't stop it to see why.

If you don't want to have them follow an invisible player (as in where the player was last seen),
and the exploration doesn't need to be actual exploration but more like wandering around, you can skip the A* and pathfinding step completely
and just let them follow single nodes instead.

It's sad but I don't really know any good tutorials. Although a quick search revealed:

Pierre-Marie's navmesh tutorial, applied to HL but may still be useful
A* on Wikipedia

EDIT: Fixed typo

[Edited by - SuperVGA on November 17, 2010 5:50:34 AM]

With any AI project it's important to first recognize that it are in fact lots of different components that will make the games AI each will take advantage of and utilize different techniques.

I'd first break down you AI into different tasks that it needs to perform each of those will be a different component. You can expend those tasks and new ones as you go along and want to make the AI more complex and powerful.

For your purposes you have 3 tasks you need the AI to perform.
1 - Decide Action
2 - Shoot Player
3 - Explore

1 - The decision engine in this case is probably easiest done using fuzzy logic. You'll have two IF Statements:
IF Can See Player THEN Attack
IF Can't See Player THEN Explore

2 - The Attack task will probably just be shoot player.

3 - The Explore task can be as simple as move to random adjacent empty space.

Once you have that all in place and working you can start adding to it and expending on the different tasks.

For example:
- Giving enemies multiple weapons and adding rules to decide which one to use.
- Adding a move to assist task. That when an enemy is under attack causes nearby enemies to move to join the fight using A* path finding.
- Adding take cover and combat manoeuvring so then when attacking or being attack the enemies do more then stand there and shoot.

Quote: Pierre-Marie's navmesh tutorial, applied to HL but may still be useful

Amazing! :D

Thanks guy

Quote: Is your FPS 2D? (Is it like Wolfenstein 3D) Also, it's relevant if it's grid based, sector based, or if the geometry is open.

It's a sort of tile-based dungeon, with rooms and corridors generated randomly on a 2D map.

I think enemies could move "tile-per-tile", by deciding the direction to take (north, west, etc.), but I don't know if it's a good idea.
Probably a pathfinding algorithm like A* would be better...

Thanks for your help.

You might want to swing by www.aigamedev.com. A quick browse through the early AI Game Programming Wisdom books would probably offer lots of ideas as well.

The classic answer for simple FPS AI is to use a finite state machine. There are lots of things wrong with that approach, but if what you want is quick, simple, and easy to implement, then it's a good place to start.

The more current answer to simple FPS AI is to use a behavior tree. You can find lots of information on behavior trees at AIGameDev.

Quote: Original post by Antar3s

Quote: Is your FPS 2D? (Is it like Wolfenstein 3D) Also, it's relevant if it's grid based, sector based, or if the geometry is open.

It's a sort of tile-based dungeon, with rooms and corridors generated randomly on a 2D map.

I think enemies could move "tile-per-tile", by deciding the direction to take (north, west, etc.), but I don't know if it's a good idea.
Probably a pathfinding algorithm like A* would be better...

Hello again, i came to think of this thread from a while back.
If you're ok with having first person dungeon-crawler movement for your bots, that is.
Communist duck's roguelike AI
It's tile based. The monster movement can be animated between tiles.

Ok, thanks a lot.
I'm trying with A* and it seems a very good solution for my case.
Actually, I have to debug some code, but it should work well.

Now I'm thinking about the test to decide when a bot sees the player.
I prepared a boolean function, but I don't know how to define it.
What should I test?
I could take the distance between player and bot positions, but there could be a wall on the way, even when they are close enough to fight each other.
Is there a common way to solve this problem?

Thanks again.

Quote: Original post by Antar3s
Ok, thanks a lot.
I'm trying with A* and it seems a very good solution for my case.
Actually, I have to debug some code, but it should work well.

Now I'm thinking about the test to decide when a bot sees the player.
I prepared a boolean function, but I don't know how to define it.
What should I test?
I could take the distance between player and bot positions, but there could be a wall on the way, even when they are close enough to fight each other.
Is there a common way to solve this problem?

Thanks again.

Yes, the common way is a line-of-sight test, which is usually done by doing a "raycast" in your physic engine. Basically you cast a line from the AI's eyes position to one or several of the player's bodyparts, and check if it intersects anything. Its a costly test cpu-wise, so you dont want to do it every-frame for all of your bots.

An cheap, alternate solution in the case of a 2d game is to check if you can trace a straight line from the bot to the player on the navmesh...