#hex tiles

[gabby-rosemary]

I'm ruminating

[ericrav]

[ahnmakes]

devlog #3 // hex tilemaps and pathfinding, part 2 (setting up a procedural map)

okay.  procedural map generation, here we go!

last time, we talked through some of the options available for making tilemaps, namely hand-crafting maps or generating them more procedurally.  after discussing a few benefits and challenges for both, i decided that it might make the most sense to start with the procedural side of things, so that’s what we’re doing today.

it all begins with one hex -- and a lovely tutorial.

i crafted this cutie in blender (a free modeling and animation tool).  first, we make a cylinder and reduce its vertices to just 6, defining sharp edges.  after that, we make a loop cut near the top, then scale down those vertices to add a bevel.  just something simple to start with.  export!

when bringing the model into unity, blender models seem to do lots of wild things, namely around rotations and scaling (for example, showing the hex as rotated 90 degrees on its side).  

the model i’m using changed its orientation, position, and scale multiple times as i set it up, so rather than continue to mess with these discrepancies (namely differences in how blender and unity handle coordinate data), i decided just to orient and scale the model exactly as i desired, then child it to an empty gameobject.  making this nested (an adjusted child object inside a neutral parent object) and a prefab (a template i could make endless copies from) assured that the tilemaps’ setup and calculations would be much simpler.

this image shows a few of the nested prefabs together, just to get an idea <3

here comes the scary part: 

t h e  C 0 D 3

i included (helpful?) comments in most of my coding today, so you can look more closely at those, but the basic procedure for setting up the initial map was as follows: (1) define that there will be a gameobject we’ll need a reference to - our hex prefab!

(2) define a map size as a vector2; in the tutorial linked above, quill does this in two different variables, but i don’t see why using a vector2 would cause any problems and it’s cleaner, so we’ll see

(3) in the start function (aka when i press play on the game), execute a for loop that goes through each of the x-y coordinate positions and instantiates (creates) a hex there note: our y coordinate is placed in the 3rd position of the Vector3, which actually represents the z-axis.  i set up the coordinates this way in order to preserve our y-axis as vertical.  things can certainly be set up differently, and the first few times i programmed the coordinates this way, it used to confuse me quite a lot :o

from there, we get something that looks like this:

so, not exactly ideal-appearing yet, but really quite close to what we need.  it may be difficult to identify just by looking, but what’s happening is that the tiles are overlapping because our code is not adequately describing how much space to leave between them.  for this, we set up offsets on each axis!

at first, i added multipliers in around the instantiate call so that the tiles would be spaced further apart when created, but i quickly realised this was not a very clean solution.  instead of trying to figure out “okay how much do i need to modify the x position, due to the size of the tile?” and hard-coding in those values, i decided to adjust the hex model (inside the prefab) to something that would allow the tiles to be centered at whole numbers (1, 2, 3..) along the x-axis.  although there were still hard-coded values for the offsets, these should ideally never change and the rest of our code remains clear, without any surprise, unexplained numbers.

once adjusted, this code results in quite a pleasing set of tiles, or as pleasing as a plain white geometry can be:

and as mentioned before, this gave us cleaner positions along the x-axis, something i hope will be helpful later:

here, i decided to implement a few mostly cosmetic changes, to help things be more organised in the hierarchy - childing every created tile under the map object (which is where the map-generating script is placed) and giving each one a name based on its tilemap coordinates:

so, now that we have these tiles set up, how do we actually .. get them to .. do things?  how do we interact with them?

well, following quill’s suggestion in the tutorial series, i create a mouse manager (a script i attach to an object in our scene) which will help us interact with the tiles.

ignore the "Color lightPurple” line for a second; really, the magick starts with our ray.  this is an invisible line which begins at one point and is cast out in a direction, for a certain distance (or eternity!).  fortunately, unity offers us the function of “Camera.main.ScreenPointToRay” which can take our “Input.mousePosition” and draw a ray between the main camera’s location and the screen coordinates where our mouse is placed.  in other words, we are a little closer to being able to click on things! once we send out the ray, it says “i hit something” or “i didn’t hit anything” - if it does hit something, we give it the data structure of “hitInfo” and say “hey, fill this out so that we can know what the ray hit.”  since this is currently in the update function, we will get this information back every single frame.  every frame that our mouse is hovering over/touching something with a collider, our code will tell us the name of that object.

then, lastly, we set up to receive mouse input - aka clicks.  this code says “when i let up from a left mouse click, grab the mesh renderer component on the ray-touched object, then change its color!  that’s why we defined a color up top, in preparation of having many custom colors we might specify in the future.

and this is what that code looks like in action, as far as the clicking:

and lastly, a pretty view of our geometry <3

so, in summary, today we:

- created a hex prefab with a non-absurd rotation and scale

- set up a grid of those hexes which will automatically be spaced out appropriately

- made it so that we can hover or click on a tile and not only get back information on which tile it was, but also effect changes to that tile

whew.

we’re well on our way.

in the next devlog, let’s aim to set up more complex click interactions (like selecting tiles for movement, toggling colors, hovering one color but clicking to change) and some basic pathfinding to be able to move our player from one space to another.  maybe we’ll even explore a bit of customising tile colors, heights, and textures to create biomes .. or perhaps save that for another time. with love and a hex-based personality,

ahn

[1drawing-a-day]

[failedcode]

[Hexaverse] The smallest structure of space

As you might have guessed already, Hexaverse is named after the most prevalent feature: The hexagonal tiles. Normal quadratic tiles are a simple grid which is easy to render and mouse coordinates are calculated by dividing by the tile size. Hex tiles are not that different – you can transform the one into the other:

The y-axis isn’t straight anymore and what tile the mouse is over isn’t two lines of code, but there are big up sides: The distance from one field to another is constant. Moving diagonal has no advantage (or even meaning) on these fields – exactly like it should be in space. Every direction can be expressed as a coordinate pair – and there is no need to differentiate between even or uneven coordinates!

Then, there is the matter of horizontal or vertical and regular or compressed representation of the tiles.

I like the compressed H-tiling the most – it looks nice and is easy to construct.