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.
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.
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. 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.
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 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.
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! Thanks a lot for the suggestion!