This page is a mirror of Tepples' nesdev forum mirror (URL TBD).

Erratic enemy movement?

I’ve been having some trouble visualizing how to make enemies move in a way that’s “erratic”, but not completely obviously random. Particularly among flying / airborne enemies.

Some examples of movements similar to what I’m thinking of are things like the birds in the Airman / Crashman stages of Mega Man, and the dude from 8 Eye’s’s falcon (who I know isn’t an enemy, but the way he moves is still interesting.)

Does anyone have a general idea of how movement like this is done? Is it all just lookup tables? Trig-based?
pick random direction, pick random duration. Move that direction for that long. Loop.
Have an array of patterns. Pick a pattern randomly. Repeat.
Two things I could suggest:

1. Don't make random decisions every frame. Pick a random direction and make the enemy commit to it for many frames before making another decision. This interval could be randomized as well.

2. Make smooth / filtered movement by controlling acceleration rather than velocity. Like how velocity adds to position each frame, you can add acceleration to velocity each frame as well. This extra step changes a straight line into a curve, which gives a very different impression of motion, but also may help the player anticipate the way it's going to move, because it can be seen turning in advance.

You can make a pseudo sine wave motion (e.g. Castlevania medusa head) simply by flipping the acceleration at a regular interval, maybe every 100 frames.

Edit: suggestion 1 was already given above while I was typing.
Oziphantom wrote:
pick random direction, pick random duration. Move that direction for that long. Loop.
I’m more or less doing this already with other enemies, but I still want there to be a sense that the enemy is moving towards the player. Maybe I can do the standard “if the player is to the left move left, etc.”, but add a bit of “noise” via the random variable.

rainwarrior wrote:
2. Make smooth / filtered movement by controlling acceleration rather than velocity. Like how velocity adds to position each frame, you can add acceleration to velocity each frame as well. This extra step changes a straight line into a curve, which gives a very different impression of motion, but also may help the player anticipate the way it's going to move, because it can be seen turning in advance.
Do you think it’s necessary to have sub-pixels for acceleration?
Sogona wrote:
Do you think it’s necessary to have sub-pixels for acceleration?

Definitely yes.
For reference, here's the enemy logic for the birds in Ninja Gaiden: http://tasvideos.org/GameResources/NES/ ... html#Birds
thefox wrote:
For reference, here's the enemy logic for the birds in Ninja Gaiden: http://tasvideos.org/GameResources/NES/ ... html#Birds
Thank you! I tried to disassemble what I think is the code in MM2 for the birds, but without a symbol list it was hard to understand any of it. And any RAM maps for the game I could find were pretty lacking.
Randomness in video game is a pretty huge subject, and you can probably find a lot of good resources out there (it's not specific for NES or old school games, after all). The general idea is that you decide on some kind of consistency in the way each enemy behaves, and let some of the factors be random.
The traditional one, usually applied to boss fights are what was already mentioned about having a bunch of set patterns and just choosing between them randomly. Another classic one could have a "patrolling" enemy that attacks the player when it gets near, aiming in the correct direction, but with a random deviance applied to the angle.
A similar effect is also typically seen in shooters with "spray patterns", where the attack feels predictable, but you still need to pay attention to the bullets in order to correctly dodge them.

For research, I recommend playing through Ghouls 'n Ghosts. Aside from the final stage, almost everything you encounter in that game is extremely random, but balanced in such a way that knowledge of the patterns will always help you be prepared with how to deal with them, and also in a way that ensures never running into completely unavoidable patterns, and maintaining a distinct identity of every type of enemy. It is one of the best examples of constant randomness in a video game ever created - barring abstract stuff like Tetris.
(for the record, SUPER GnG is a completely different game and doesn't do the same thing, in fact it's almost a complete opposite in that regard)

thefox wrote:
For reference, here's the enemy logic for the birds in Ninja Gaiden

The birds in Ninja Gaiden are 100% deterministic though.
Also, I've found that having "less than accurate" routines when it comes to calculating distances or angles makes behaviour feel more natural. Or something as simple as adding random idle states to enemis which pursue you, for example, specially when those enemies use acceleration.

Sometimes I use a very simple kind of enemy which will modify its acceleration depending on the position of the player: if the player is to the right, increase X acceleration up to a max, etc, but only if the player is "within range", using a somewhat unacurate distance calculation, and introducing random delays, that is, game frames where acceleration is left untouched for one of the axes. It looks great.
Just make sure that kind of behavior doesn't make the enemy too unpredictable, especially in situations where you need to dodge/attack it.

Like, imagine if it's coming right for you at a specific speed, and you prepare to jump over it, but just as it's getting close it randomly changes to a much slower speed, and you land on it on the way down.
That's the kind of stuff we usually call "hard for the wrong reasons".
In my case, max acceleration is low so enemies react slow to the player changes of position. It seems to work just fine, specially in platformers where the main character is much faster while jumping.
Sumez wrote:
For research, I recommend playing through Ghouls 'n Ghosts. Aside from the final stage, almost everything you encounter in that game is extremely random, but balanced in such a way that knowledge of the patterns will always help you be prepared with how to deal with them, and also in a way that ensures never running into completely unavoidable patterns, and maintaining a distinct identity of every type of enemy. It is one of the best examples of constant randomness in a video game ever created - barring abstract stuff like Tetris.
(for the record, SUPER GnG is a completely different game and doesn't do the same thing, in fact it's almost a complete opposite in that regard)

Yeah, I’m trying to give each enemy a distinct behavior. Translating ideas / flowcharts on paper into game code is the biggest challenge for me. It’s easy to just think “yeah, so this enemy can walk around randomly and stop occasionally while it’s idle, and when the player is nearby hover around and then attack him.” Actually thinking about how that would work code-wise is a completely different story.

It’s been years since I’ve played either version of Ghouls and Ghosts, but I’ll take a look at it. I feel like with side scrollers you have a lot more freedom to experiment with stuff like that than in a top-down zelda-like game, like what I’m currently working on. I probably should play through Zelda again too to see what type of things they did with enemies. It also seems like with flying enemies you can do more than with enemies that are typically on the ground.

For flying enemies, I was also thinking about trying polar coordinates to achieve some interesting flying patterns. Just having a variable for angle and radius. The only real issue with this is that you’d need subpixels for it to look good at all, and that’d make the look up table for conversion huge.
Sogona wrote:
For flying enemies, I was also thinking about trying polar coordinates to achieve some interesting flying patterns. Just having a variable for angle and radius. The only real issue with this is that you’d need subpixels for it to look good at all, and that’d make the look up table for conversion huge.

I don't understand why you'd need a huge lookup table for this.
You'd need maybe a 64-entry cosine table, but then you'd need to multiply that by the speed to get the rectangular velocity. An 8-bit by 8-bit multiply takes a scanline and a half unless you do it through a quarter square lookup table.
thefox wrote:
Sogona wrote:
For flying enemies, I was also thinking about trying polar coordinates to achieve some interesting flying patterns. Just having a variable for angle and radius. The only real issue with this is that you’d need subpixels for it to look good at all, and that’d make the look up table for conversion huge.

I don't understand why you'd need a huge lookup table for this.
You’re right, actually. I’d thought about it a while back and figured out I’d only need 64 values for 0-pi/2 radians and can combine sine and cosine since they’re essentially the same; like Tepples pointed out. I’d just forgotten about these tricks. And using 16-bit values for subpixel precision would only be 128 bytes. So I guess that isn’t too bad.

tepples wrote:
You'd need maybe a 64-entry cosine table, but then you'd need to multiply that by the speed to get the rectangular velocity. An 8-bit by 8-bit multiply takes a scanline and a half unless you do it through a quarter square lookup table.
I’d want speed and final cartesian positions to be 16-bit. I haven’t really looked into 6502 implementations for multiplication/division. Are there any 16*16->16 where the result is just rolled over if it exceeded 65,535? I’d guess this would take a bigger performance hit unless there are other tricks I don’t know about.

I also couldn’t decide if I wanted to just leave the screen coordinates as they were (leave (0,0) as the origin and have Y go downward as it increases) or add 128 to X and Y and then negate Y to try and “fake” cartesian space.