Advertisement

moving sprite on a hex grid

Started by June 14, 2022 08:51 PM
73 comments, last by Tom Sloper 2 years, 4 months ago

I like the pics. I have a question about how do I draw a sprite in a hex and then move it to another hex center.

1. Write a function “draw_hex(x, y)” that draws a hex at position (x, y)

2. Write a function “draw_sprite(x, y)” that draws a sprite at position(x, y)

3. Write a function “draw_all_hexes()” that draws all hexes using the “draw_hex(x,y)” function above.

4. Write a function “draw_game(x, y)" that draws all hexes, and draws a sprite at position (x,y)

5. Have variables “spr_x, spr_y” for storing the position of the sprite

6. Then, for your question, call draw_game(spr_x, spr_y) to display the sprite at the first position, change “spr_x, spr_y” to a different position, and call draw_game(spr_x, spr_y) to display the sprite at the new position.

Advertisement

Question: How do you draw a sprite in a hex and move it to another hex center?

You start by thinking in Hex Grid Coordinates (which is what I gave you in that picture of the hex grid). Figure out where your sprite is, in hex-grid terms.

To draw your object in a hex (in OpenGL), translate that hex-grid location to world space terms. Then give those world space coordinates to OpenGL.

To move from one hex to another hex, think in hex-grid terms. Look for the patterns for each of the 6 ways to move from your current hex. And use those patterns to develop algorithms to step along the hex grid.

Moving East and West on the hex grid I illustrated is easy (that is just +/- x like it would be on a normal grid). NW, NE, SW, SE are a bit harder, because the rules for that motion change depending on whether your current row is even or odd. But the rules still exist. And you can derive them by looking at the picture I gave you.

For example, from looking at that hex-grid image I supplied, we can determine how to step NorthWest. . . and the code could look like this :

glm::ivec2 Take_NorthWestStep_On_HexGrid(glm::ivec2 StartPoint)
{
        glm::ivec2 Destination;
        
        Destination.y = StartPoint.y +1; // NW move is always +1 y (but may, or may not change x value)
        
        // now we need to find out if we are on an even or odd row. . . 
        if( StartPoint.y % 2 == 0) // this means we are on an even row
                 Destination.x = StartPoint.x -1; // even row means -1 x
        else // we are on an odd row
                 Destination.x = StartPoint.x; // odd row means no change in x
                 
         return Destination;
}

And you could use the above code as follows. . .

// Move tank one step North West on Hex-Grid
Tank.location = Take_NorthWestStep_On_HexGrid(Tank.location);
// Important Note : the above function does NOT check for grid bounds, 
// so we might eventually want to check to see if our NW step takes us off the hex grid,
// however, for learning purposes, we'll not worry about such matters right now

If we know where your tank is in Hex-Grid terms, then move it to the North-West in Hex-Grid Terms (using the function above), then we translate that new hex-grid loc into world-space, and draw it in OpenGL. By doing this action, we will have accomplished your goal of moving on a hex grid, and drawing your sprite at the new hex center.

What remains is to translate from Hex-Grid space into world space. Which I will explain soon enough (I'm going to take this one step at a time though).

@Warp9 I really dislike the way you are numbering your hexes. It works, I guess, but the non-uniformity means that every time you write a function that operates on hex coordinates, you need to make sure that it works on both the even and the odd rows. That's twice as many cases to think about, twice as many test cases to write, twice as many bugs to fix. Four times as many for functions that operate on two hex positions at the same time, e.g. distance functions.

Much better, in my option, is to use a skewed coordinate system:

          /  \  /  \  /  \  /  \
         [0, 3][1, 3][2, 3][3, 3]
       /  \  /  \  /  \  /  \  /
      [0, 2][1, 2][2, 2][3, 2]
    /  \  /  \  /  \  /  \  /
   [0, 1][1, 1][2, 1][3, 1]
 /  \  /  \  /  \  /  \  /
[0, 0][1, 0][2, 0][3, 0]
 \  /  \  /  \  /  \  /

well, I am going to code a sprite that moves in a square grid before I use a hex grid.

well, I have got a sprite to move west and east along the hex grid I just have to move NE SE SW NW directions.

Advertisement

@a light breeze : That method of doing things never occurred to me. Very cool! I guess you learn something new everyday. :-)

I like the fact that it gets rid of all the conditional tests based on odd/even row.

My only complaint is that it looks like it would create a sloping edge to your map though (as every thing skews to the right). A sloping map doesn't match well with the vertical edge of a computer screen. . . do you have a solution for that?

@pbivens67 : I really like the idea of starting with a square grid before going to a hex grid. . .

Solve the simpler problems first, then move to the more complex ones! That's how things get done.

well, I finished my drawing code, it moves W, E, NE, SE, SW, SE, all directions on the hex grid, thanks for all the help.

@pbivens67 : That is awesome news, I'm glad you were able to get your code to do what you wanted it to do! :-)

This topic is closed to new replies.

Advertisement