Incline Hexes or Squares?

[Momock]

One disadvantage of grid less TB is that it's less obvious what is blocking moves and what is not (Can I squeeze past these two obstacles / mobs / characters - will my tank block this doorway?).

That's what you get for going with "rigid blocks that physically block the path" model.

It's better to assume that solid core of your character is surrounded by non-solid halo of their reach, which doesn't prevent friendly movement or own movement by obstacles, but is used for actual blocking. Then you can block passages by overlapping weapon ranges with obstacles and each other, without any need for being pixel exact.

Of course with gridless you do need some extra UI aids:

• Ability to queue any reasonable sequence of moves not limited to current turn (to make sure that your brilliant plan doesn't require you to go a pixel further than you actually can) - reasonable means just short of "fuck, if we do that we'll run out of RAM"
• Relevant ranges and passabilities overlaid (possibly on demand) on both current and planned/expected tactical situations
• Unambiguous presentation when movement crosses into range or hazard, and when ranges and hazards directly cross into obstacles.

Otoh you get to move and reposition arbitrarily and have a lot of subtle mechanics involving reach and movement.

OR

You can put a fucking grid so a can play the game instead of trying to understand all that indigest extradiegetic bullshit on the screen.

 

[Valky]

I've always preferred hexagons. HoMM3, Eador Genesis, and Wesnoth all use them.

 

[J1M]

Have any games done a 3d hex grid, or is it generally understood that hexes can't scale to a third dimension?

That's a good point. But one must remember that you are thinking of a continuous map in 3D which is not a necessity. You can always use half hexes to fill in what is missing.

You are confused. I am talking about 3 dimensions of movement. A square grid easily scales to cubes when height comes into play.

 

[passerby]

The only advantage of hexes over squares is that movement speed/range in all directions is more accurate, when you have 1AP point per tile rule ( but still not perfectly mathematically accurate anyway ).
A simple rule like 1AP/1.5AP for movement and range will deal with this issue on squares.

Huge advantages of squares are 8 facing and movement directions symmetrically alligned with cardinal directions and very easy alligment of human made environments into the grid, nature is easier too.
Think how natural layouts felt in Ultima Underworld with only stright and diagonal walls on a square grid.

Hexes are good ( but not better really ) for strategy games with scale large enough, that physical facing of units is not a concern, for tactical games squares are way superior.
I was a blind supporter of the hexes, because they look cool and advanced, before I've actually put a 10 minutes of thought into it.

 

[Matticus]

Thanks for the insights. In response to my earlier posts, I think I was getting caught up with the issues surrounding diagonal action cost of squares -- so I was convinced hexagons would be more elegant. I also just recently played through Fallout 1 so it was on my mind. Having been testing a few more games I am now favoring squares by a significant margin, and feel like gridless is probably more trouble than it's worth. For grand scale battles hexes work well though.

 

[mihai]

For the A* this "3d cube grid" graph poses no problems and it might be more simple for human players than a bitruncated cubic honecomb, since the movement is more obvious in a square cube grid. But if it is not tested even once we don't know for sure the result.

Ok so actually I pondered this idea a while ago and programmed a bare-bones engine in my spare time. I did use A* at first, but it usually doesn't scale well in 3d. So I spend a lot of time (and headache) trying to translate jump point search (JPS) into the bcc grid (totally different pruning rules). I think i got it right, but not sure if it's bugfree. In the time dimension, I played with a kind of phase-based resolution, by having each unit stepping after each other with rogulike-like rules (higher speed gives you 2 steps sometimes, for example). The time-steps are not shown, however, but interpolated with a 5th polynomial (to get smooth rotation / roll).

I never captured any video before, so the quality is a bit bad, but here's a short demo:



please treat this as vaporware right now, I don't know when I will have free time again.

 

[J1M]

Have any games done a 3d hex grid, or is it generally understood that hexes can't scale to a third dimension?

That's a good point. But one must remember that you are thinking of a continuous map in 3D which is not a necessity. You can always use half hexes to fill in what is missing.

You are confused. I am talking about 3 dimensions of movement. A square grid easily scales to cubes when height comes into play.

I know. and a hex grid does not. But you can easily fill in the voids. For example, a staircase that leads from the ground floor to first can be built of partial hexes at turns for example.

This fetish for partial hexes seems to have you distracted. Consider the case of a large scale army clash with flying units. Or a space battle. Or a medeival keep with a hex for a gateway and a defensive position directly above it.

If I am somehow missing something magical about 3d hex battles I implore you to provide a diagram.

 

[The Great ThunThun*]

Maybe I do not understand. Do you mean something like this?

 

[DraQ]

One disadvantage of grid less TB is that it's less obvious what is blocking moves and what is not (Can I squeeze past these two obstacles / mobs / characters - will my tank block this doorway?).

That's what you get for going with "rigid blocks that physically block the path" model.

It's better to assume that solid core of your character is surrounded by non-solid halo of their reach, which doesn't prevent friendly movement or own movement by obstacles, but is used for actual blocking. Then you can block passages by overlapping weapon ranges with obstacles and each other, without any need for being pixel exact.

Of course with gridless you do need some extra UI aids:

• Ability to queue any reasonable sequence of moves not limited to current turn (to make sure that your brilliant plan doesn't require you to go a pixel further than you actually can) - reasonable means just short of "fuck, if we do that we'll run out of RAM"
• Relevant ranges and passabilities overlaid (possibly on demand) on both current and planned/expected tactical situations
• Unambiguous presentation when movement crosses into range or hazard, and when ranges and hazards directly cross into obstacles.

Otoh you get to move and reposition arbitrarily and have a lot of subtle mechanics involving reach and movement.

OR

You can put a fucking grid so a can play the game instead of trying to understand all that indigest extradiegetic bullshit on the screen.

Say what you want about other genres, but at least their enthusiasts are usually lucid enough to not want to make the gameplay subservient to the UI.

...and if they aren't, we deride them for being

 

[J1M]

Maybe I do not understand. Do you mean something like this?

That is a great example of the compromises a hex grid needs to make. That certainly looks pretty, but where did the vaunted benefits of equidistant measurement go?

Is the hex with the door on it the same distance from the knight as the hex of grass above the arch? What are the rules around a hex 4.2 hexes above another?

When the elevation slices are done the way a square grid would be, one has to ask what the point of hexes is (aside from aesthetics).

 

[Cael]

Maybe I do not understand. Do you mean something like this?

That is a great example of the compromises a hex grid needs to make. That certainly looks pretty, but where did the vaunted benefits of equidistant measurement go?

Is the hex with the door on it the same distance from the knight as the hex of grass above the arch? What are the rules around a hex 4.2 hexes above another?

When the elevation slices are done the way a square grid would be, one has to ask what the point of hexes is (aside from aesthetics).

The problem with equidistant measurement for elevation is that in DnD, for example, it is a 5ft distance. A 5ft step up is... difficult, to say the least. Battletech went the other way, in which an elevation level is half the height of a 'mech (about 5-6 meters), whereas a hex represented 30 meters.

Most map grids tend to break down in use when you take it to the third dimension and you have to make allowances or adjustments to the z-axis.

 

[Zanzoken]

Hexes are the monocled choice but I like the simplicity of squares.

 

[Momock]

Say what you want about other genres, but at least their enthusiasts are usually lucid enough to not want to make the gameplay subservient to the UI.

The very definition of popamole: games that are such a mess that the only way to make them playable is to have ugly highlights everywhere on the screen and to make every action assisted/contextual. It's been this way for ages in AAA gaming and you're suggesting to do the same in RPGs with you're gridless thing. Like if having so much shit to manage per turn (for something trivial like no squares because ???) isn't going to be compensated by removing actualy important mechanics so you don't have to lose an hour each turn.

 

[tritosine2k]

https://github.com/uber/h3

VERY nice

 

[tritosine2k]

 

[Harthwain]

Hexes makes tactical aspect of the game more complex, because there is always a position that is more exposed than others, even in a single line (assuming the grid is properly placed, of course). With squares you can form a line and most of it will be equally protected, save for the flanks.

The only advantage of hexes over squares is that movement speed/range in all directions is more accurate, when you have 1AP point per tile rule ( but still not perfectly mathematically accurate anyway ).

You can have squares and allow to move to any square, even diagonal ones, thereby giving 9 possible movement directions, instead of 6.

 

[thesecret1]

I've suffered AoO attacks on me on square grid because I failed to notice my square is touching he enemy's by the corner far too many times. Square grid a shit, hex grid forever.

 

[luj1]

Hexes ofc

 

[FriendlyMerchant]

Measurement based positioning instead of grids.

 

[Assisted Living Godzilla]

Of the two I prefer Hexes, although I could also go for a completely gridless system like Temple of Elemental Evil and Valkyria Chronicles.

 

[Sykar]

Octagons, clearly!

 

[J1M]

Would suggest the new arrivals actually read the thread. It's an interesting examination of the topic from multiple perspectives.
Harthwain thesecret1 FriendlyMerchant Assisted Living Godzilla Sykar

Also, isn't "measurement-based" just a preference for 1-pixel wide squares?

 

[MadMaxHellfire]

squares with time units. x-com uber alles.

 

[Mr. Magniloquent]

Neither. This is the kind of anachronism that doesn't need to be in CRPGs. Look at ToEE or DOS. That's how you do it properly.

 

[tritosine2k]

https://news.ycombinator.com/item?id=16136912 from H3: A Hexagonal Hierarchical Geospatial Indexing System

I used to work at Uber and worked on H3. They're working on a blog post to explain some more, but if you clone the repo and build the doxygen docs, you'll get more explanation.
The big difference between this and S2 is that hexagons have only one kind of neighbor, neighbors that border on an edge, instead of the two kinds of "checkerboard" neighbors that squares have. This lets you do some interesting analysis on data gathered with hexagons.
Movement between neighbors could be modelled as a current flow, with the edge being a cross-sectional area between them, and since the edges are all equal (unlike squares) you can consider it a constant factor on that analysis, and then drop it and simply use the directional flow counts (the H3 UniEdge index) directly.
H3 takes better care than S2 to keep both hexagon area and shape distortion to a minimum together (area distortion is about the same as S2, but shape distortion is much better than S2), so the hexagons look almost the same almost anywhere on the planet, and so data gathered in one city on the planet is directly comparable to data gathered in another city, which can let you do interesting things like classify "types" of hexagons (urban, suburban, etc) and then make predictions about cities you haven't even set up shop in, yet, based on similar cities.
Hexagons are also the most efficient way to pack spheres, and can best approximate a circular radius with a discrete grid, so they're also useful for doing fast approximations of field-effect calculations (like electromagnetic fields from discrete particles). You could count drivers as a negative charge and riders as a positive charge, for instance, and use EM equations to determine the biggest imbalances in supply and demand distribution, and this will let you do it very quickly with little error.
The hexagons themselves can get down to a granularity below GPS resolution error, so you could, without any effective losses, pack 3 doubles (lat, lng, error) into a single 64-bit integer (H3 index of an appropriate size based on the error) and reduce bandwidth usage on location data.
The H3 index for any particular resolution is ordered in something similar to a Gosper curve[1] so if you really need just a rough approximation of data to query from an area, you actually only need to store the two indexes at the beginning and end of the gosper-like curve you're interested in.
This C library wasn't meant to be used directly by most developers and that's why it has a few rough edges (like not centering the output around the meridian (-180, 180) instead of the current (0, 360) output). I can't wait until the bindings come out, too, probably with the blog post.
[1]: https://en.wikipedia.org/wiki/Gosper_curve

Neither. This is the kind of anachronism that doesn't need to be in CRPGs. Look at ToEE or DOS. That's how you do it properly.

git gud