#Synchronizing movement between a 2D Grid and 3D Grid

8 messages · Page 1 of 1 (latest)

fathom crest
#

Hello, I'm trying to make a game with movement like a first-person dungeon crawler, like as in Etrian Odyssey or Undernauts. Basically, grid movement with a simple minimap that updates as you explore, and a dungeon grid represented in 3d, first person perspective. The picture is an example.

I've managed to prototype the 2d map, using the grid resource described in the GDquest's Tactical RPG tutorial, and it works fine so far. But now that I'm trying to figure out how to mirror that in 3D I'm a little stumped. I've done a bit of research, but I can't seem to find many examples of solutions for this problem. The few ideas I've found are:

-Just make the 3d unit move with the same inputs as the 2d unit (which seems simple, but I'm worried about the maps desynchronizing due to bugs etc, but I might be overworrying)
-Program everything on the 2d map and just use signals to control the 3d viewpoint (a lot of signals going could get messy)

Specifically, what I'm asking is: Is there a better way to synchronize the player's movement on two simultaneous maps, one that is a simplified 2d minimap and one that is a 3d first person dungeon?

Thanks!

honest rock
#

If the 3D area is just a projection of a 2D map, I suppose you could compute the relative location on the 2D map using the 3D position and set it directly so you aren't trying to keep them synced up
Basically, control one and let the other know where it is rather than trying to control both separately

fathom crest
#

So for example, I could make an alternate grid resource that uses Vector 3 instead of Vector 2, and then make sure to write a function that converts the V2 coordinates to V3 ones (with the right values swapped out) and then just have the 3d viewport position update to match the 2d one? So the player would always occupy the same grid points on the map... That could work! I'll just tinker around to see how I can make that happen

#

Also need to decide the size of the grid squares. I know 2d uses pixels as a unit, not sure how that translates to 3d

honest rock
#

Yep, basically. Both could work but I imagine the bulk of the movement code is in 3D so I think 3D to 2D would be a bit cleaner, since you could just trim the extra scalar and convert that to your grid size

#

Either way, it cuts the worry of desync since one is just a representation of the position of the other

#

Though yeah, maybe get the position of the player relative to the origin of the 3D gridmap? That way you don't worry about pixels so much as how many grid elements there are

fathom crest
#

Thanks, I'll try that! I started with the 2d map since that's what I'm most familiar with, but I'll see if I can find some resources to better help me understand the 3D-first method