LÖVE

Like in a top down shooter games like enter the gungeon, nuclear throne, and other games like old Zeldas(except smarter movement), etc. Anyway to make that type of movement without boids and effectively (Pathfinding included)?

I've made games that used straight up x/y screen coordinates, games with tiles and my current game uses x,y within tiles!

They all have their purpose depending on the nature of the project.

What is common is the need to learn trigonometry and vector math (which is fun!).

I know vector math, just application is a problem. I can get a path with A - star or other methods and then simply move it based on velocity but that may cause objects to get stuck on some obstacle.

Very few games like that use pathfinding at all, it's not necessary. Nuclear Throne for sure is all just controlled-random movement. https://twitter.com/tha_rami/status/110 ... 52?lang=en

An in-between step could be to add raycasts to avoid walls and other obstacles. I've had good results using 4 raycasts that rotate to cover all angles. Just moving toward the target's last known position while avoiding walls makes for amazingly intelligent-looking movement.

To efficiently navigate into enclosed rooms, through mazes, etc., then sure, you'll need pathfinding for that. Can you show an example of how your objects are getting stuck? You'll probably need to keep the path in the center of your tiles or whatever navigation nodes you're using. And the smaller your characters are compared to the hallways, the easier it will be of course.

Hmmm, that's true. Nuclear throne just has the characters move randomly and also move back when you're too close. Nice insight.

The example is just general "blahblah" (?) code that I did a while back (and lost?) and was now thinking to do it again but with some more info on what others thought. I'll see if I can make it now. Thanks

Gunroar:Cannon() wrote: ↑Sun Jun 05, 2022 10:32 am I know vector math, just application is a problem. I can get a path with A - star or other methods and then simply move it based on velocity but that may cause objects to get stuck on some obstacle.

If you're properly using A* (or similar), why would it get stuck on an obstacle? o_O

milon wrote: ↑Mon Jun 06, 2022 6:32 pm
If you're properly using A* (or similar), why would it get stuck on an obstacle? o_O

Good question

Since it's not turn based I move the entity to the next tile in the path with velocity. But then at a turn the entity might get stuck (because it's focusing on the top left of the object), so I have to make it focus on the middle and do a bunch of other stuff like check if its been at the same tile for to long and recalculate (in case of other entity blocking it) or shove it in a free direction. It seems like it might work on paper but it kept on creating new problems where it got stuck.

I think in the end I got entities to move without being stuck that much but then I lost the advantage of steering behaviours (was trying to mix the two, and yes, the game/test case was in a maze like environment where they had to find the player).

So...Now I'm thinking of going on another adventure into this AI...steering...path finding...thing

I think I'm understanding the issue. Sounds like you need to know/consider the maximum width of the entity and use that in your A* implementation. It's been a while since I've played with A*, but I think you'd want to factor in the entity width when examining neighboring cells. IIRC, that's right before calculating the cell score and adding it to the open list. If the entity is too wide for that cell, don't even bother calculating a score; just put it on the closed list and move on.

EDIT - If you want to see a functional (crappy) A* implementation, check out my not-yet-abandoned JRPG attempt. All road building was A* pathfinding there. I still intent to revisit it someday, lol!

milon wrote: ↑Mon Jun 06, 2022 7:05 pm. IIRC, that's right before calculating the cell score and adding it to the open list. If the entity is too wide for that cell, don't even bother calculating a score; just put it on the closed list and move on.

Waoh, that's a neat idea, though I'll have to dig into the A* lib I use, but still, I'll try it out and check the example
Thanks

If its tiles i do the move first and then check for colliding, trick is to have the move temporary and scrap it when it collides.
You can also save the movement in a trail and jump back on collide, trails are cool for various stuff.

Do not use pathfinding libs. In real live gameplay they feel horrible. Enemies approaching you in a line or never doing something surprising is just lame.
Same for randomness sadly.
Best method i found is to have precalculated pathways like a tree. This allows for enemies to eg avoid you just to reappear from behind.