Search Unity

  1. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  2. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice
  3. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Movement in Isometric 2d tilemap

Discussion in '2D' started by tylerdtrudeau, Feb 28, 2021.

  1. tylerdtrudeau

    tylerdtrudeau

    Joined:
    Mar 4, 2020
    Posts:
    1
    Ok so bear with me as this is my first post on this forum and any help would be appreciated. I have searched through this forum, stack exchange, youtube, etc.. and cant seem to find a solution or explanation for my problem. Also pleas note there are a few questions in here. so here it is...

    I am using 2D isometric Z as Y tilemap. setting up the sprites and painting the tiles all works fine. however I am having some issues with the movement. I have gotten the player movement to work just fine using Rigidbody.Moveposition. For my side to side movement I am doing Vector3(-0.5f, 0.25f) "left" and Vector3(0.5f, -0.25f) for "right". As well as Vector3(0.5f, 0.25f) and Vector3(-0.5f, -0.25f) for "up" and "down". so using these values my player will move exactly one tile in whatever direction I press, which is great. However I want to implement a system so my player can only move say 3 tiles in one turn.

    Question 1 - How can I limit my players movement to only 3 tiles in one turn if my tile distance is different depending on which direction they are going? For example I move 0.5 on the X and 0.25 on Y.

    Question 2 - Is there a way I can set up my movement so I can move 1 to the left on x to move to next tile or 1 on y to move up 1 tile (as opposed to different decimals like 0.5 and 0.25). Or is this just not possible on isometric tilemaps?

    Question 3 - How do I highlight my possible movement for the turn? Like so that 3 tiles in every direction are flashing or a different color or whatever. I know I'll need to do some pathfinding to go around obstacles and stuff and to eliminate not walkable areas. But just for the start I would like to get it working without considering unwalkable areas as I can just cross that bridge when I come to it.

    The above scenario is using the WASD system to move the player. I have also been messing around using the mouseclick to move the player. The problem I have been running into with this system is the difference in the screentoworldpoint and worldtocell. for example I have a couple lines here.

    Vector3 mouseWorldPos = Camera.main.ScreenToWorldPoint(Input.mousePosition);

    when I use debug.log to print out my coordinates on a click it gives me something like (-1.5, -0.9, -10.0)
    then when I use...

    Vector3Int coordinate = grid.WorldToCell(mouseWorldPos);

    I get a printout of (1, 4, -10) for a click on the same cell as the screentoworldpoint example.
    I then try to feed in my Worldtocell vector 3 as a move coordinate like...

    transform.position = new Vector3(coordinate.x, coordinate.y);

    it just moves me to (1,4,-10) but on the screentoworldpoint system NOT the grid cell system. so its nowheres near where I clicked.

    So Question 4 = when I give my player coordinates, how do I make sure it moves to those coordinates on the grid cell system and not the screen to world point system?

    Any and all help is greatly appreciated (and please keep in mind this is my first post)

    Thanks
     
  2. Derekloffin

    Derekloffin

    Joined:
    Mar 14, 2018
    Posts:
    321
    Oh you have more questions... below still applies to question 1:

    Best method I can think of is to use a continuous check of distance traveled adjusted appropriately for the x/y compression. So you want 3 tiles, so that's a total distance of 3. So every turn the player starts with 3 movement. Every fixupdate, you compare the last position of the player to their current position and get a diff of x and diff of y. You then adjust those (in your case doubling y) and compute the distance traveled in the last fixedupdate and subtract it from your total available distance (or add it to a distance traveled total, whatever you prefer). It isn't perfect, as you'll get the player in the last frame either coming up a bit short if you bound high, or a bit long if you bound low, but it will probably be good enough. If you want to be perfect, you'll have to do some final frame adjustment to the position, but I suspect that extra code isn't necessary as the difference will probably be pretty small and I've found messing with position tends to cause issues with the rounding so best to avoid it unless absolutely necessary.
     
    tylerdtrudeau likes this.
  3. Derekloffin

    Derekloffin

    Joined:
    Mar 14, 2018
    Posts:
    321
    Question 2 not sure what you mean so will skip that.
    Question 3: Depends a lot on how you want it to look. Flashing tiles are fine. You could also draw a transparent ellipse of the appropriate size centered on the player too. Ellipse is pretty easy to show as you just make a sprite ellipse and resize it appropriately. Flashing tiles you just have to compute a distance. It is a bit tricky, but you can use many square tile calcs and here if need be and just convert back to iso tiles at the end.
    Question 4: Not sure what you mean here. There is functions to move both to and from cell positions to world positions. I'm not sure that is what you're looking for though since you seem already aware of them.
     
    tylerdtrudeau likes this.
unityunity