Re: The epic love demo thread!
Posted: Mon Apr 13, 2009 12:34 pm
Second crack. This one is a little better as it attempts to weigh the costs between the X Axis and the Y Axis and move accordingly. The motion is a little smoother, however it still heavily biases towards one or the other. Part of me thinks that in order to do this right, I'm going to have to either invoke the physics engine (set an angle, set the impulse/force/whatever) or else I'm going to have to come up with an implementation of A* Path-finding algorithm. Or maybe just Dykstra's Algorithm...
If this isn't clear to you (I try to make my variables very human readable, but I still sometimes wind up with esoteric things) and you'd like more code commenting, please let me know.
Side Note: I couldn't find any sort of built-in function for making a negative number positive in Lua. Since we don't have a text console in Love and this is the only Lua implementation I have, I couldn't quickie test what one site told me I could do:
print( not -50 )
Known Issues:
When the big circle (the player sprite) matches up to the little circle (the cursor), it doesn't stop moving, it just sort of twitches. I'm not 100% sure what the deal is, but I may have to build in a "if we're within blah and blah, then set the X of the Player Sprite to the X of the Destination" type function.
Notes for the Future:
I'm thinking that in order to make it a much smoother progression, what I'm going to have to do is basically simplify the x/y axis costs and determine what the ratio is. Basically, if we've got 100 pixels to shift for X but 200 pixels to shift for Y, then for every 1 time we move X, we need to move Y twice (1:2). But if we're 100 away for X and 300 away for Y, for every time we move X, we need to move Y three times (1:3). If that makes any sense.
Code: Select all
--Move Directly To Function
--What the program does is determine which value in an X/Y array is higher.
--It then gives whichever axis has a higher value an extra movement turn
--on that pass.
function load()
mousePressed = false
gotoX = 0
gotoY = 0
playerBallX = 400
playerBallY = 300
speed = 1
end
function update(dt)
--Step 1: Get the values
local xAxisCost
local yAxisCost
local moveTokenX
local moveTokenY
if mousePressed == true then
if gotoX > playerBallX then
xAxisCost = gotoX - playerBallX
playerBallX = playerBallX + speed -- move the ball
moveTokenX = true
else
xAxisCost = makePositive((gotoX - playerBallX))
playerBallX = playerBallX - speed -- move the ball
moveTokenX = false
end
if gotoX == playerBallX then
xAxisCost = 0
end
if gotoY > playerBallY then
yAxisCost = gotoY - playerBallY
playerBallY = playerBallY + speed
moveTokenY = true
else
yAxisCost = makePositive((gotoY - playerBallY))
playerBallY = playerBallY - speed
moveTokenY = false
end
if gotoY == playerBallY then
yAxisCost = 0
end
if xAxisCost > yAxisCost then
if moveTokenX then
playerBallX = playerBallX + speed
else
playerBallX = playerBallX - speed
end
else
if moveTokenY then
playerBallY = playerBallY + speed
else
playerBallY = playerBallY - speed
end
end
end
end
function draw()
love.graphics.circle(1, gotoX, gotoY, 5)
love.graphics.circle(1, playerBallX, playerBallY, 20)
end
function mousereleased(x, y, button)
if button == love.mouse_left then
mousePressed = true
gotoX = x
gotoY = y
end
end
function makePositive ( negativeNumber )
local positiveNumber
positiveNumber = (negativeNumber * -1)
return positiveNumber
end
If this isn't clear to you (I try to make my variables very human readable, but I still sometimes wind up with esoteric things) and you'd like more code commenting, please let me know.
Side Note: I couldn't find any sort of built-in function for making a negative number positive in Lua. Since we don't have a text console in Love and this is the only Lua implementation I have, I couldn't quickie test what one site told me I could do:
print( not -50 )
Known Issues:
When the big circle (the player sprite) matches up to the little circle (the cursor), it doesn't stop moving, it just sort of twitches. I'm not 100% sure what the deal is, but I may have to build in a "if we're within blah and blah, then set the X of the Player Sprite to the X of the Destination" type function.
Notes for the Future:
I'm thinking that in order to make it a much smoother progression, what I'm going to have to do is basically simplify the x/y axis costs and determine what the ratio is. Basically, if we've got 100 pixels to shift for X but 200 pixels to shift for Y, then for every 1 time we move X, we need to move Y twice (1:2). But if we're 100 away for X and 300 away for Y, for every time we move X, we need to move Y three times (1:3). If that makes any sense.
But as was pointed out to me, math.abs does the same thing. I'd prefer built-in functionality over cobbled-together madness any day. But thank you for the response!
)
Made some small enhancements, hope you like them: