Reply to thread

Message

<blockquote data-quote="Nom" data-source="post: 4045968" data-attributes="member: 56980">Actually, they cause a variety of problems, some of which are not shared by square grid metrics.Hexes constrain in exactly the same way that manhattan distance (orthogonal only) squares do.&nbsp; It's just not quite as noticeable because you have 3 axes of freedom rather than two.I've also noticed some people running the 'diamond' argument.&nbsp; That applies to hexes too.&nbsp; Set up two guys on a spline.&nbsp; Any path from one to the other is the same length, which means that a guy in the middle can be bypassed for no additional movement cost unless he can block the entire width.Similarly, a hex grid ends up in exactly the same situation as square grids vs distance on and off prime axis (oddly, the diagonal axes becomes the prime axes under the 4E system).&nbsp; I've played a number of space combat games on hexes, and one always ends up manoeuvring around the splines.&nbsp; Admittedly, those games including 6-direction facing.No grid can achieve an exact distance measurement.&nbsp; It's not accurate vs non-accurate; it's about how much inaccuracy you are willing to put up with.That's not a feature of hexes.&nbsp; That's just because you are using military wargame style hex maps.&nbsp; I have seen square maps with the same features.Assuming you are happy with &quot;circle&quot; = &quot;hex&quot; and &quot;cone&quot; = &quot;60 degree triangle&quot;.&nbsp; Which is fundamentally the same abstraction as &quot;circle&quot; = &quot;square&quot; and &quot;cone&quot; = &quot;45 or 90 degree square/triangle&quot;.&nbsp; D&amp;D 3.5 at least produced shapes that were significantly more circular / conic than the grid.Hexes do have one failing that is unique - they are not monotonic to intersecting lines.Draw any line across a square grid.&nbsp; Unless it lies on a grid line, there is always a single crossing point from any row or column to the next row or column.&nbsp; In contrast, many lines on hexes will spend some time in the zig-zag between two hexrows.&nbsp; This becomes a pain when trying to calculate sight lines or cover, as the &quot;direct path&quot; between two hexes is non-unique.It's important to consider the difference between hexes, manhattan (orthogonal) squares, cheybeshev (diagonal = 1) squares, and the diagonal = 1.5 squares approximation.&nbsp; Hexes and manhattan squares are mathematically identical with the exception of 2 vs 3 axes of movement.&nbsp; Non-manhattan square models offer 4 axes of movement, but with artefacts on distance metrics.As for other models, I've played a couple of games with the '1st diagonal costs double' model (eg a mini-game in Star Frontiers' Volturnus series, which incidentally normally counted hexes as 1).&nbsp; It ultimately plays almost identically to diagonal = 1, except that:(1) slower creatures suffer a greater penalty.(2) one ends up with a concave movement area (diamond with extra bits on orthogonals), which is the opposite of a &quot;realistic&quot; convex area.Thus, you end up with a &quot;quirky&quot; mechanic without really gaining anything.The opposite alternative, which I rather like in terrain-rich environments, is that diagonals count not double but +1.&nbsp; It means that a diagonal in clear terrain is the same as orthogonal (unless the orthogonal is blocked!), but you gain speed moving over difficult terrain.For me, though, the most telling argument is the unification of movement distance and range.&nbsp; Any model that penalises up-front means that an adjacent diagonal is range 2 while an adjacent orthogonal is range 1, which then means we need a 3.5-esque exception to handle that case.</blockquote>

[QUOTE="Nom, post: 4045968, member: 56980"] Actually, they cause a variety of problems, some of which are not shared by square grid metrics. Hexes constrain in [i]exactly[/i] the same way that manhattan distance (orthogonal only) squares do. It's just not quite as noticeable because you have 3 axes of freedom rather than two. I've also noticed some people running the 'diamond' argument. That applies to hexes too. Set up two guys on a spline. Any path from one to the other is the same length, which means that a guy in the middle can be bypassed for no additional movement cost unless he can block the entire width. Similarly, a hex grid ends up in [i]exactly[/i] the same situation as square grids vs distance on and off prime axis (oddly, the diagonal axes becomes the prime axes under the 4E system). I've played a number of space combat games on hexes, and one always ends up manoeuvring around the splines. Admittedly, those games including 6-direction facing. No grid can achieve an exact distance measurement. It's not accurate vs non-accurate; it's about how much inaccuracy you are willing to put up with. That's not a feature of hexes. That's just because you are using military wargame style hex maps. I have seen square maps with the same features. Assuming you are happy with "circle" = "hex" and "cone" = "60 degree triangle". Which is fundamentally the same abstraction as "circle" = "square" and "cone" = "45 or 90 degree square/triangle". D&D 3.5 at least produced shapes that were significantly [i]more[/i] circular / conic than the grid. Hexes do have one failing that is unique - they are not monotonic to intersecting lines. Draw any line across a square grid. Unless it lies on a grid line, there is [i]always[/i] a single crossing point from any row or column to the next row or column. In contrast, many lines on hexes will spend some time in the zig-zag between two hexrows. This becomes a pain when trying to calculate sight lines or cover, as the "direct path" between two hexes is non-unique. It's important to consider the difference between hexes, manhattan (orthogonal) squares, cheybeshev (diagonal = 1) squares, and the diagonal = 1.5 squares approximation. Hexes and manhattan squares are mathematically identical with the exception of 2 vs 3 axes of movement. Non-manhattan square models offer 4 axes of movement, but with artefacts on distance metrics. As for other models, I've played a couple of games with the '1st diagonal costs double' model (eg a mini-game in Star Frontiers' Volturnus series, which incidentally normally counted hexes as 1). It ultimately plays almost identically to diagonal = 1, except that: (1) slower creatures suffer a greater penalty. (2) one ends up with a concave movement area (diamond with extra bits on orthogonals), which is the opposite of a "realistic" convex area. Thus, you end up with a "quirky" mechanic without really gaining anything. The opposite alternative, which I rather like in terrain-rich environments, is that diagonals count not double but +1. It means that a diagonal in clear terrain is the same as orthogonal (unless the orthogonal is blocked!), but you gain speed moving over difficult terrain. For me, though, the most telling argument is the unification of movement distance and range. Any model that penalises up-front means that an adjacent diagonal is range 2 while an adjacent orthogonal is range 1, which then means we need a 3.5-esque exception to handle that case. [/QUOTE]

Verification