.Netterpillars: Artificial Intelligence and Sprites - Line of Sight
(Page 4 of 9 )
For games that use NPCs, a classical problem is how to discover whether the computer character can see the player or not. There are many different solutions to this problem, but possibly the simplest one is the line of sight algorithm. You can implement this in a few steps:
- Consider an NPC’s eyes as a point just in front of it. It will be “looking” in this direction.
- Using the techniques for calculating the distance between two points, which you saw in the previous chapter, calculate the distance between the NPC and the player’s character. If distance to the player is greater than a certain value (the “seeing distance”), the NPC can’t see the player, as shown in Figure 2-2.
If the distance is less than the seeing distance of the NPC, create an (invisible) object having the player character as the center and the NPC’s “eyes” as vertices.
Figure 2-2. The player (good guy) is outside the seeing distance of the NPC devil
Use one of the collision detection algorithms you saw in the previous chapter to calculate whether there’s a collision between this object and the NPC’s head. If so, it’s because the line of sight goes through the NPC’s head. The player is not in front of the NPC, so the NPC can’t see the player. Figure 2-3 illustrates this situation.
Figure 2-3. The player is behind the NPC, so it can't see the player.
If there’s no collision with the NPC’s head, calculate the collision among the created object and other game objects. If there’s no collision, there’re no obstacles between the player and the NPC, so the NPC can see the player. See Figure 2-4 for a graphical view of this last calculation.
Figure 2-4. The NPC tries to see the player.
Making NPCs “Hear” the Player
There’s a simple solution to making NPCs aware of player sounds: Every time the player makes a sound, the program must compute the distance (using the Pythagorean theorem, discussed in Chapter 1) from the player to the NPCs. Any NPC whose distance is less than a constant value (the “hearing distance”) would turn to look for the sound origin. After a while, if there are no further sounds and the NPC has not seen the player, the NPC returns to its previous activity (patrol, stand still, walk erratically, etc.).
It’s a common practice to have different hearing distances for different kinds of sounds: A gun shooting can be heard from a long distance, whereas the player must be really near to the NPC for it to hear his or her footsteps.
Path Finding
Like the line of sight problem, there are also many different algorithms to solve the problem of path finding. If you don’t know in advance how the game field will take shape, you could employ some of the following methods:
- Mark some “milestones” along the path the character is walking. If it hits an obstacle, return to the last milestone and try another way. This algo rithm is useful when you have labyrinths or tiled game fields.
- Use invisible “bumpers” around the game characters. The program checks for any collision with these invisible objects, and chooses a way according to the noncolliding paths. The game can create bumpers following the NPCs from different distances, in order to allow them to see remote obstacles.
- Create a line of sight between the current position and the destination position. If there are obstacles in the way, move the line of sight to one side until there’s no obstacle. Mark this point as a way point, and repeat the process between this point and the desired destination point.
If you know the game field, such as a fixed screen in an adventure game, some common approaches are as follows:
- Define fixed paths, so the player and the NPCs always walk over these paths.
- Define path boxes, where each part of the screen is defined as a box with some characteristics, including a list of reachable boxes from that area. When walking inside a box, the player and the NPCs have full freedom; when going to a place on screen that’s inside another box, have the player and NPCs walk to the junction point between the two boxes, and then to the desired point in the next box. This method provides a more flexible look and feel for the game, but the boxes must be well planned to avoid strange behaviors (like the NPC running in circles if all the boxes are connected). This is the approach used by LucasArts in the first three games of the Monkey Island series.
 This chapter is from Beginning .NET Game Programming in C# by Ellen Hatton et al. (Apress, 2004, ISBN: 1590593197). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Use Your Imagination >>
More ASP.NET Articles
More By Apress Publishing
