Considering Hexes instead of squares

[Sir Brennen]

Most of the arguments against hexes can be reduced to "drawing on a hex grid is (supposedly) harder".
A few weeks ago, while we were discussing the matter of the 'irrealistic' 4E diagonals on it.hobby.giochi.gdr.dnd, Vincenzo Beretta suggested this brilliant solution: a hex-like distribution for squares (or, how to square the hex).
I've made a pdf sheet for use with my tokens you can find here.

I used this for my (fast-play) 4E demos at my gaming club's convention last weekend, and I must say it really is a reasonable compromise - almost as good to spot movement at a glance as real hexes, but with a lot less wasted space in dungeons and the like.

Your example is what most people mean when they mentioned using "off-set" squares. There's still as much "wasted space" when drawing rectangular rooms on the map along one axis, where every other square will be a half square.

 

[Asmor]

After looking at the SRD for UA, it does make a bit more sense to me. I was having trouble seeing Large as 3 hexes until now. If I'm reading it right, a burst 2 is the same as a 10 foot radius and a blast 6 is the same as the 30 foot cone, right?

Derek

I think you're right about blast (Blast N is an NxN square), but from what I understand about burst you're way off. Bursts are always fairly large, because you choose a target square and count a radius around that square. For example, burst 1 is a 3x3 square (radius of 1 around the center square). Burst 2 is a 5x5 square. In general, Burst N is a (2N+1)x(2N+1) square.

 

[Asmor]

Incidentally, I saw something on ENWorld a long time ago about drawing orthogonal lines on a hex grid that really changed my way of thinking. In a nutshell, it all boiled down to how you place the lines... Instead of trying to follow the natural lines of the hex grid, you have to go down a "zig-zag" where you're snipping a tiny corner off of each hex you intersect. Depending on the orientation, the line will either snip off 1 or 2 corners.

It allows you to easily draw lines in any increment of 30 degrees, meaning you can hit the all-important 90 degrees. Best of all, it keeps all the hexes mostly intact. At most, you're clipping off a tiny corner of a hex.

The big downside, in my mind, is that it skews the distance a bit. A walk way one hex-wide will appear, visually, to be wider or narrower depending on whether you're running in the "natural" direction of the hexes, which requires snipping 2 corners on each side, or if you're running skew which clips only 1 corner on each side.

 

[parvatiquinta]

Your example is what most people mean when they mentioned using "off-set" squares.

Oh, I see. So that'd be the English name for that then. Thanks!

 

[Burr]

Facing with hexes and 4e rules

I'm considering a houserule for facing with hexes:

1) Whichever direction you face, you get to add one more hex to your threatened area/range.
2) Changing your facing can be done as a minor action or as part of a move or shift action.

This brings it more in line with the number of surrounding spaces -- 8 for squares, but 7 for hexes w/ facing. We don't need special rules for flanking or for making your back more vulnerable; it's a natural consequence of your enemies' extra hex each.

I've never used facing rules of any sort before. But this seems simple enough, I imagine someone's already used a similar rule with 3.5. If so, was it worth it?

 

[Asmor]

If I may, I'd like to recommend against facing rules, especially if it costs an action to change your facing.

Like all other things, the space you're taking up is abstract. Trace out a 5-foot square on the floor (or hexagon, as the case may be). It's surprisingly large.

When you're standing there, you're not actually standing there. You're shifting around, dodging, moving, looking all around.

Facing is already abstracted out of the system with combat advantage. It's simple for someone to change their facing to address any new threats; however, if you've got threats in front of and behind you, then you can't give either of them your total attention.

 

[Whimsical]

Diamond grid battle mat

If super-diagonal movement bugs you, but you want to keep using your square-grid battlemat, then turn your mat 45 degrees so you have a diamond-grid map instead where the most efficient movement is forward, backwards, and side-to-side. Moving diagonally is appropriately less efficient.

You can also keep your battle mat normally laid out and then always set up your encounters so that your players start on one corner of the combat arena and their opponents are on the opposite corner.

 

[Dausuul]

If super-diagonal movement bugs you, but you want to keep using your square-grid battlemat, then turn your mat 45 degrees so you have a diamond-grid map instead where the most efficient movement is forward, backwards, and side-to-side. Moving diagonally is appropriately less efficient.

This doesn't solve anything. Instead of super-diagonal movement, now we have super-orthogonal movement. It's like the SWSE approach of having all diagonal movement cost 2; it doesn't fix the problem, just rotates it 45 degrees.

 

[DerekSTheRed]

I think you're right about blast (Blast N is an NxN square), but from what I understand about burst you're way off. Bursts are always fairly large, because you choose a target square and count a radius around that square. For example, burst 1 is a 3x3 square (radius of 1 around the center square). Burst 2 is a 5x5 square. In general, Burst N is a (2N+1)x(2N+1) square.

A burst 1 and 2 on a grid is 9 and 25 squares respectively. A 5 and 10 foot radius on a hex map (using the link I provided) will have 7 and 19 hexes respectively. That's about as close as you're going to get. They also are counted the same way. You pick a target square/hex and then count squares/hexes away from that equal to the burst value.

Derek

 

[WalterKovacs]

Considering that, with 4e, charging and running no longer require you move in a straight line ... changing over to a hex-grid doesn't have to worry about addressing those issues. There may be some counting issues with calculating distances [it still takes a little while in the Mechwarrior games that I've been playing for quite a long time] but the same issue would probably come up on a similarly positioned character on a square map.