Grid Movement

Find quick help here to get you started with Hollywood
Post Reply
oceanarts
Posts: 111
Joined: Mon May 27, 2024 10:42 pm

Grid Movement

Post by oceanarts »

Would this be a valid way to implement grid movement like the old-school rpg's?

Code: Select all

@VERSION 10,0

@DISPLAY{WIDTH = 800, HEIGHT = 600, MODE = "WINDOWED", TITLE = "Grid Movement", COLOR = #BLACK} 

CreateBrush(1, 16, 16, #GREEN)

ply_X = 384 ;Set initial X-position
ply_Y = 288 ; Set initial Y-position


Function p_UpdateScreen()

    Local leap = 16
    
    If IsKeyDown("LEFT") = True Then ply_X = ply_X - leap
    If IsKeyDown("RIGHT") = True Then ply_X = ply_X + leap
    If IsKeyDown("UP") = True Then ply_Y = ply_Y - leap
    If IsKeyDown("DOWN") = True Then ply_Y = ply_Y + leap

    DisplayBrush(1, ply_X, ply_Y)
    Wait (7)
EndFunction

Function p_DrawGrid()
    For Local x =  0 to 799 step 16
    Line(x, 0, x, 600, #MAROON)
    Next
    For Local y = 0 to 599 step 16
    Line(0, y, 800, y, #MAROON)
    Next
EndFunction

BeginDoubleBuffer()
EscapeQuit(True)
Repeat
    Cls(#BLACK)
    p_DrawGrid()
    p_UpdateScreen()
    Flip()
Forever
EndDoubleBuffer()
Or would it spell trouble later? How can I remove diagonal movement?
Development System : Imac G5, MorphOs 3.19
User avatar
jPV
Posts: 734
Joined: Sat Mar 26, 2016 10:44 am
Location: RNO
Contact:

Re: Grid Movement

Post by jPV »

I would keep the game logic as single unit grid (1x1 pixels basically), then you can have a simple table that contains what's on every block in the game and make calculations with in (when you implement more complex stuff like finding paths etc.). Movement or checking what's on the next block would then be simple -1/+1 operations. Then a renderer function can scale the output to any resolution you want.

To remove the diagonal movement, use ElseIf:s or Switch-Case (instead of separate If:s) to accept only one key press at the time?
oceanarts
Posts: 111
Joined: Mon May 27, 2024 10:42 pm

Re: Grid Movement

Post by oceanarts »

jPV wrote: Mon Jul 28, 2025 6:24 am I would keep the game logic as single unit grid (1x1 pixels basically), then you can have a simple table that contains what's on every block in the game and make calculations with in (when you implement more complex stuff like finding paths etc.). Movement or checking what's on the next block would then be simple -1/+1 operations. Then a renderer function can scale the output to any resolution you want.

To remove the diagonal movement, use ElseIf:s or Switch-Case (instead of separate If:s) to accept only one key press at the time?
Ah! So what you're saying is that there's no need for a 1:1 scale between logic and visual representation. I never thought of it like that. Brilliant!
Development System : Imac G5, MorphOs 3.19
Bugala
Posts: 1390
Joined: Sun Feb 14, 2010 7:11 pm

Re: Grid Movement

Post by Bugala »

This also gives you a possibility of changing things on the fly.

That say you have 32x32 grid, and player is at location 10, 5

If you now want to use 16x16 grids, you will then use:

Code: Select all

Function DisplayPlayer(X, Y)
	XToUse = X * Leap
	YToUse = Y * Leap
	DisplayBrush(PlayerBrush, XToUse, YToUse)
EndFunction

Leap = 16
DisplayPlayer(Player.X, Player.Y)
Or if you then want to Unzoom for example, making grids become 8 x 8, then you simply change Leap = 8 instead, and all works the same.

Although there are situations where hardcoded numbers are good, by default try to avoid any hardcoded numbers, but always try to use variables (changeable numbers) instead, so that you can change them afterwards.
Post Reply