# How can I make an AI agent avoid screen edges?

I'm programming an AI agent and I want them to avoid the screen edges. I've been considering using either the obstacle avoidance or the fleeing behaviour. Do either of these make sense?

How should I approach this?

First thing first, creatures should not avoid the "edges of the screen" because that is part of the View and not the actual Game Model. Game Entities should interact with the Game Model and not the View. The view is only the way you present the game to your game's players eyes.

Secondly, what you are asking of has little to do with Obstacle Avoidance steering behavior because these techniques were mostly designed to help finding a none-collision path through obstacles or avoiding moving obstacles (see this for more info).

It also should have little to do with fleeing because that is conceptually useful in building distance from moving creatures. If something is trying to get away from the edges of the screen as much as possible, it may just stay in the center of the screen.

## How to avoid the edges of the screen

If the game type is a brawler (beat'em up) or a platformer, you could make it so that if the distance from the camera is greater than Width / 2 on axis-x or Height / 2, on axis-y, the creature will move towards the camera until it is close enough. Alternatively if there are obstacles, the creature could find a path to some spot close enough to the camera and stop once it is near enough.

Normally a creature follows a path. Sometimes the path is generated with a path finding algorithm such as A*. Other times the path is picked in advance by the games' creators. If the path is picked in advance and the edges of the screen don't move, it could be selected so it doesn't move through obstacles or outside the edges of the screen.

If the path is created by a path finding algorithm, the edges of the screen could be marked as an impassable obstacle and avoided.

How close to an edge do we care about?

For a fairly thin threshold, avoiding the edges is quite closely approximated by finding the closest point on the edge and avoiding that:

For a thick threshold, it's a good approximation to just steer toward the center of the screen:

• I'm talking about a thin threshold, like in the first pic you posted from left to right. My idea was this: The agent constantly senses how close it is to the edge of the screen. If it's close enough, it applies Fleeing force from the edge, until it's once again far enough from the edge. I think it will create this screen-edge-avoiding behavior. Does this sound like a good idea? – Aviv Cohn Apr 18 '14 at 13:46
• Sounds great. That way, the agent won't care about the edges unless they're close. I recommend coding it up and playing with the parameters to get the effect you want. You're happy with implementing autonomous agents, right? – Anko Apr 18 '14 at 13:57
• Yes I can implement autonomous agents. Got a question about this: I'm implementing them using finite state machines, using the State design pattern (where each state is an object of class State). The behavior of the agent is entirely decided by the current state. So the current state is the one that will apply steering behaviors on the agent (makes sense?). So I have a question regarding this: the agents behavior should be affected by environmental factors (e.g. an enemy close by, etc). How can the current State object of the agent be aware of these game-world factors? – Aviv Cohn Apr 18 '14 at 16:31
• I had an idea how to do this, please say your opinion. Idea: Each agent will hold a reference to instance of the main class of the game (GameWorld or something). This class, in addition to more important stuff, holds references to all the entities in the game (divided into a uniform-grid for collision-detection performance). Each update, the current State object of the agent will contact the GameWorld instance, and see if any entities are near by. If they are, it will act appropriately using steering behaviors and such. Is this reasonable? Are games designed this way? Is there a better way? – Aviv Cohn Apr 18 '14 at 16:33
• @Prog All of what you've mentioned sounds sensible to me. It's only tangential to the topic of this question though; you should maybe ask it as another question altogether. – Anko Apr 19 '14 at 20:54