Limit angle change while chasing target

[Jekyll Grim Payne]

I need to only let the monster turn within a limited angle every tic when it's chasing its target. I tried this:

Code: Select all

{
		A_Chase(null,null,CHF_NORANDOMTURN );
		if(target) {
			if (angleto(target) > angle)
				angle+=1;
			else if (angleto(target) < angle)
				angle-=1;'
			}
		}

But apparently A_Chase somehow interferes with my attempts to change the angle, when I removed it, the angle visibly changes. However, I'm not sure where to go from here. There is some inheret functionality in A_Chase that I'd like to keep. Also, I'm not completely sure what would be the best way to push the monster to simulate regular movement.

[Apeirogon]

Try to use a_wander with no turn option, and then turn monster in direction of it target.

[Jekyll Grim Payne]

Nope, the effect is the same. Apparently both functions reset the angle.

Code: Select all

	See:
		TNT1 A 0 A_Chase(null,null,CHF_DONTTURN );
		ZAA1 AAAAABBBBBCCCCCDDDDDEEEEEFFFFFGGGGGHHHHHIIIIIJJJJJKKKKKLLLLLMMMMMNNNNNOOOOOPPPPPQQQQQRRRRRSSSSSTTTTTUUUUUVVVVVWWWWWXXXXXYYYYYZZZZZ 1 
		{
			//console.printf("%f",angleto(target));
			if(target) {
				if (angleto(target) > angle)
					angle += 1;
				else if (angleto(target) < angle)
					angle -= 1;
				}
			}
		loop;

I tried this, and when A_Chase (or A_Wander) is called, the angle seems to be reset.

[Arctangent]

Something to keep in mind that A_Chase and A_Wander only allow moving in the cardinal and ordinal directions. This is because they don't care about the actor's angle at all, but rather move the actor based on its movedir variable. Which isn't an angle equivalent, but rather something that only has 8 valid values which correspond to those directions.

You're going to have to make you own movement code for something like this.

[Apeirogon]

Than look into total chaos mod. It have models for enemy which chase player with full 360 degree turns, IIRC.

[Jekyll Grim Payne]

For clairity, this is basically how I want the basic walking to look:

https://streamable.com/sobvk

Which I think is pretty close to most older RE games. Except in this case I simply used thrust:

Code: Select all

		ZAA1 AAAAABBBBBCCCCCDDDDDEEEEEFFFFFGGGGGHHHHHIIIIIJJJJJKKKKKLLLLLMMMMMNNNNNOOOOOPPPPPQQQQQRRRRRSSSSSTTTTTUUUUUVVVVVWWWWWXXXXXYYYYYZZZZZ 1 
		{
			thrust(0.1,angle);
			if(target) {
				if (angleto(target) > angle)
					angle += 1;
				else if (angleto(target) < angle)
					angle -= 1;
				}
			}
		loop;

So obviously I need to work pathfinding into it. Rewriting A_Chase it is, I guess?

[Arctangent]

Well, I mean, A_Chase doesn't have pathfinding, anyway. Doom monsters are basically just very angry pinballs that try to walk directly towards you to the best of their eight-directional abilities, but if something gets in their way then they just "bounce" off walls until they have a straight shot to you.

If you want pathfinding, you'll probably have to look up actual pathfinding algorithms to get anywhere.

[Jekyll Grim Payne]

I don't think you're right about A_Chase. I tested it on those zombies and observed (them being slow and 3D helped to observe better), and after bumping into an obstacle they clearly went around it to get to me. There's definitely some pathfinding, not just random walking around.

[phantombeta]

I don't think you're right about A_Chase. I tested it on those zombies and observed (them being slow and 3D helped to observe better), and after bumping into an obstacle they clearly went around it to get to me. There's definitely some pathfinding, not just random walking around.

No. Pathfinding requires actually being able to follow paths. Notice that if you go into a completely different room, it'll try to walk directly towards you instead of following the correct path to the next room.
What A_Chase does is extremely primitive, extremely limited obstacle avoidance. Pathfinding is part of an entity's AI, while obstacle avoidance (and other such movement related things) are part of an entity's movement code.

[Arctangent]

Something like this is a perfect illustration of exactly how dumb Doom monsters are:

dumbassesinacagethatisntevenacage.wad

(3.83 KiB) Downloaded 43 times

Notice how that, despite having multiple paths to the player, a demon will very rarely move past the wall while you're on the spawn pad, and only in extremely rare circumstances will it manage to do so without wandering around like an idiot for five minutes. As soon as you step in front of an opening, however, all of them will manage to get past the wall with basically zero difficulty.

They really do just bounce around the place until they get a straight shot to you, it's just that that makes a convincing enough illusion of pathfinding with certain kinds of geometry.

[Jekyll Grim Payne]

I don't know exactly what A_Chase does or doesn't do, but my point is, for _zombies_ it does enough. I need just obstacle avoidance, not some complex AI. Plus, since I'm planning it for a custom wad, I don't need a universal solution; most likely there will be a fixed number of enemies, maybe some patrol routes, specifically designed systems, etc. I don't need zombies to follow me into another room or anything like that. If I could implement just that, i.e. just chase with smooth angle change, it'd be enough for me. Sure, I guess proper pathfinding would be great, it could even have its uses, but I honestly don't even know where to start with it.

[Arctangent]

Eh, I think you're underestimating how much the fact that they can only move in 45-degree intervals is necessary to make A_Chase's movement "work." You've got this nice gradual turn effect going on currently, but going with A_Chase's method would mean that running in a wall would either result in jarring angle changes or the zombies getting stuck on the wall as they slowly tank control to another angle, which might just lead them into another wall.

It's just a very goofy way of moving around that only "works" because Doom monsters move in such underdetailed, cheat-y ways to begin with.

[Cherno]

I have a project that uses models for monsters, and I implemented a solution that retains the 8 cardinal direction movement and rotation, but the angle changes are not instant but rather smoothed over several tics so the model doesn't just snap to it's new angle, but rather visibly turns towards it. It involves using invisible actors for the monsters itself and visible actors as children that continously rotate towards the main actor's angle. Is this something you need, or do you really need a movement solution that also lets the monsters move and rotate in all directions?

[Jekyll Grim Payne]

Eh, I think you're underestimating how much the fact that they can only move in 45-degree intervals is necessary to make A_Chase's movement "work." You've got this nice gradual turn effect going on currently, but going with A_Chase's method would mean that running in a wall would either result in jarring angle changes or the zombies getting stuck on the wall as they slowly tank control to another angle, which might just lead them into another wall.

It's just a very goofy way of moving around that only "works" because Doom monsters move in such underdetailed, cheat-y ways to begin with.

OK, that's fair. My frustration comes from the fact that the angle of the model HAS to follow the actual angle of the actor. Like, I expected INTERPOLATEANGLES would do something about it, but no dice. Considering models are pretty relevant, it's just weird to me there's no out-of-the-box solution.

I have a project that uses models for monsters, and I implemented a solution that retains the 8 cardinal direction movement and rotation, but the angle changes are not instant but rather smoothed over several tics so the model doesn't just snap to it's new angle, but rather visibly turns towards it. It involves using invisible actors for the monsters itself and visible actors as children that continously rotate towards the main actor's angle. Is this something you need, or do you really need a movement solution that also lets the monsters move and rotate in all directions?

That's an interesting idea. However, my problem isn't only with the visuals, it's also with the fact that I actually don't want the monster to be able to turn that fast. You know how often in Resident Evil you can run past a zombie? Yes, sometimes they'll suddenly lunge at you, turning 90 or 180 degrees (which will be implemented by a separate state and animation), but a good amoung of times you can just run by and they won't be able to turn fast enough to attack you. I want to replicate that behavior too.

upd: Although.... I could try to limit the monster's ability to attack depending on the angle of the child actor with the model, not on the monster's own angle... I'll try that and report back. Thanks for the idea!

P.S. There are monsters such as the Tyrant/Mr. X that would require more advanced pathfinding, though...

Upd2:

Well, I'd say this looks decent: https://streamable.com/yil95

I'll have to tweak it a bit more and incorporate additional animations for long turns though, but it's something

[DnB-Freak]

Upd2:

Well, I'd say this looks decent: https://streamable.com/yil95

I'll have to tweak it a bit more and incorporate additional animations for long turns though, but it's something

I'd guess I'm late posting this, whatever... I've messed around with ZScript to figure out A_Chase turning limits too.
This looks like a solution to me too (I'm using MD3-models & ZScript), can you share the code for the recent one please?