# Is there any competent Zombie AI?

Show 40 post(s) from this thread on one page
Page 1 of 4 1 2 3 ... Last
• 20th February 2020, 10:00 AM
Outcast
Is there any competent Zombie AI?
For my next game I want to make a zombie game so of course I need to have a Zombie AI. I have never done an AI of this sort though so I am trying to find examples on how to do it. I have looked at some examples and bought a couple on the clicker store, but all of them have serious flaws that would not make them quite the quality for a proper game that is sold on Steam etc.

Most importantly I need a zombie AI that make the zombies able to get around walls without trying to "push" their way through the wall and slide a long it until they reach an exit. They should be dumb (they are zombies), but still be able to traverse around the environment.

Have anyone dibbled in this and know if there is any competent zombie AI examples out there or what would be the best steps to try to create one? Are some extensions essential if trying to do such a task?
• 20th February 2020, 03:42 PM
Dex
Hi Outcast.

Yes I have dont a lot of AI in the past....and there is an easy way to do it...But remember AI is always designed around the need of the game (ISO, 3D, 2D, Top Down, etc etc)

Instead of using collision detection (IE: the slide-around-it thing you mention) you can use a much older method, but one that still works perfectly.

All you do is to map out your ground area and the obstacles, and simply save it as a binary.
So as an example....Here is a 9 by 3 play area:

123456789
000000000----1
000010000----2
000000000----3

What you would then do is to keep track of your zombie and what area it is in.
So in the above example, lets say your zombie is at position 3,2 then he ( X ) would be here:

123456789
000000000----1
00X010000----2
000000000----3

When your zombie gets to 3,3, he will be next to the obstacle, so you can then give him a random direction to move (up or down) to get around it. You then move the zombie in that direction and so avoid the obstacle.

Yes it does mean you have to add a few variables (counters) to your game, but once you have it working, then you will find that your zombie can home-in on the player and totally avoid the obstacles without a problem.

If you want I can make you a very simple example to help you...but I may have to post it tomorrow as im busy today. :)
• 21st February 2020, 04:40 AM
Volnaiskra
I'm in the process of making AI for my game, so I'm also very interested in seeing what suggestions people have. I think environment navigation is just one part of the problem (albeit probably the most fundamental part). Even for a dumb enemy like a zombie, I think you probably need to factor in quite a lot of things before they feel believable (ie. the zombies seem dumb rather than the game seeming dumb). Here are some I think would be useful:

-keep track of distance to player and only chase player if at a reasonable distance
-keep track of line of sight and only chase player if appropriate
-detect holes/inaccessible terrain in between player and enemy and don't bother chasing if player can't actually be reached.
-if enemy has a 'frenzied' state when chasing player, include some sort of cooldown timer so that enemy isn't frenzied forever
-include some basic geometry/algebra in chasing routine so that enemy doesn't just run to where player is but to where player is likely going (eg. if enemy is at 9o'clock and player is at 3o'clock but moving south, enemy should move not east but southeast)
-include some basic record of enemy's recent movement patterns, so that if they have been going around in circles or bouncing between two points for a long time, they'll try something new to break out of the pattern*
-include some occasional check to see if enemy is stuck in a wall or glitching out some other way, with some strategy for fixing them up (eg. moving them X pixels away from the wall until they get unstuck)
-some kind of randomised 'personality type' or some such thing that tries to make different enemies behave slightly differently, so that the player doesn't end up being like the Pied Piper with a conga line of automatons following him around all in exactly the same way

* Here's an issue I recently found that I hadn't expected at the planning stage, but that became immediately apparent once testing began (I imagine many more issues like it will surface eventually). Some of my enemies can jump onto ceilings and move on them. So I had their movement set like this:
-they move along a ceiling until they get to an edge
-once at the edge, they test to see if they can safely drop down to a nearby ledge
-if not, they turn around.

But then you get a situation like this where the enemy gets stuck in a loop on a ceiling, because it only checks for dropping points when it's at an edge, but the only safe dropping point occurs away from the edges:

https://media.giphy.com/media/YP1ZRI...Sk6t/giphy.gif

So my solution was to keep track of how many times it hits ceiling edges consecutively, and force it to look for a dropping point once it hits a certain amount of them:

https://media.giphy.com/media/duu6TX...tU6P/giphy.gif
• 21st February 2020, 09:37 AM
Outcast
Quote:

Originally Posted by Dex

I am considering between ISO and complete top down, but I think I will go for the complete top down since it would simplify things a lot I imagine and this is a completely new genre for me to tackle in many other areas (like with the AI), I think it would be easier with top down, not the least with graphics and animations for characters with having to just have a top down sprite instead of a 8 direction sprite from all angels. I have not fully decided yet though since I find that making graphics for objects from a completely top down perspective is a little tricky in its own right since it is quite an odd angle to see things from and many things look very "strange" from a complete top down perspective.

If you would like to make an example of your method I would gladly try it :)

Quote:

Originally Posted by Volnaiskra
]

Happy to see that Spryke is still going forward :)

I can imagine that making AI is a sure way to get a lot of unexpected results and problems to overcome in ways that no other area of development has!

One other area I am a little worried about is how performance heavy AI could potentially become, especially if having like 100 zombies. I even toyed with the idea of wanting to have the whole map be active and "moving" in real time all the time, so like zombies that are way far away from you are still moving around, I like that sort of persistance in games where not everything is just happening right around the player and everything else is "freezed" or just an "illusion", even if it is in practice "pointless" in a way. But I imagine that would make it even more performance heavy.
• 21st February 2020, 11:44 AM
MuddyMole
What you're talking about is "collision avoidance" (that's the proper term to google), as opposed to true pathfinding.
Dex's method seems like it should work.

Alternatively, I remember seeing an example many years back, that used two detectors positioned in front of the zombie, at roughly 2 and 10 o'clock positions.
If only the 10 o'clock (left) detector overlaps an obstacle, rotate to the right (clockwise).
If only the 2 o'clock (right) detector overlaps an obstacle, rotate to the left (anti-clockwise).
If both detectors overlap an obstacle, pick a direction (clockwise or anticlockwise) and keep rotating in that direction until not overlapping a backdrop.
If neither detectors overlap an obstacle, rotate towards the player character.

It's very simple, but it does work - although it requires a bit of fine-tuning to get the best results.

I couldn't find the original file or forum post any more (might have been on The Daily Click?), so I've just put together a quick example to demonstrate the principle.

https://1drv.ms/u/s!Atq7cUIJ7uexnzNJ...-ZAjq?e=BbKNle
(arrow keys to move the player)

Obviously that's just the collision avoidance part - you still need to add in line-of-sight calculation (loads of example on the forums) and some behavioural states (searching, chasing, going to last known position, etc).
• 21st February 2020, 12:10 PM
Volnaiskra
Quote:

Originally Posted by Outcast
One other area I am a little worried about is how performance heavy AI could potentially become, especially if having like 100 zombies. I even toyed with the idea of wanting to have the whole map be active and "moving" in real time all the time, so like zombies that are way far away from you are still moving around, I like that sort of persistance in games where not everything is just happening right around the player and everything else is "freezed" or just an "illusion", even if it is in practice "pointless" in a way. But I imagine that would make it even more performance heavy.

I've been very concerned with this too, especially since overlap checks are so expensive. I've been mindful of performance/efficiency since the beginning, and so far I've been relieved to see that performance is very acceptable. I only check for collisions only every 2nd tick or so, and only basic collisions (eg. is a hole or wall present, is enemy on a slope); only if a hole or wall has been found do I check detailed collisions (how wide is the hole, how tall is the wall, must enemy adjust for slope etc.).

If you have the whole map active, I'm sure you can somehow simplify the AI for those zombies that are off-screen or far away from the player - maybe check them less often, or use basic XY calculations rather than actual overlap checks, and of course skip any animation/rotation stuff for zombies that aren't currently visible. I'm sure this is what many AAA games do - especially open-world ones. I'm pretty sure I've taken advantage of this recently when playing Borderlands 3: some enemy had glitched and disappeared - stuck in geometry or whatever - so I moved as far as I could to the other end of the room. When I came back, he was fixed...I'm assuming it's because his AI routines changed when I was far away, and were perhaps more forgiving of collisions, allowing him to return to where he was meant to be.
• 21st February 2020, 08:34 PM
Outcast
Quote:

Originally Posted by MuddyMole
Quote

Quote:

Originally Posted by Volnaiskra
Quote

Wow, that seems to actually work kind of good! (apart from the "zombie" being a bit "jittery" for some reason, but that might be curable?)

The only main concern with this I have is what Volnaiskra is also saying in that overlap checks are expensive so maybe it would be too performance heavy to do it this way with too many zombies?
• 21st February 2020, 09:35 PM
MuddyMole
Yes, fine collision checks are slow. On the other hand, bounding box collision detection should not be computationally expensive at all, so try disabling fine collision detection in the object properties.

Alternatively, there are two other routes you could go:

You could make the game grid-based, so collisions can be detected simply by looking up values from an array - Dex has suggested one way of doing that, but actually almost any method that works using the built in collision detection could be adapted to use an array instead (including the example I posted above).

You could make the game polygon-based, so collisions can be detected by calculating the intersections of lines. The maths is a bit more involved, but polygonal maps lend themselves really well to much more efficient pathfinding, line-of-sight checks, shadow-casting, etc and allow a more "free form" level design than is possible with a grid, so there are a lot of added bonuses.
• 22nd February 2020, 01:10 PM
Outcast
Quote:

Originally Posted by MuddyMole
Yes, fine collision checks are slow. On the other hand, bounding box collision detection should not be computationally expensive at all, so try disabling fine collision detection in the object properties.

Alternatively, there are two other routes you could go:

You could make the game grid-based, so collisions can be detected simply by looking up values from an array - Dex has suggested one way of doing that, but actually almost any method that works using the built in collision detection could be adapted to use an array instead (including the example I posted above).

You could make the game polygon-based, so collisions can be detected by calculating the intersections of lines. The maths is a bit more involved, but polygonal maps lend themselves really well to much more efficient pathfinding, line-of-sight checks, shadow-casting, etc and allow a more "free form" level design than is possible with a grid, so there are a lot of added bonuses.

Yes, I don't think I will go the grid-based route though, unless it is possible to have really tiny grids? I don't want the movement to be "locked" and moving like on a checkers board. With polygon based do you mean 3D?

Another route I have been considering is doing things with Box2D since that could possibly make for cool effects with zombies being able to move around furniture etc. I wonder if it would be possible to make a similair system that you had for traversing movement, but based on Box2D? Perhaps that would not be as performance heavy?

There was an example of a zombie game with Box2D that was kind of cool, even though the pathfinding on the zombies did not seem as good as in you example, but the source code seems to be gone :/

Also a video of the game: https://www.youtube.com/watch?v=hGnMUpXxnuM
• 22nd February 2020, 03:14 PM
MuddyMole
By "grid-based", I don't mean that the actual movement has to be grid-based - only that the map is grid-based. That way, a two-dimensional array can easily be used to label a grid space as either walkable or an obstacle. With a little more work, you could also implement simple shapes such as circles and 45 degree angled walls, to give you slightly more fine control. In terms of creating the graphics, designing maps, saving and loading map data etc, a grid-based system will be much easier as well. This is the way I would go, in your particular case, since it's also good for stuff like destructible terrain and movable barricades etc, which I'd guess you might want to include.

By "polygon-based", I don't mean 3D, although the vast majority of 3D games are polygon-based, and so very often use polygons in their pathfinding etc, because most of the groundwork is therefore already done. All I mean is that obstacles are defined only as a list of vertex (corner) positions, and the outline that they form - collisions can be tested for using just maths (involves intersecting line segments). This would be massively more work (to be honest, don't even bother unless you're very confident with geometry and vector maths), but would give the best looking and performing results - if you can avoid bugs...

https://i.imgur.com/9x7JBvg.png
On the left is a polygon-based pathfinding system I made (but never quite managed to iron out all the bugs in). The example on the right was designed as a polygon-based field-of-vision display, like in "Commandos : Behind Enemy Lines", but it could easily be used for lighting/shadows too. In both, the shape of the obstacles is defined only by a long string of successive vertex coordinates, stored in a list or an alterable string - the visible lines and numbered nodes are only there for debugging purposes, and are not used in any of the calculations at all.

Box2D is likely to be far more computationally expensive than any other alternative.
Show 40 post(s) from this thread on one page
Page 1 of 4 1 2 3 ... Last