[Solved] Approaches for walking an arbitrary board square by square?

I am working in a board game where the board path is not square (as in Chess) neither linear (as in Monopoly or Snakes And Ladders).

The board is arbitrary (not random) and the player would move in any possible direction using arrow keys (Up, Down, Left or Right; 1 square per keypress). Ignore dice roll for now.

The board:

I experimented 2 approaches (expand for conclusions):

1. Assigning each block an Object Variable 'ID' and mapping the ID of adjacent blocks with Object Variables 'Up', 'Down', 'Left' and 'Right'. All manually, during level creation.

Pro: Freedom of blocks size and displacement, therefore freedom for level creation.
Con: Mapping gets cumbersome for large levels and latter addition of extra blocks make things messy.
(Better for design)

2. Using 4 sprites (hidden, permanently attached to the player) to use collision to detect the presence of blocks in the 4 directions. No manual mapping required.

Pro: No need to link blocks, therefore the freedom to add new blocks even in between existing ones.
Con: Blocks size and distance must be constant, reducing flexibility for level creation.
(Better for maintenance)

What else could I experiment with in order to chose the best approach for my game? I still plan to have NPCs moving around in turns by the way.


Could you mix 1 and 2 (four sprites on the tiles) at the beginning to assign possible moves of each tile?

Probably better, could you make a ghost go first to check if it collides with a tile, and move the pawn if it does?

1 Like

Thanks for the suggestions @Gruk!

That’s an interesting idea. Would the “level loading” state in the begin be worth it though? I guess that for a large level, it could be quite heavy processing. Perhaps, I could address it by having a large circular sprite (hidden, acting as my “field of view”) following the player, and map the blocks in collision with it which hasn’t been mapped yet. :thinking:Right?

I like the idea of the “ghost go”, it could be implemented with the “shooting view objects” approach of this old thread: How to make simple enemy AI (No zombie AI) - #13 by paulera. It also allows for modifying tiles availability on the fly (e.g. when a bridge is activated or a gate is open, I could remove the barrier blocking the “view objects” and new movements become possible). I am just not sure if this “view object” trajectory would cause glitches if too fast, or lag if too slow.

Only one way to find out :blush:

I created 4 points around the Player itself (DetectionUp, DetectionDown, DetectionRight and DetectionLeft) and tried to use Pick the Block that is nearest to DetectionUp to search for near Blocks.


I noticed that from a certain distance, objects are not considered “near” anymore:

Is there really a threshold for this condition, or could it be that I messed up something?

I don’t think there’s a threshold, but the tile on the left is closer than the one down, no? So that one is being picked (again).
You should use raycast in fact. And it will allow you to control the gap distance you want.

1 Like

I just found the bug, you got close. The CollisionDown point was closer to the current block the player was.

I actually started with a triangular sprite in each direction and tried to detect collision, but finding the closest block which was also in collision was not easy (then I moved to the points approach). I had no clue about this raycast condition, it seems to be exactly what I need! :pray:Thanks a lot for the suggestion!

1 Like

@Gruk the Raycast idea worked perfectly, it is exactly what I needed. Thanks for the suggestion. :+1:

I created a playable example: GDevelop example: board walk with Raycast by Paulo Amaral (source) and a pull request for adding it to GDevelop example base.

I implemented the logic below, together with placing the origin point of both Player and Block in the center of the Sprite.