xyz Ahh that is right, you could just check if the cell above returns -1 and this is empty... duh...
Well as far as why to do this, in my game eventually I want to have bridges and such or platforms that are above that you can walk under (like there are in Tibia). In 2D there are no actual gaps it's just rendering order.
However, for 3D in 2.5D I assumed this was the best way to do that.
xRegnarokx You're again trying to make a complex system before you made a simple system.
xRegnarokx Here's a version of demo that can have holes. All tiles are now same sized cubes. It can handle any number of "bridges" one on top of another.
This is 15 additional lines of code compared to previous version. 60 lines in total in the whole project.
xyz Cool, thanks, I'll try and implement just that movement. Then I'll slowly add things to it such as other units moving, and detecting/setting occupation of tiles, ect... Thank you so much!
Edit: So, using your code I created a simple movement, and am working with it to understand it better. I did tweak it, and am planning on implementing obstacles to test it out, here is my occupied changing that I added.
func update_occupied(from: Vector2i,to: Vector2i,from_elevation: int, to_elevation: int) -> void:
for cf in map_data[from]:
if not cf.elevation == from_elevation:
continue
cf.occupied = false
for ct in map_data[to]:
if not ct.elevation == to_elevation:
continue
ct.occupied = truexRegnarokx Remember that the most important thing is figuring out the best fitting data structure(s) for the problem you want to solve. Doing so can simplify/shorten your code by the order of magnitude. Conversely, choosing inappropriate structure(s) can turn your code into a mess.
Time to yet again inject that timeless Fred Brooks piece of wisdom:
xRegnarokx Cool, thanks, I'll try and implement just that movement. Then I'll slowly add things to it such as other units moving, and detecting/setting occupation of tiles, ect... Thank you so much!
Note that adding other moving units to a system like this is trivial because movement only happens in respect to map data, and is instant. Only the visual representation shows (fake) gradual transition. So when you need to move the unit to some cell, just check if no other unit has its map position at that cell. If that's true, you can safely move it there.
xRegnarokx For completeness, here's the version with the player and arbitrary number of npcs, all moving and respecting cell occupancy of each other. As I already mentioned, this is trivial to add if you store your map/cell data in a proper structure.
We're now at 90 lines of code in total.
gridmap - 20 LOC
character base class - 50 LOC
player - 10 LOC
npc - 10 LOC
xyz You definitely make it look easy haha, I have a long way to go to learn how to think through implementation and such.
xRegnarokx Just keep at it. You'll get there.
xyz Thanks for giving me a launching pad, I have been expanding what you suggested to implement things like stairs/slopes that you can mount and normal blocks that you can't. So, rather than any block at a certain elevation, I've made it that there are certain mountable blocks, that you can mount, or descend from (following same 1 elevation difference principle) however, if you aren't on a mountable block, or moving to a mountable block you can't move to a higher or lower elevation.
I think I'll close this question for the moment since I think you sufficiently answered my original question.
I'll work on pushing objects and other movement types now, such as dashing to fleshout my movement system.
xRegnarokx Pushable objects should be treated in the similar way NPCs are. So again, they'd be relatively easy to implement.