Post by JimBoReee in Lil Programming Questions

Viewing post in Lil Programming Questions

I want to make an isometric game in Decker. I'm able to make things move. But there are some places where I don't want to move beyond.

In other words, I want to have collision mechanics. How do I program that? I vaguely remember someone saying to use the Path module to text whether a patter is or is not to be moved into, but I don't know how that works. I tried looking into Sokoban, but I can't make heads nor tails of it and, after looking into its resources, cannot find anything on the mover module within it which might be able to help me, but I am not sure.

In all honesty, I don't even know where to start and could appreciate some pointers.

ahmwma7 days ago(+1)

This is not a complete answer, this is kind of just a gesture towards one. The actual complete answer will kind of depend on what's going on in your game, y'know? But I can point to a couple of things.

Here's some recent discussion of the sokoban example specifically: https://itch.io/post/16368974

And for the path module here's the card that has an example that gives a visual example of the forbidden color thing: https://beyondloom.com/decker/path.html#followeranim (click the checkbox at the bottom)

Some of the code for this is inside the module, not the deck's scripts but I believe it uses .hist to check parts of the movement grid for a specific color, and forbids movement onto that square of the grid if it finds any.

It should be possible to do something similar with a different kind of movement system too, if the path module itself doesn't have the kind of movement you had in mind.

JimBoReee7 days ago

Hm... I have an idea. In that I could have a bunch of canvases, shaped into a rough hexagonal shape, which I will call the "Player," like this:

And then have different canvasses act as, I don't know, geometry for the Player to "collide" with. Like this:

I theorize that I can use the Draggable module to collide with the other canvases.

Again, this is theory for me and probably labor intensive, but better than nothing, lol.

Screwtapello6 days ago(+1)

The thing is, “an isometric game” covers a lot of ground. Some isometric games are just regular top-down 2D games that happen to use sprites drawn from an isometric perspective, even though the games use normal rectangular hit-boxes for collision and movement (though I can’t think of a well-known example off the top of my head). Other isometric games (such as the original Diablo and Diablo II) have everything happen on a regular square grid, then they just draw the grid with isometric graphics. That way, game logic and collisions are still pretty straight-forward, but the game looks more interesting with more overlap than a regular 2D top-down view. Still other games use a real hexagonal grid, which makes logic and collisions more complicated in exchange for being mechanically isometric (the same cost to travel in any direction) as well as visually isometric (a thing looks the same size no matter which way it’s pointing).

Which of those seem the closest to what you want?