I might just be blind, but I have looked everywhere. I need a way to create continous grid based movement, not https://love2d.org/wiki/Tutorial:Effici ... _Scrolling.
Thanks
Good grid based movement
- zorg
- Party member
- Posts: 3468
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Good grid based movement
Hi and welcome to the forums.
"Continuous movement" (pixel-based) and "Grid-based movement" (tile-based) are usually not implemented at the same time for the same object/entity, you're either snapped to the tiles or not (old bomberman games use a third method that's "in the middle"); if you could provide an already existing game as an example, we could guess what you actually are looking for.
"Continuous movement" (pixel-based) and "Grid-based movement" (tile-based) are usually not implemented at the same time for the same object/entity, you're either snapped to the tiles or not (old bomberman games use a third method that's "in the middle"); if you could provide an already existing game as an example, we could guess what you actually are looking for.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: Good grid based movement
I think he means tweened grid-based movement, like Pokémon.
lf = love.filesystem
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
Re: Good grid based movement
Pokemon works by having the next maps loaded up as the player approaches the boundary, but the functions to draw maps accepts offset values so that they can draw the next map. When the player moves outside one and onto the next, the current map and the next map switch, and then the new active map is initialized (sprites placed, etc), the player's relative position is changed, and all the bookkeeping is done.
In a sense, when the player moves from (20, 0) to (20, -1), the game quickly moves the player to (20, 63) and moves the active map from (0, 0) to (0, 64) and the other map from (0, -64) to (0, 0).
I'm pretty sure I remember the old gameboy color version would change palettes on some levels where this happened.
In a sense, when the player moves from (20, 0) to (20, -1), the game quickly moves the player to (20, 63) and moves the active map from (0, 0) to (0, 64) and the other map from (0, -64) to (0, 0).
I'm pretty sure I remember the old gameboy color version would change palettes on some levels where this happened.
Re: Good grid based movement
I think the question's about something much more basic, movement itself (gridlocked with tweening/animations).
lf = love.filesystem
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
Re: Good grid based movement
If you're asking about how to implement it, I'd suggest you take a look at a game I made (If you can decipher the ABSOLUTE MESS that is that code, mostly because of deadlines and lack of experience) called PAC-MATH; specifically check the game.lua file.
function earth:destroy()
00count=5000
00while count>0 do
0000lg.draw(explosion,math.random(0,600),math.random(0,800))
0000count=count-1
00end
00earth = nil
00print("Earth has been destroyed.")
end
00count=5000
00while count>0 do
0000lg.draw(explosion,math.random(0,600),math.random(0,800))
0000count=count-1
00end
00earth = nil
00print("Earth has been destroyed.")
end
Re: Good grid based movement
Someone on reddit had an issue with movement recently and posted his code. It's doing exactly that! Here's the pastebin!
The basic idea is to have two locations. The location on the grid and the location on the screen.
For gameplay you only modify the location on the grid. For rendering (drawing) you only use the screen location.
And during update you make the screen location move towards the grid location.
The basic idea is to have two locations. The location on the grid and the location on the screen.
For gameplay you only modify the location on the grid. For rendering (drawing) you only use the screen location.
And during update you make the screen location move towards the grid location.
Who is online
Users browsing this forum: Ahrefs [Bot] and 2 guests