# Tag Info

69

Octogons: Hexagons: The gaps in the octogons make for an unappealing game world. Typically, if you wanted to allow for eight directions of movement, you would just use squares.

66

To summarize and elaborate upon what has been said in other answers and in comments, triangles, squares and hexagons are the only mathematically possible regular tilings aka regular tessellations of the Euclidean plane. So yeah, this sucks. Triangles are completely useless here, squares suck because you can't move diagonally without having a somewhat ...

43

This guide didn't exist when the question was asked, but here's my guide to hex grid math: Hexagonal Grids

33

I have been able to come up with a few reasons myself, but I'd really like to hear more. Horizontal layout matches the layout of the keyboard. You could use WEADZX for movement, similar to WASD on square grids. On the other hand, I have also found suggestions that QWEASD is a natural fit for vertical hexes. Horizontal hexes seem to be better suited for 3D/...

29

The author of HyperRogue here. HyperRogue actually uses a tesselation made of hexagons and heptagons, here is the reason why this particular tesselation has been chosen, instead of only octagons or heptagons, for example: Hyperbolic geometry in Hyperbolic Rogue Basically, the octagons are too big. Also some consequences of using hyperbolic geometry in a ...

23

A hexagonal ring with the radius of N consists of 6 straight lines, each with length N - see my extremely crude example below :) For N=2: The arrows cover 2 hexes each. I assume you have some functions which give you the neighbouring tile in a specific direction, like north(), southeast() etc. So your algorithm, in pseudocode, should be something like ...

23

I would go with vertical layout if you are using any sort of bird's eye perspective, as in the image above. Why? Because all walls will be visible. If you use horizontal layout, and you have walls that run along the vertical lines, you will not be able to make out details on them very well (such as doors or gates). Furthermore, if you are using the ...

21

A few answers! The coordinate system I've seen most often for hex-based traversal is one where the player can move in every normal NSEW direction, as well as NW and SE. Then you just render each row half-a-square offset. As an example, the location (2,7) is considered adjacent to (1,7), (3,7), (2,6), (2,8), and the weird ones: (1,6) and (3,8). Meanwhile, if ...

17

Sounds like you're leaning toward horizontal as having more advantage. For what it's worth, bees agree with you when they build their honeycombs: The axes of honeycomb cells are always quasi-horizontal, and the nonangled rows of honeycomb cells are always horizontally (not vertically) aligned. Thus, each cell has two vertical walls, with "floors" ...

16

No. √3 is an irrational number, and by definition an irrational number can not be used as a ratio between two natural numbers (integers) such as pixel counts. However, there is no rule that says you have to use ideal hexagons in your game tiles. If you approximate it closely and avoid any miscalculations that may result, which you should be able to do ...

14

If you are building a strategy game, the game requirements and design itself should dictate which orientation you choose. Note that defensive lines are more easily held with the grain than against it, so your choice of grid orientation relative to map orientation will affect game play. To emphasize defence, such as in WWI, align the hex grid with the natural ...

14

Your hex orientation will influence both your general aesthetics and your asset production. If you choose vertical tiles, you can make your hexes twice as wide as they are tall and have pixel-perfect accuracy. Here are some 64x32 hexes. Note that the diagonal edges are at 45 degree angles, making them easier to render in pixels. The narrow height of the ...

13

From a technical and programming perspective, there should be no fundamental difference in data structure between the two orientations - any reasonable scheme should be easily modifiable to work well with either setup. Design-wise, in the end it will come down to preference — as you've noted, there are multiple games using either scheme, which is ...

13

Have you tried Lloyd's Algorithm? The procedure is pretty simple, and will generate fairly regular looking regions (depending on how many iterations you run). Tile the map with blank hexes to start. Choose N hexes at random. These will represent the "center of mass" for each country. Tag each hex with the center hex it is closest to (Voronoi Diagram). ...

12

As Martin Sojka notes, rotations are simpler if you convert to a different coordinate system, perform the rotation, then convert back. I use a different coordinate system than Martin does, labeled x,y,z. There's no wobble in this system, and it's useful for lots of hex algorithms. In this system you can rotate the hex around 0,0,0 by “rotating” the ...

12

I guess I'll take the counterpoint here and argue against using static values. In this case, all of the hex regions you're talking about are (a) easy to compute - you don't need to use BFS or anything so complicated; you should be able to iterate over all of the hexes in any of them with straightforward doubly-nested loops; and (b) not something you'll need ...

12

There are many hex coordinate systems. The “offset” approaches are nice for storing a rectangular map but the hex algorithms tend to be trickier. In my hex grid guide (which I believe you've already found), your coordinate system is called “even-r”, except you're labeling them r,q instead of q,r. You can convert pixel locations to hex coordinates with these ...

11

If the values will never change, they may as well be static. Why waste CPU time recalculating something that will be the same as last time? However, they don't necessarily need to be 'hard-coded': You can put the values in a data file, and load that in at the start. You can perform the search during play and cache the values once you find them. The first ...

11

You're right that A* is a little overkill, but not by much. You shouldn't be seeing delays like you are. A* is really just a modified Dijikstra's algorithm. Since you're not using an end position (as your end position is just "as far as you can go"), using A* with it's added heuristic isn't necessary. Simply using Dijikstra or a simple breadth first search ...

11

Finding an algorithm is usually best done with a data structure that makes the algorithm easy. In this case, your territory. The territory should be an unordered (O(1) hash) set of borders and elements. Whenever you add an element to the territory, you iterate over adjacent tiles and see if they should be a border tile; in this case, they are a border ...

10

I don't recommend using the "increase the dimensions and orbit in a cylinder" trick here. It has several disadvantages: More expensive to compute: Perlin noise needs to select and interpolate $d^2$ gradient vectors per evaluation, so going from 2 dimensions to 5 means doing 8x more work. More distortion: by evaluating it on a membrane in higher-...

9

The parallelogram coordinates you're using are easier to work with, but they do have the drawback of being weird for rectangular maps. One approach is to store it with the offset coordinates but actually use parallelogram coordinates in your game logic. Observation: in each row of the map, the grid data is contiguous. All the wasted space is on the left ...

9

Use a Canonical (Or oblique) coordinate system (with axes at 120 degrees) to identify the hexes that are in the triangle. Then convert the coordinates of those hexes (with a homogenous transformation) to Rectangular coordinates for display. The utility toolkit I linked to above could be of help in writing this code.

9

Basically what you want is a monohedral tesselation (or tiling), that is a coverage of the entire plane (assuming 2d) with a single shape where the tiles do neither overlap nor leave gaps. There are lots of shapes with which this can be done but when we introduce other constraints, usually orientation should stay the same or they should conform to a ...

9

Before I answer the question you already asked, some notes: You can use A* with the original grid system you are using. The key things you need are neighbors and distance (for the heuristic). For neighbors with your grid system, you need to do something different for even and odd columns (as you mention); here's how: neighbors = [ [ [+1, +1], [+1, 0]...

9

There are two ways to handle this problem, in my opinion. Use a better coordinate system. You can make the math much easier on yourself if you're clever about how you number the hexes. Amit Patel has the definitive reference on hexagonal grids. You'll want to look for axial coordinates on that page. Borrow code from someone who has already solved it. I ...

9

While I don't know of any truly official convention for classifying these, in the mathematical sense, I'll take Anko's advice and write up what I do know... Amit Patel (Red Blob Games) wrote what I'd consider the definitive guide to using hexagonal grids in games. This guide uses the nomenclature: flat topped pointy topped So while it's not super ...

9

If you need to find edges of holes in the middle of your territory too, then your linear in the area of the territory bound is the best we can do. Any tile on the interior could potentially be a hole that we need to count, so we need to look at every tile in the area bounded by the territory's outline at least once to be sure we've found all the holes. But ...

8

In algorithm 1, you're using “even-q” but you should use “odd-q” instead. Your grid is flipped upside down relative to the one on my page, so you want to shift every odd column up instead of every even column down. Change + (x % 2) in coordOffset2Cube and coordCube2Offset to use - (x % 2) instead. Also, on diagonals, the line drawing algorithm will not hit ...

8

I'd consider a Square-based grid as a "base" type of tiles in any game. Such grid is simple to imagine and moves over this grid are simple to understand. It's also very simple to implement "under the hood". Those are few reasons why even the Chess game uses it :). Additionally, this grid helps you make "regular" levels, because Vertical and Horizontal are ...

Only top voted, non community-wiki answers of a minimum length are eligible