Turn Based: Square Grid vs. Hexagonal Grid

[denizsi]

edit: 2011.01.28 - just so you know this isn't thread necromancy for teh lulz by some newfag. I'd like to once again bring this question to attention as it didn't draw as much as attention and discussion as I would've liked it to.

Which is better and why? Discuss!!

Seriously, though.

Also, alternative grid approaches and hybrids are welcome, as long as there's still a grid.

edit: For instance, does anyone feel the same way that either has a bias towards ranged / melee combat? I tend to think that a hexagonal grid is much better suited to melee combat if only for the natural inclination it provides towards footwork and opponents circling one another. Put two figures on anywhere on a hexagonal grid and their opposition towards each other is naturally complimented by the movement options the hexagonal grid provides. With a square grid, it becomes more like an environmental puzzle-game (which is kind of how I felt like playing AoD combat demo -not that it's anything bad or a disadvantage but just different).

 

[DraQ]

Hexes, as only one kind of adjacent tiles exists.

Alternative? Why, rhombic dodecahedral three-dimensional honeycomb, of course.

 

[rpgcodexusername]

hexes are a pain the ass to program, they look a lot better though.

e.g. to draw a bunch of squares its

for x=0 to map_width
for y=0 to map_height
drawimage(square,x*64,y*64)
next
next

(64 is the image width)


Now, can anyone come up with the formula to draw hexagons??

To see if the mouse if over a certain square its

for x=0 to map_width
for y=0 to map_width
if mousex>x*64
if mousey>(y*64)
if mousex<x+1*64
if mousey<y+1*64
selected square=xy
endif
endif
endif
endif
next
next

for a hexagon you have to calculate if the mouse was inside 6 polygons inside of a certain hex.

 

[racofer]

I prefer squares, as long as diagonal movement counts and just one.

 

[denizsi]

The hexagonal grid based movement script I wrote for Oblivion/Fallout 3 was quite simple, though basically, the logic was still square based with some interpolation. It worked/works glitchless. Still, it's a hell of a lot longer than what a straight square grid script would look like, but it really is simple.

I was also surprised that VD went with a square grid, saying they couldn't implement a hexagonal grid, because implementing one in OB/FO3 with mere scripting was so damn easy.

Anyway, alternatives or hybrids could be something like a dense square grid, for instance, where any given unit occupies several squares according to its size, so it's possible to move more precisely than a basic square grid, with less restrictions. Or something like a gridless game world where a grid is dynamically adjusted whenever a turn starts and the characteristics of the grid may or may not depend on the action you'll choose. Or what I don't know. Yes, rhombic dodecahedral three-dimensional honeycomb

I also favour hexagonal grid, but my favourite, and probably, with so little dispute, the best turn-based tactical combat is in JA2, which is grid based, and I simply can't imagine JA2 with a hexagonal grid.

 

[denizsi]

I prefer squares, as long as diagonal movement counts and just one.

That's my foremost problem with squares. Diagonal movement is a deal breaker for me. Damned if it counts one, damned if it doesn't.

Now, can anyone come up with the formula to draw hexagons??

To see if the mouse if over a certain square its

for x=0 to map_width
for y=0 to map_width
if mousex>x*64
if mousey>(y*64)
if mousex<x+1*64
if mousey<y+1*64
selected square=xy
endif
endif
endif
endif
next
next

for a hexagon you have to calculate if the mouse was inside 6 polygons inside of a certain hex.

I just saw your edit. Here's one of the working iterations of the hexagonal grid script I've written for Oblivion:

scriptname denizsiCM

short consoleOpen
short doOnce
short doOnce2

short defCurX
short defCurY

short defCurX0
short defCurY0

float nk
float chX
float chY
float kX
float kY
float pcX
float pcY
float pcZ

float distH
float distF

ref CursorObj
ref HexObj

; //////////// DEBUG KEYS //////////// /////////////// ///////////////

Begin GameMode

if IsKeyPressed2 79 == 1
	set CursorObj to GetCrosshairRef
;	MessageEx " %n " CursorObj
;	return
endif

if IsKeyPressed2 80 == 1
	set HexObj to GetCrosshairRef
;	MessageEx " %n " HexObj
;	return
endif

;if IsKeyPressed2 81 == 1 && doOnce2 == 0
;	set doOnce2 to 1
;	return
;elseif IsKeyPressed2 81 == 1 && doOnce2 == 1
;	return
;elseif IsKeyPressed2 81 == 0 && doOnce2 == 1
;
;	if consoleOpen == 0
;		Message "ConsoleOpen Turned ON", 5
;		set doOnce2 to 0
;		set distH to 28
;		set distF to 56
;		set consoleOpen to 1
;		return
;	else
;		Message "ConsoleOpen Turned OFF", 5
;		set doOnce2 to 0
;		set consoleOpen to 0
;	endif
;endif

if IsKeyPressed2 82 == 1
	set doOnce to 0
endif

End

; //////////// CONSOLE CURSOR //////////// /////////////// ///////////////


Begin MenuMode

if consoleOpen == 0
	return

elseif consoleOpen == 1

	if doOnce == 0
		set pcX to player.GetPos x
		set pcY to player.GetPos y
		set pcZ to player.GetPos z
		CursorObj.setPos X pcX
		CursorObj.setPos y pcY
		CursorObj.setPos z pcZ
		HexObj.setPos X pcX
		HexObj.setPos y pcY
		HexObj.setPos z pcZ
		set defCurX to GetCursorPos x
		set defCurY to GetCursorPos y
		set doOnce to 1
		return

	else

		if defCurX == GetCursorPos x && defCurY == GetCursorPos y
			return
		else

			set defCurX0 to GetCursorPos X
			set defCurY0 to GetCursorPos Y

			set kX to defCurX - defCurX0
			set kY to defCurY0 - defCurY

			if player.GetDistance CursorObj <100> 100 && player.GetDistance CursorObj <300> 300
				set nk to 3
			endif

			set kX to ( kX * nk )
			set ky to ( ky * nk )

			set pcX to CursorObj.getPos X
			set pcY to CursorObj.getPos Y

			set kX to kX + pcX
			set kY to kY + pcY

			CursorObj.setPos X kX
			CursorObj.setPos Y kY

			set chX to HexObj.GetPos x
			set chY to HexObj.GetPos y

			set defCurX to GetCursorPos x
			set defCurY to GetCursorPos y


			if kx > chX - 45 && kx <chX> chy - 45 && ky < chy + 45
					return

				else

					if ky <chy>= chy + 45
						HexObj.setPos x chx
						set chy to chy + 90
						HexObj.setPos y chy

						return
					endif

				endif

			elseif kx <chX>= chy
					set chx to chx - 90
					set chy to chy + 45
					HexObj.setPos x chx
					HexObj.setPos y chy
					return

				elseif ky <chy>= chX + 45

				if ky >= chy
					set chx to chx + 90
					set chy to chy + 45
					HexObj.setPos x chx
					HexObj.setPos y chy
					return

				elseif ky < chy
					set chx to chx + 90
					set chy to chy - 45
					HexObj.setPos x chx
					HexObj.setPos y chy
					return
				endif

			endif

			return

		endif

	endif

endif



End

CursorObj is the in-game 3D object you control with 2D cursor behaviour, though I guess the 2D behaviour part isn't in this particular script. HexObject is the in-game 3D hexagon symbol you see below your 3D cursor, pretty much like in FO1/2.

 

[Vault Dweller]

I was also surprised that VD went with a square grid, saying they couldn't implement a hexagonal grid, because implementing one in OB/FO3 with mere scripting was so damn easy.

When did I say it? The first thing we did was the hexagonal grid. Unfortunately, there were some issues with Torque (related to map objects, not the grid) and we had to go with a square grid.

The hexagonal grid is obviously superior due to the freedom of movement in any direction.

 

[mondblut]

Squares. They have 8 directions to work with (squares without diagonal movement shouldn't even be discussed, of course), they map on keypad, and movement across them in all primary directions looks natural.

Hexes only have 6 directions, do not map well on keyboard, and either horizontal or vertical movement, depending on their direction, is fucked up.

 

[rpgcodexusername]

I find it difficult to read others code,

It seems you are moving a hex-cursor to a certain place depending on where the mouse is,
lots of temp variables make it kind of difficult to understand

 

[DraQ]

I prefer squares, as long as diagonal movement counts and just one.

That's my foremost problem with squares. Diagonal movement is a deal breaker for me. Damned if it counts one, damned if it doesn't.

This.

 

[Double Ogre]

Squares, obviously. I thought the only reason hexes were used in Fallout was to lessen the amount of art needed, as the developers had to render character sprites in only 6 rotations instead of 8 that squares would require.

 

[BearBomber]

I prefer squares, as long as diagonal movement counts and just one.

That's my foremost problem with squares. Diagonal movement is a deal breaker for me. Damned if it counts one, damned if it doesn't.

This.

 

[Helton]

If you can move diagnol aren't you really dealing in octagons?

 

[Captain Rufus]

Neither. Give me miniatures style, 360 movement.

But failing that hexes are nice. Even if my favorite strategy series of the last decade used squares. (Advance Wars)

 

[Zomg]

Fools don't know how to regularly tessellate no octagon.

I bet there's a wargame that uses a triangle grid that I've heard of but not played.

 

[porchsitter]

What's wrong with free movement?
When the PC is selected draw a bunch of concentric circles on the ground and move to any point on a particular circle for x AP.
I believe most game engines provide functionality to dectect the world location of an object you clicked, and if your terrain has constant elevation it wouldn't be too hard to do the math yourself

 

[denizsi]

I was also surprised that VD went with a square grid, saying they couldn't implement a hexagonal grid, because implementing one in OB/FO3 with mere scripting was so damn easy.

When did I say it? The first thing we did was the hexagonal grid. Unfortunately, there were some issues with Torque (related to map objects, not the grid) and we had to go with a square grid.

The hexagonal grid is obviously superior due to the freedom of movement in any direction.

I've misinterpreted then. Must have been tricked by my memory once again. What kind of issues were there with map objects?

By the way, you can also try to point out the negatives in either, whether it's your favourite or not.

What's wrong with free movement?
When the PC is selected draw a bunch of concentric circles on the ground and move to any point on a particular circle for x AP.
I believe most game engines provide functionality to dectect the world location of an object you clicked, and if your terrain has constant elevation it wouldn't be too hard to do the math yourself

That's an option, but irrelevant to the subject, ie. grids. I do believe free movement can be an interesting addition to the world of TB, as the videos I've seen of the TB PS3 game Valkyrie Chronicles feature more or less what you like, but free movement would probably screw up tactical calculations in short distance and also combat encounters in VC for PS3, judging from the videos, seemed to cover lots of long distances.

For short range, players should be able to have a clear and precise idea of what can be done in the environment that can't be exploited with float-point movement, I think.

 

[Rosh]

What's wrong with free movement?
When the PC is selected draw a bunch of concentric circles on the ground and move to any point on a particular circle for x AP.

This is something I've seriously been looking into and working with, with concentric range circles to denote reserved time for actions like adopting cover/lying low, preparing an interrupt shot, all that fun stuff. The problematic part would be obstacles/corners and recalculating around them, but it really isn't too difficult when you first project to that obstacle and then recalculate the rings beyond that obstacle from around that point.

 

[shihonage]

Right now I use squares (8-directional movement) unless there's combat. Those participating in combat are limited to 4 directions in order to avoid the diagonal "cheat".

Still working on it.

 

[zenbitz]

I actually don't think it matters too much.

Hexagons were used in table top games because you can "count" range without a ruler. If you can have 8 orientations on a square, you can have 12 on a hex grid (I have a couple table top wargames that use this "vertex vs. face" orientation)

For diagonal movement, just multiply movement costs by sqrt(2), or distort the artwork.

 

[Sovy Kurosei]

Having experience with using designing a hexagon-based game (shameless picture plug) it isn't complicating to program for. Infact hexagons is almost exactly like squares as far as the computer is concerned. The only difference is that the rules for what defines a neighbor cell is different for squares than it is for hexagons. They both use a grid.

There are pros and cons to using hexagons, squares and free movement. Ultimately the designer should pick the proper system that works best for the gameplay. It really depends on just how complicating you want movement to be in the game. And just because something is complicating and accurate doesn't mean it is more fun to play than something that is simpler.

 

[Redlands]

(shameless picture plug)

Have you done any more work on this, or is it languishing in limbo?

 

[Sovy Kurosei]

It's dead, Red.

 

[Double Ogre]

If you can have 8 orientations on a square, you can have 12 on a hex grid

12? How is that possible?

 

[Redlands]

It's dead, Red.

If you can have 8 orientations on a square, you can have 12 on a hex grid

12? How is that possible?

Across the 6 edges and 6 vertices, I guess. Similar to how you can go over the corners of the squares to get 4+4=8.