Physics navigation and other questions

[BlackPhoenix]

Hello all,

I'm a newbie in lua and Love but I have worked my way building a simple top down physics simulation, involving balls and immovable rectangles. I'm not a newbie in programming, I have used Box2d and SDL before but wanted something quicker and easier, so don't be afraid to get technical. I want to experiment with game ai and I am building a framework for that (don't ask me how physics crept into that, they just did somehow ...I want fluid motions and force-based combat not grids and stats after all ). I am however stuck.

- I decided to build a simple motion controller for my balls. I can use the setPosition() of the bodies to simply warp in from A to B but I want something better: I want a function acting as a motion controller, that accelerates the ball when it is away from the destination and then steadily slows it down to reach the spot. I eventually aim to combine that with the A* pathfinding TLpath library to effectively get around obstacles. Here's the problem: This controller function is recursive as it has to constantly refresh the body speed or forces applied to the body until a threshold is reached. It has to run in parallel with the physics simulation and has to share data with it so it can get the new positions of the body. Is this the "correct" way to go about it and if so, are lua threads suited for this purpose? I made a thread out of the function (with coroutine.create and resume) but it seems that it doesn't run in parallel with the rest...Do I also have to declare the rest as a thread? Putting a yield in there or explicitly running world:update() makes it sequential...I want it parallel goddammit

- Can I debug with breakpoints while testing with love?

- Is there a way to save the game state without a lot of fuss? Simply freeze the memory on a file and then reload it like hibernate on windows? I don't really care about save game filesize

- I noticed that Love has a problem drawing some png images... I made a 32x32 arrow png but love wouldn't show it. I went on to load love-ball.png and it was fine with it. I edited love-ball.png to an arrow and ta dah, it was drawn fine. Strange

- Last but not least: Is Love still actively developed? It seems things are a little slow...It would be a shame for such a pretty little framework to go dead

Thanks for bearing with me

[bartbes]

- I noticed that Love has a problem drawing some png images... I made a 32x32 arrow png but love wouldn't show it. I went on to load love-ball.png and it was fine with it. I edited love-ball.png to an arrow and ta dah, it was drawn fine. Strange

That's weird, are you sure you're not saving in some weird format?

- Last but not least: Is Love still actively developed? It seems things are a little slow...It would be a shame for such a pretty little framework to go dead

Of course it is! The 0.7.1 release wasn't that long ago! (About 2 months) Not releasing every week means we've got some stability, which is nice for a framework.

[Robin]

Also, 0.7.2 is in the works and many people are already using it.

- Can I debug with breakpoints while testing with love?

See debug.debug.

- Is there a way to save the game state without a lot of fuss? Simply freeze the memory on a file and then reload it like hibernate on windows? I don't really care about save game filesize

Tables can be serialised, which is a common solution for savefiles.

[vrld]

Is this the "correct" way to go about it and if so, are lua threads suited for this purpose?

There seems to be no one correct way to do things in Lua. But it's certainly one way to do it.

I made a thread out of the function (with coroutine.create and resume) but it seems that it doesn't run in parallel with the rest... Do I also have to declare the rest as a thread? Putting a yield in there or explicitly running world:update() makes it sequential...I want it parallel goddammit

Lua's coroutines are exactly that: routines that cooperate with each other. They can be the building blocks for user level threads, but you have to build the thread dispatcher yourself. Chapter 9 of the Lua book gives a good idea of what a coroutine is. Chapter 9.4 shows how to do non preemptive multithreading using coroutines.
If you want kernel level ("real") threads, you should have a look at love.thread.

Can I debug with breakpoints while testing with love?

Debugging in Lua is generally not that well developed as in other languages. There are some solutions, but I find none of them very useful.

Is there a way to save the game state without a lot of fuss?

No.

[BlackPhoenix]

That's weird, are you sure you're not saving in some weird format?

yep, basic png format from gimp. It may be because of the intel gma945 my laptop has...I found on the forum some guys had issues with it...Anyway I managed to get around that problem

Lua's coroutines are exactly that: routines that cooperate with each other. They can be the building blocks for user level threads, but you have to build the thread dispatcher yourself. Chapter 9 of the Lua book gives a good idea of what a coroutine is. Chapter 9.4 shows how to do non preemptive multithreading using coroutines.
If you want kernel level ("real") threads, you should have a look at love.thread.

I'm off to reading.

Thank you all for your quick replies. I managed to get my controller going, I don't know how it does it exactly but I bet whatever it's doing it's sequential. I'll go more in depth on lua concurrency, my most recent experience with threads was pthreads c api so at least I get a smoother learning curve

[ivan]

- I decided to build a simple motion controller for my balls. I can use the setPosition() of the bodies to simply warp in from A to B but I want something better: I want a function acting as a motion controller, that accelerates the ball when it is away from the destination and then steadily slows it down to reach the spot. I eventually aim to combine that with the A* pathfinding TLpath library to effectively get around obstacles.

I've programmed something similar although I decided to use behavioral trees instead of controllers (not too familiar with the controller design pattern).
Moving a body from one point to another is not that hard.
Just apply a force each frame in the direction of the target (while accounting for the effects of gravity)
Notice that Box2D is updated in intervals so the moving body will rarely align 'precisely' with the target position.
A simple workaround could be:

Code: Select all

local lvx, lvy = body->GetLinearVelocity ( )
local speed = math.sqrt ( lvx * lvx + lvy * lvy )
if speed * delta < distanceToTarget then
  body->SetPosition ( target )
end 

Following a path is a bit more complicated when physics are involved.
Since rigid bodies have a linear velocity you will need to slow them down gradually ahead of sharp turns (so that they remain within the 'spine' of the path).
This is somewhat complicated but there's an excellent book by Buckland that might help:
http://www.red3d.com/cwr/steer/PathFollow.html

Here's the problem: This controller function is recursive as it has to constantly refresh the body speed or forces applied to the body until a threshold is reached. It has to run in parallel with the physics simulation and has to share data with it so it can get the new positions of the body. Is this the "correct" way to go about it and if so, are lua threads suited for this purpose? I made a thread out of the function (with coroutine.create and resume) but it seems that it doesn't run in parallel with the rest...Do I also have to declare the rest as a thread? Putting a yield in there or explicitly running world:update() makes it sequential...I want it parallel goddammit

I think trying to use non-preemptive multitasking for this purpose will make your script super compilcated.
What's wrong with simply applying a force to the body at each frame?

- Can I debug with breakpoints while testing with love?

Yes, using Decoda
http://www.unknownworlds.com/decoda

[BlackPhoenix]

I've programmed something similar although I decided to use behavioral trees instead of controllers (not too familiar with the controller design pattern).
Moving a body from one point to another is not that hard.
Just apply a force each frame in the direction of the target (while accounting for the effects of gravity)
Notice that Box2D is updated in intervals so the moving body will rarely align 'precisely' with the target position.
A simple workaround could be:

Code: Select all

local lvx, lvy = body->GetLinearVelocity ( )
local speed = math.sqrt ( lvx * lvx + lvy * lvy )
if speed * delta < distanceToTarget then
  body->SetPosition ( target )
end 

Following a path is a bit more complicated when physics are involved.
Since rigid bodies have a linear velocity you will need to slow them down gradually ahead of sharp turns (so that they remain within the 'spine' of the path).
This is somewhat complicated but there's an excellent book by Buckland that might help:
http://www.red3d.com/cwr/steer/PathFollow.html

I used a similar setLinearVelocity(0,0) when distance < treshold.
I thought about path following, sharp turns and so on and decided to use a simple constant velocity solution, at least for now. Good thing with setLinearVelocity is that you don't have to worry about masses or even gravity plus you get forces applied on unfortunate bodies that get in your way! Maybe not as realistic but gets the job done.

I think trying to use non-preemptive multitasking for this purpose will make your script super compilcated.
What's wrong with simply applying a force to the body at each frame?

You're right. I realized that updating physics and running the motion controller aren't really two independent tasks that can run in parallel. Going that way would require locks, mutexes . I used -as it should be used- what I started with, coroutines, and right now I'm very happy with my code, it works without a hitch.

One quick lua question: Does coroutine.resume(co,arg1,arg2,...) passes the arguments to co, when co already exists (it has stopped due to yield)? I came over a behavior that can only be justified if resume passes args only at the 1st time it is called (starts execution).

[Taehl]

- I decided to build a simple motion controller for my balls.

<_<*

But anyway, best of luck. If you need help with TLpath, let me know.

[vrld]

One quick lua question: Does coroutine.resume(co,arg1,arg2,...) passes the arguments to co, when co already exists (it has stopped due to yield)? I came over a behavior that can only be justified if resume passes args only at the 1st time it is called (starts execution).

A useful facility in Lua is that a pair resume-yield can exchange data between them. The first resume, which has no corresponding yield waiting for it, passes its extra arguments as arguments to the coroutine main function:

Code: Select all

co = coroutine.create(function (a,b,c)
        print("co", a,b,c)
    end)
coroutine.resume(co, 1, 2, 3)    --> co  1  2  3

A call to resume returns, after the true that signals no errors, any arguments passed to the corresponding yield:

Code: Select all

co = coroutine.create(function (a,b)
        coroutine.yield(a + b, a - b)
    end)
print(coroutine.resume(co, 20, 10))  --> true  30  10

Symmetrically, yield returns any extra arguments passed to the corresponding resume:

Code: Select all

co = coroutine.create (function ()
        print("co", coroutine.yield())
    end)
coroutine.resume(co)
coroutine.resume(co, 4, 5)     --> co  4  5

Finally, when a coroutine ends, any values returned by its main function go to the corresponding resume:

Code: Select all

co = coroutine.create(function ()
        return 6, 7
    end)
print(coroutine.resume(co))   --> true  6  7

[Lafolie]

- I decided to build a simple motion controller for my balls.

<_<*

But anyway, best of luck. If you need help with TLpath, let me know.

I'm so glad I'm not the only person who read that in this way.