Good grid based movement

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
pete456
Prole
Posts: 1
Joined: Sun Jun 04, 2017 7:43 pm

Good grid based movement

Post by pete456 »

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
User avatar
zorg
Party member
Posts: 3468
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Good grid based movement

Post by zorg »

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.
Me and my stuff :3True 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.
User avatar
Nixola
Inner party member
Posts: 1949
Joined: Tue Dec 06, 2011 7:11 pm
Location: Italy

Re: Good grid based movement

Post by Nixola »

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
User avatar
Inny
Party member
Posts: 652
Joined: Fri Jan 30, 2009 3:41 am
Location: New York

Re: Good grid based movement

Post by Inny »

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.
User avatar
Nixola
Inner party member
Posts: 1949
Joined: Tue Dec 06, 2011 7:11 pm
Location: Italy

Re: Good grid based movement

Post by Nixola »

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
User avatar
DiegoG
Prole
Posts: 20
Joined: Sat Apr 29, 2017 2:43 am
Location: Venezuela

Re: Good grid based movement

Post by DiegoG »

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
User avatar
erasio
Party member
Posts: 118
Joined: Wed Mar 15, 2017 8:52 am
Location: Germany

Re: Good grid based movement

Post by erasio »

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.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 2 guests