Hello.
MOVETYPE_WALK On Non-Players is an engine feature that does exactly what it says it does, TomazQuake has it and it is nicely commented.
I was wondering how I would put this to use on monsters and bots?
Thank you.
MOVETYPE_WALK On Non-Players
-
Team Xlink
- Posts: 368
- Joined: Thu Jun 25, 2009 4:45 am
- Location: Michigan
Basically, give the monsters/bots MOVETYPE_WALK instead of step. Then move them by velocity instead of their engine movement code (i.e. rename walkmove and movetogoal etc in defs.qc, and then make your own velocity-based walkmove and movetogoal). It's not quite that simple, but that's the gist.
Monsters have movement code that basically changes their origin in tiny doses instead of giving them true velocity. It does some path-finding for them that will direct them around moderate obstacles, like a wall. If you change them to velocity, they won't have that automatic path-finding anymore. The greedy pathfinding algorithm (always move straight toward target) won't serve your monsters or bots very well, so I suggest solving this issue.
One possible solution is to have your monsters spawn an invisible and non-solid dummy that they use for pathfinding. Every 5-10 seconds or so they tell it to repath for them. The pathfinder entity then does a series of large (say, dist 50-100) movetogoals toward their target, using the engine code to automatically move toward the target around minor obstacles. Each time the pathfinder moves in a burst, it drops a waypoint for the monster that owns it to follow. The monster will tell its pathfinder to repath again when it runs out of waypoints, or its 5-10 seconds or so are up.
You'll want to tweak 2 distances as needed: burst distance and planning distance. The burst distance is how far between waypoints, and planning distance is how far overall the planning entity goes. For example, you could have a burst distance of 50 and a planning distance of 1000, so 20 bursts overall. These bursts might happen all in one frame (as long as that's not too slow, and all monsters don't do this all at once), or you could spread it over 20 frames.
That's one solution. Other people here may have better ideas.
The other problem with MOVETYPE_WALK on monsters is edges. If a monster decides to run straight at the player, it won't fall off cliffs with MOVETYPE_STEP because the auto-pathing code won't let it. Monsters therefore need a special monster jump trigger to get them to hop off ledges. With movetype walk, however, there is no such protection and monsters will regularly hurl themselves off cliffs that normally they wouldn't have had trouble with. If you use the pathing method above, you'll have less trouble with this because the pathing entity that is guiding the monster should not direct them to go over the ledge, but it won't be perfect.
Monsters will still go over cliffs in some situations:
1) If the player fires a rocket, monsters with movetype walk will be pushed and may go flying off a ledge. Movetype step monsters do not respond to damage velocity.
2) If the monster strafes or wanders a bit while following its pathfinder's route, it could go off an edge.
3) If the pathfinder burst distance is too wide, it may turn a corner in a single burst and tell the monster to go from waypoint A to B in a straight line that leads over a cliff corner edge.
Solutions:
1) Reduce monster flight distance in T_Damage to about 1/4th or nothing at all, depending on what you want players to be able to do.
2) Either never allow your monsters to strafe or deviate from their path, or add some sort of edge detection (i.e. my right-forward corner is hanging over an edge, better move away).
3) Test your pathfinder burst distance to make sure to minimize this problem, or even eliminate it.
Cliff edges are the bane of MOVETYPE_WALK AI because cliffs are so hard to detect and manage in Quake. Frikbots don't like lava levels for this reason unless they have excellent waypoints, and even then they face a disadvantage. Someone once pitted frikbot vs (I think) frogbot to prove frogbot was better... and can you guess which DM level they chose? The silly things people will do to win a pissing contest, eh? Poor frogbot community.
FrikaC has tackled most of these issues with amazing success in Frikbot. He and the frikbot code would be exceptionally good resources. Hopefully he'll notice this thread and correct me on any bad advice I give.
BTW, in case you're wondering, frikbots exploit a hack to let the bots masquerade as clients. This allows them to use movetype_walk without engine support.
I don't believe flying monsters will want to have MOVETYPE_WALK. You could do them as movetype fly, if you gave them a friction or otherwise told them to stop flying when they stop wanting to move. Otherwise they may be better with movetype step + flags & FL_FLY, using the engine monster move code. Not sure about swimming monsters using movetype walk, I don't remember if there were caveats.
Also I think movetype walk will basically turn the entity into a bar of soap that slides wildly all over the place unless you apply friction each frame.
All of this will get monsters behaving about as well as normal movetype step monsters, plus any good perkes of movetype walk. For a bot, you'll want to implement much more complex pathfinding to handle long-term planning too, since the monster code frankly isn't capable of that (it's just for mitigating small-medium obstacles, not navigating the level).
I hope that helps!
Monsters have movement code that basically changes their origin in tiny doses instead of giving them true velocity. It does some path-finding for them that will direct them around moderate obstacles, like a wall. If you change them to velocity, they won't have that automatic path-finding anymore. The greedy pathfinding algorithm (always move straight toward target) won't serve your monsters or bots very well, so I suggest solving this issue.
One possible solution is to have your monsters spawn an invisible and non-solid dummy that they use for pathfinding. Every 5-10 seconds or so they tell it to repath for them. The pathfinder entity then does a series of large (say, dist 50-100) movetogoals toward their target, using the engine code to automatically move toward the target around minor obstacles. Each time the pathfinder moves in a burst, it drops a waypoint for the monster that owns it to follow. The monster will tell its pathfinder to repath again when it runs out of waypoints, or its 5-10 seconds or so are up.
You'll want to tweak 2 distances as needed: burst distance and planning distance. The burst distance is how far between waypoints, and planning distance is how far overall the planning entity goes. For example, you could have a burst distance of 50 and a planning distance of 1000, so 20 bursts overall. These bursts might happen all in one frame (as long as that's not too slow, and all monsters don't do this all at once), or you could spread it over 20 frames.
Code: Select all
_________________
|
M . | P
__ . _|_ .
| . | | .
| . |__| .
| . . .
__| ___
|
|
The other problem with MOVETYPE_WALK on monsters is edges. If a monster decides to run straight at the player, it won't fall off cliffs with MOVETYPE_STEP because the auto-pathing code won't let it. Monsters therefore need a special monster jump trigger to get them to hop off ledges. With movetype walk, however, there is no such protection and monsters will regularly hurl themselves off cliffs that normally they wouldn't have had trouble with. If you use the pathing method above, you'll have less trouble with this because the pathing entity that is guiding the monster should not direct them to go over the ledge, but it won't be perfect.
Monsters will still go over cliffs in some situations:
1) If the player fires a rocket, monsters with movetype walk will be pushed and may go flying off a ledge. Movetype step monsters do not respond to damage velocity.
2) If the monster strafes or wanders a bit while following its pathfinder's route, it could go off an edge.
3) If the pathfinder burst distance is too wide, it may turn a corner in a single burst and tell the monster to go from waypoint A to B in a straight line that leads over a cliff corner edge.
Solutions:
1) Reduce monster flight distance in T_Damage to about 1/4th or nothing at all, depending on what you want players to be able to do.
2) Either never allow your monsters to strafe or deviate from their path, or add some sort of edge detection (i.e. my right-forward corner is hanging over an edge, better move away).
3) Test your pathfinder burst distance to make sure to minimize this problem, or even eliminate it.
Cliff edges are the bane of MOVETYPE_WALK AI because cliffs are so hard to detect and manage in Quake. Frikbots don't like lava levels for this reason unless they have excellent waypoints, and even then they face a disadvantage. Someone once pitted frikbot vs (I think) frogbot to prove frogbot was better... and can you guess which DM level they chose? The silly things people will do to win a pissing contest, eh? Poor frogbot community.
FrikaC has tackled most of these issues with amazing success in Frikbot. He and the frikbot code would be exceptionally good resources. Hopefully he'll notice this thread and correct me on any bad advice I give.
BTW, in case you're wondering, frikbots exploit a hack to let the bots masquerade as clients. This allows them to use movetype_walk without engine support.
I don't believe flying monsters will want to have MOVETYPE_WALK. You could do them as movetype fly, if you gave them a friction or otherwise told them to stop flying when they stop wanting to move.
Otherwise they may be better with movetype step + flags & FL_FLY, using the engine monster move code. Not sure about swimming monsters using movetype walk, I don't remember if there were caveats.Also I think movetype walk will basically turn the entity into a bar of soap that slides wildly all over the place unless you apply friction each frame.
All of this will get monsters behaving about as well as normal movetype step monsters, plus any good perkes of movetype walk. For a bot, you'll want to implement much more complex pathfinding to handle long-term planning too, since the monster code frankly isn't capable of that (it's just for mitigating small-medium obstacles, not navigating the level).
I hope that helps!
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
Another big annoyance with velocity-based monsters is turning corners, especially in tight areas. You'll need good 'steering' code or the monster will bump into corners and walls like a retard as he goes somewhere (i.e. overshoot a turn, hit the far wall and then come back and try again).
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Ha, imagine a fiend at full speed running at you. You flee around a corner and then it comes around, angry like a steam locomotive on ice, drifting in its old direction but focused on you.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Yeah, and another problem is their feet will rarely "stick" to the ground so it'll look like they're sliding around on ice... So if you really wanted good looking monster movement you need velocity, IK for the feet, AI-driven animation, and legs-tangled tripping.
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
lol
The turning corners thing can be solved with proper friction and a smaller dist between waypoints, I suspect. The legs issue is basically just like the player's feet. They move a bit on the floor during running because the framerate doesn't quite cover the movement by velocity. Hopefully not too bad though.
You know, my ferret grenades from (I think) Wazat or Void mod would love velocity code. They were meant to be clumsy as they slide/run along the floor. There's something to be said for their jittery monster movement code though.
The turning corners thing can be solved with proper friction and a smaller dist between waypoints, I suspect. The legs issue is basically just like the player's feet. They move a bit on the floor during running because the framerate doesn't quite cover the movement by velocity. Hopefully not too bad though.
You know, my ferret grenades from (I think) Wazat or Void mod would love velocity code. They were meant to be clumsy as they slide/run along the floor. There's something to be said for their jittery monster movement code though.
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.