hexagonal_map: Add turn-based movement mode#1239
hexagonal_map: Add turn-based movement mode#1239idbrii wants to merge 4 commits intogodotengine:masterfrom
Conversation
aaronfranke
left a comment
aaronfranke
left a comment
There was a problem hiding this comment.
I would not call these turn-based and real-time movement. These should be called tile-based and free movement. You can have movement be done on tiles without being turns, and being real-time doesn't inherently indicate that movement is freeform.
The code needs to follow the GDScript style guide: https://docs.godotengine.org/en/latest/tutorials/scripting/gdscript/gdscript_styleguide.html
All files need to be snake_case, so for example, gridlayer.gd needs to be renamed to grid_layer.gd.
|
See also PR #1085 which adds hexagonal navigation, I wonder if all of these should be in one demo. |
idbrii
force-pushed
the
hex-turnbased
branch
4 times, most recently
from
1f219ec to
940feee
Compare
|
Applied all the style changes and renaming to "tile-based and free movement". I believe I correctly merged with #1258 (kept uid from master).
I agree it'd make sense to combine them in the future. Maybe once this PR is merged that PR could add their features to this demo? |
|
With the current behavior of the demo, I find it very difficult to move up-left or down-right. If I try to move down-right, and I don't press the keys at exactly the same time, I end up moving down or right. I think it should not try to move when the input direction is close to being in-between two others, such as a right input being ambiguous between up-right and down-right, and instead a right input should wait until an up or down input is received. |
|
@aaronfranke What if instead, you select a direction and then press a key to confirm movement? I think that's more classic hex movement behaviour. Mouse picking an adjacent destination would also be more typical (but maybe for a future PR). I wasn't sure how much complexity is okay in these demos, but if that's fine then I think the more expected movement for hex is a better choice. |
Games with hexagonal maps usually want characters to stay within the grid, so add another movement option. This troll has no physics and uses tweens to move. Instead of collision, it uses tile values to determine where they're allowed to go. You aim your movement and then confirm with a separate key, which adds complexity over the free movement but ensures movement always matches intent.
Move troll's root pivot to line up with their collider. This makes their global_position a good representation of where they are. Add check for moving to an invalid tile and undo our move. In my tests, this isn't less smooth than skipping the move_and_slide if (global_position + velocity * dt) is an invalid tile and allows sliding to resolve us to a slightly different position.
idbrii
force-pushed
the
hex-turnbased
branch
from
3b7ab7d to
bbb3fc4
Compare
|
@aaronfranke I've updated the tile troll movement so you press Space/A to confirm movement. |
Use get_vector when building a Vector2 from input so it applies the deadzone. Increase the deadzone on all move inputs.
Add mouse click to move_confirm and now you can wasd, mouse point, or gamepad LS to aim your troll.
|
I added mouse aiming too. It was easier than expected! |
4 participants
Games with hexagonal maps usually want characters to move between tiles on the grid, so I added another movement option that makes the troll from tile to tile like a turn-based hex game. It still uses WASD controls (you need to press multiple keys to hit all 6 directions). Works well on gamepad too.
Additionally, the current
move_and_slidetroll doesn't really interact with the world, so I made it stop before leaving the grid. This also acts as a demonstration of how to get the tile id for interacting with objects represented by valid tiles.I also converted TileMap to TileMapLayer.
No untyped_declaration warnings.
Demo:
godot-hexmap.mp4