Basic enemy movement where A* isn't really needed?

Newbie & Debugging Questions
#1

I’m working on a 2d platformer-space game and though i’ve dealt with A* pathfinding before, I feel like it might not really be needed for this game?

The design is sort of like the Mario turtles where they walk along a platform and I know how to do this, make them turn around etc but I also want them to attack the player at a certain distance. Are there any sort of path finding ways of doing this? Of course I don’t want them to walk through walls etc but it seems pointless to implement A* for only left to right movement

#2

When your enemy is “aligned” to a block (not in-between blocks), you could check the block left or right of it (depending on its direction) and check if there’s a dropoff. If so, turn around.

For your ranged attacking, you’ll have to be a bit more descriptive. We can’t really help you with “attack at certain distance”.

#3

Yeah sorry, it was a little sparse. So the enemies will attack with guns/laser blasters. I know how to deal with projectiles/etc that’s not an issue. The issue comes when the movement for the entity should change.

Ideally the movement should change when the player is within a certain radius to the enemy, the enemy should try to kill the player though not go through walls etc. Now, am I right in thinking that for left/right movement that A* is just too much work to implement. Maybe I should make the enemy move on the x axis at a speed depending on the player location and if it hits a wall then it stops movement

#4

This can be modeled as a state machine, as can many simple AI behaviors like this.

You don’t have to actually encode the problem as such, this is just pseudocode:
Obviously you could do things like parametrize Walking to both left and right with the same code, etc.


State WalkLeft
    if(isNear(PLAYER))
        state = Attacking
        break           // break out to different state
    if (walkable(LEFT)) // there is a block to the left, but not i.e. a wall
        walk(LEFT)      // go 1 step left
        // no state change, repeat this
    else
        state = WalkRight
        break

State WalkRight
    if(isNear(PLAYER))
        state = Attacking
        break
    if (walkable(RIGHT)) // there is a block to the right
        walk(RIGHT)      // go 1 step right
    else
        state = WalkLeft
        break

State Attacking
    // whatever
    // resume to WalkingXX state when player is dead or out of sight, etc.
#5

Why would they would through walls? They do have collision detection otherwise they would fall through the floor.

In mario whenever they hit a wall they just turn around. Which is simply:

always: keepMoving()
if (haveIActuallyMoved() == false) //meaning there is a wall
doFlip()

aaaand thats it

#6

Please don’t use state machines for AI.

http://gameprogrammingpatterns.com/contents.html

Read this book about programming patterns.

#7

Why not? They’re perfectly suited to this particular problem. Don’t over-complicate. Also don’t throw out classes of solutions on opinion.
I posted that book here. I’ve read it.

#8

The only things I could think off would be getting the absolute value of the player and enemy and go by that, while making sure that area does not pass through walls, or having an extra set of rectangles that stretch from the enemy ai to the player and serve as the range the AI could shoot. Again, you would have to be careful for the rectangles not to pass through tiles. A way I would do is just have a set variable for the width of said rectangle and while it is colliding with a wall tile subtract its width until it isn’t, and then adjust it by the amount it was subtracted by to align it back on the enemy. Vice-Versa for the other stuff. Heck, why not use BOTH the absolute value (Movement range) and the rectangles(projectile range)? But then again, I’m not experienced whatsoever in game development, so my way is probably horrifically inefficient.

#9

If line of sight matters, use raycasting. Cast a ray to the player, if it’s unbroken by tiles [first assuming the distance is under some threshold], then the enemy can see the player, and it should begin attacking.

#10

Why one should read that? In what particular section AI is talked? Why no state macines?

You argument is like saying God hates X. Read the Bible to learn the truth. Absolute zero information.

#11

It’s a bit confusing. The ‘State’ section talks about state machines, in the context of AI, even though the contents don’t mention AI at all.

#12

Lots of interesting ideas here! I particularly do like the state machine idea though it seems there is a little disagreement o.o raycasting also seems interesting! I might have to look into it(Though I was thinking of putting a circle around the enemy if the player enters that then it can attack). Raycasting could be useful for turrets behind walls! :slight_smile:

#13

I re-read the GPP chapter, all of the problems were either: (and none of them are specific to FSMs)

  • changing problem requirements, which will ruin your day regardless
  • boilerplate and complexity explosion caused by trying to stuff things into an object-oriented model
  • not understanding the definition and consequent limitations of an FSM

But wait, at the bottom:

[quote]This doesn’t mean finite state machines, pushdown automata, and other simple systems aren’t useful.
They’re a good modeling tool for certain kinds of problems. Finite state machines are useful when:

You have an entity whose behavior changes based on some internal state.
That state can be rigidly divided into one of a relatively small number of distinct options.
The entity responds to a series of inputs or events over time.
[/quote]
Does it match Sauron’s problem? Check, check, and triple check.

#14

That’s what I call dedication! Thank you very much Pizza (Everyone else as well) it’s really helped me to get some ideas about different AI behaviors and I really do like the idea of the state machine so I will likely try and implement something of that nature