Tile shape, maybe plusses?
 David Buunk
 Posts: 78
 Joined: Thu Jun 22, 2017 4:46 pm
 Location: Netherlands
Tile shape, maybe plusses?
So here is the argument between squares, and hexes, summed up:
For squares the concept of neighbour is ambiguous. Does it have 4, does it have 8? Hexes don't have this problem. Neither option feels satisfactory.
Finding the neighbours is a little simpler for squares than for hexes, but the difference is minimal.
Finding longer distances/shortest path will be rather complex anyway, as you'll need to take into account map projection, terrain difficulty, roads and navigable rivers. So the difference between squares and hexes won't matter all that much.
So what is the problem with hexes? Graphics! Hexes are made up of triangles, which can be made up of smaller triangles in a regular fashion. Graphical displays, on the other hand, use squares. So using hexes creates a sort of "putting a square peg into a triangular hole" problem. You have a sprite of a hex. The parts of the sprite that don't belong in the hex are transparent. Now you can just add all the sprites together, slightly overlapping, but the transparency assures that every pixel comes from one welldefined tile. So far, so good. But now we want to zoom out a little. We scale all our tile sprites, and boom, the edges are all fuzzy. Also, since the width and height of a hex aren't equal, or have neat ratio, and you start adding them in at whole coords, you'll end up with small gaps or overlaps between tiles.
Now you say: we just assume this is so minor that nobody will notice, or try to fix it in code. (Must be possible, lots of games use hexes.) But I had a different, crazy idea that I wish to share.
Big plusses, looking a bit like:
O X X O
X X X X
X X X X
O X X O
Where X is part of the tile, and O is transparent. This is something made out of squares (easy graphics) that behaves pretty much as a hex on the larger level. It has 6 neighbours, and while the distances aren't exactly equal, they are near enough. (3.6 vs 4). Coordinate system and algorithms for hexes apply. Best of both worlds?
Now, I didn't take aesthetics into account. And maybe I forgot arguments for either side, if so, please make me aware of them.
For squares the concept of neighbour is ambiguous. Does it have 4, does it have 8? Hexes don't have this problem. Neither option feels satisfactory.
Finding the neighbours is a little simpler for squares than for hexes, but the difference is minimal.
Finding longer distances/shortest path will be rather complex anyway, as you'll need to take into account map projection, terrain difficulty, roads and navigable rivers. So the difference between squares and hexes won't matter all that much.
So what is the problem with hexes? Graphics! Hexes are made up of triangles, which can be made up of smaller triangles in a regular fashion. Graphical displays, on the other hand, use squares. So using hexes creates a sort of "putting a square peg into a triangular hole" problem. You have a sprite of a hex. The parts of the sprite that don't belong in the hex are transparent. Now you can just add all the sprites together, slightly overlapping, but the transparency assures that every pixel comes from one welldefined tile. So far, so good. But now we want to zoom out a little. We scale all our tile sprites, and boom, the edges are all fuzzy. Also, since the width and height of a hex aren't equal, or have neat ratio, and you start adding them in at whole coords, you'll end up with small gaps or overlaps between tiles.
Now you say: we just assume this is so minor that nobody will notice, or try to fix it in code. (Must be possible, lots of games use hexes.) But I had a different, crazy idea that I wish to share.
Big plusses, looking a bit like:
O X X O
X X X X
X X X X
O X X O
Where X is part of the tile, and O is transparent. This is something made out of squares (easy graphics) that behaves pretty much as a hex on the larger level. It has 6 neighbours, and while the distances aren't exactly equal, they are near enough. (3.6 vs 4). Coordinate system and algorithms for hexes apply. Best of both worlds?
Now, I didn't take aesthetics into account. And maybe I forgot arguments for either side, if so, please make me aware of them.
Programming SotE.
Re: Tile shape, maybe plusses?
I'd go with classic squares. I liked uniqueness of plus shape until I tried to imagine straight line. I think that for simplicity sake squares are best
Re: Tile shape, maybe plusses?
Yeah Pelpel, I'm inclined to agree. Plus it causes a lot of problems with edge effects, because when the crosses lock together in a grid they don't have uniform perimeters with their neighboring crosses. In general its a lot of confusion. It may just be that squares are the best way to go with the first iteration of the game. It's what people are most used to, the geometry and coordinates are super simple when you are procedurally generating the map.
Re: Tile shape, maybe plusses?
I'm a little surprised nobody mentioned an offset square grid
You have the graphical ease of squares, with the visual and mathematical/geometric simplicity of a hex grid, without having to try to reinvent the wheel.
I'll be honest, the cross idea seems to just have the problems of both with few of the advantages.
As for my 2cents on square v hex (which include offset square and the cross implementation both as hex) I personally prefer hex based. When using square based there will always be questions about diagonals: and this applies on every level, for movement comes the question of it's move cost (is it 1 or 2 or 1.5 or even 1.4); if there are going to be visible boundaries it will matter graphically; distance formulae need to be pinned down (do we use Pythagorean distance, or Manhattan distance) and you have to make sure everyone and everything uses the same system, assuming all mechanics can use the same maths; plus whichever way of doing it use will cause mathematical weirdness, or at least more egregious examples than hex based.
You have the graphical ease of squares, with the visual and mathematical/geometric simplicity of a hex grid, without having to try to reinvent the wheel.
I'll be honest, the cross idea seems to just have the problems of both with few of the advantages.
As for my 2cents on square v hex (which include offset square and the cross implementation both as hex) I personally prefer hex based. When using square based there will always be questions about diagonals: and this applies on every level, for movement comes the question of it's move cost (is it 1 or 2 or 1.5 or even 1.4); if there are going to be visible boundaries it will matter graphically; distance formulae need to be pinned down (do we use Pythagorean distance, or Manhattan distance) and you have to make sure everyone and everything uses the same system, assuming all mechanics can use the same maths; plus whichever way of doing it use will cause mathematical weirdness, or at least more egregious examples than hex based.
 David Buunk
 Posts: 78
 Joined: Thu Jun 22, 2017 4:46 pm
 Location: Netherlands
Re: Tile shape, maybe plusses?
Xelada, thank you for your suggestion. I should have though of that. When it comes to implementation it is pretty much equivalent to the plus idea, except that the final version of the plus also has equal perimeter with each neighbour, as well as almost equal distances between tile centres to neighbouring tile centres.
Also, we'll be using Pythagorean distance, as we will want it to be accurate above all.
For everybody, this was discussed in the stream, and this is my summary thereof:
We discussed the various tile shapes.
A strawpoll was held beforehand: http://www.strawpoll.me/13675052/r (Demian and I didn't vote)
The main problem with squares was considered army/pop/trade movement.
But since pop/trade travels on its own, it can move partial tiles with ease.
So it isn't really bound to the tile grid.
And we decided that armies would end up with a different model altogether.
Where it is more spread out, and not in one specific place that the player can move tile by tile.
More details to be decided later.
With the larger part of the problems with the squares out of the way, we decided to go square, and reevaluate after version 1.
Then Demian went to check on the girls.
While he was away, I asked the chat for questions they had.
Then we had 20 minutes of QA session.
But there isn't really anything new said there.
(And 5 people of 18 found my plusses confusing )
Also, we'll be using Pythagorean distance, as we will want it to be accurate above all.
For everybody, this was discussed in the stream, and this is my summary thereof:
We discussed the various tile shapes.
A strawpoll was held beforehand: http://www.strawpoll.me/13675052/r (Demian and I didn't vote)
The main problem with squares was considered army/pop/trade movement.
But since pop/trade travels on its own, it can move partial tiles with ease.
So it isn't really bound to the tile grid.
And we decided that armies would end up with a different model altogether.
Where it is more spread out, and not in one specific place that the player can move tile by tile.
More details to be decided later.
With the larger part of the problems with the squares out of the way, we decided to go square, and reevaluate after version 1.
Then Demian went to check on the girls.
While he was away, I asked the chat for questions they had.
Then we had 20 minutes of QA session.
But there isn't really anything new said there.
(And 5 people of 18 found my plusses confusing )
Programming SotE.
Re: Tile shape, maybe plusses?
I'm not so sure about the stated advantages of the plus shape, I'm not sure what you mean by equal perimeter with each neighbour: two sides have two thirds the shared perimeter of the other four (offset square is kinda the other way round with two sides having twice the shared perimeter) and as for the more consistent distance, we are talking 10% shorter (cross) vs. 12% longer (offset) which isn't a huge difference (well it is, 22% difference is significant but in terms of which is more precise it isn't much).
Hmm... after considering it I have to admit that your cross idea is a much better idea than I first gave it credit for. I still like the fact that offset squares doesn't require transparency or subdividing, but your way certainly has it's merits, not least of which being mathematically more precise.
Also upon further consideration standard square grids do have the advantage of... I'm not sure if there is a name for it, I sometimes call it "supertessellating" where you can make a shape entirely from that same shape (random fact: triangles and parallelograms are the only 2D shapes that have this property). Plus there is nothing that says you can't use a standard square grid for the smaller levels, then use another system for the higher levels.
Hmm... after considering it I have to admit that your cross idea is a much better idea than I first gave it credit for. I still like the fact that offset squares doesn't require transparency or subdividing, but your way certainly has it's merits, not least of which being mathematically more precise.
Also upon further consideration standard square grids do have the advantage of... I'm not sure if there is a name for it, I sometimes call it "supertessellating" where you can make a shape entirely from that same shape (random fact: triangles and parallelograms are the only 2D shapes that have this property). Plus there is nothing that says you can't use a standard square grid for the smaller levels, then use another system for the higher levels.
 David Buunk
 Posts: 78
 Joined: Thu Jun 22, 2017 4:46 pm
 Location: Netherlands
Re: Tile shape, maybe plusses?
Oh, right, I forgot to upload the final plus shape to here as well.
But anyway, this discussion is moot for now, as we've (for better or worse) settled on squares.
But anyway, this discussion is moot for now, as we've (for better or worse) settled on squares.
Programming SotE.

 Posts: 17
 Joined: Wed Aug 23, 2017 1:34 am
Re: Tile shape, maybe plusses?
To keep the plus Idea you could have wilderness change spread in a plus pattern.
 David Buunk
 Posts: 78
 Joined: Thu Jun 22, 2017 4:46 pm
 Location: Netherlands
Re: Tile shape, maybe plusses?
You don't understand. The spread of wilderness is determined by the local circumstances, and the workings of ecology, not the will of the makers of SotE.
Programming SotE.

 Posts: 17
 Joined: Wed Aug 23, 2017 1:34 am
Re: Tile shape, maybe plusses?
The wilderness could only spread to tiles that border it correct. If that is true and we are using square tiles the you can not spread to diagonals beacuse they do not border the square with wilderness forming a plus pattern.
Who is online
Users browsing this forum: No registered users and 1 guest