LÖVE

I will give a shiny Stanley Nickel to the first person who converts LuaStar to use Coroutines so I can have my characters think about their paths without pausing the execution of the game for half a second.

Jasoco wrote:I will give a shiny Stanley Nickel to the first person who converts LuaStar to use Coroutines so I can have my characters think about their paths without pausing the execution of the game for half a second.

Here's my personal implementation of A*: https://github.com/inmatarian/landofway ... finder.lua
Of course, it'll undergo massive tweaking as I work on this project. Anyway, line 99 is the code you're interested in.
Here's a mob that uses it: https://github.com/inmatarian/landofway ... nenemy.lua

Thanks! After a bit of work I have something working.

I am a bit surprised though. I notice your path is returned as a string of directions. N, S, E, W instead of a table of X and Y values. Any reason for this? Not that it matters. This actually could work in my favor. Haven't decided whether I'll convert it to an X, Y table version or keep the directions. I do need to do more testing to see how it holds up and if there's any delay while running my game with a dozen enemies all making decisions at once.

Having some success, but also encountering a really strange bug where my enemy object will stop halfway through following its path. It's very strange. I had one where I made 100 enemies and 90 of them stopped and refused to move. Is there a limit to how many coroutines can be running? Am I jamming this too full?

I can't see why though since they freeze after they've already generated the path and have started following it. So weird.

Bottom line is I haven't had any slowdown while all of them choose paths. But my grid is only 21x14 tiles. I'll have to test it out with a grid much larger.

The underlying objects move on a fixed grid. I came from the ZZT/MZX background (I was inmate2993) and the project is heavily influenced by it, so NSWE directions are how I designed everything. The A* engine was built in the same mindset.

I'm not sure what your bug is, but if you pulled code from the DragonEnemy, he's cutting down the path to a part of itself. Since the player is actively moving, the enemy is only using A* to get around obstacles and return to attacking, not to touch the player. In fact, one of the places I need to upgrade the A* is to allow a good enough path when it can't find the best path.

A simpler demonstration of my A* engine is this sprite: https://github.com/inmatarian/landofway ... rhardt.lua
On line 24, he gets the path and then immediately follows it.

Still working on bug shooting but I modified the pathfinder so instead of returning the path, it applies the path to the enemy object from within itself immediately after it builds the table of directions. I know that's not the problem because I made it work this way after having the problem to try and fix it. I'll figure it out. It's weird and probably a silly oversight on my end. I doubt it's the pathfinding since they usually freeze halfway through following a path. So it's probably a bug in my own following code. Weird though because even if I have only 2 enemy objects, eventually one of them gets stuck while the other never seems to. Need to do more analyzing.

Edit: Well I'm silly. I wasn't even creating a coroutine to put the pathfinding function in. Not that that has anything to do with my problem. It just proves the bug has nothing to do with coroutines. lololol

Jasoco wrote: ↑Thu Mar 22, 2012 4:03 am

Code: Select all

function love.update(dt)
    coroutine.yield(co)
end

btw, this should be

10 years later...

Ahhh, now I understand the foolishness of necro-ing.

Edit: But at least it clears confusion for anyone seeing the thread now

ReFreezed wrote: ↑Sat Sep 17, 2022 7:17 pm 10 years later...

i mean, better late then never, huh?