Once we have a grid on the screen, regartless of whether it's a square grid or a hex grid, what we essentially have is a map showing where stuff is.
But, for game purposes, just looking at the map and viewing what it presents is not enough.
We also want to be able to interact with the map in two basic ways:
1. We want to be able to right-click our mouse on a location on the map to ask it to display additional and more detailed information than it's able to display on the face of the map itself.
For example, a square or hex on the map might be green, but if we right-click on that location, it might pop-up a box telling us that there's a pot of gold hidden in the woods and that it's somewhere above ground level.
2. We want to be able to left-click our mouse on a location to issue a command for action.
For example, we might want to instruct our exploration crew to move to and make a careful examination of some particular square or hex.
So, at the most basic level, when we click the mouse, we need to know which square or hex we clicked on.
Quite possibly the most brilliant and exhaustive online treatment of this subject is provided by Amit Patel at:
Amit's site has lots of fun interactive stuff to play with, but it's also rather math-heavy. Even after 30 years as an engineer and ten years as a computer consultant, my eyes started to glaze over rather quickly.
I also need to suggest that all that math may be somewhat like shooting flies with a shotgun: it's messy, and will probably miss the fly anyway...
You see, most of our games are complicated by the fact that they live in the real world, rather that in the ideal world of mathematics.
From the ideal mathematics view, a point takes up no space: it has no dimensions, it only has a location (aka position).
But, from a real (raster graphics) view, a point takes up one pixel; it is one pixel wide and one pixel high.
Even if you're using a vector graphics package for design and calculations, the visual display is still a raster device, and any given point is one pixel wide and one pixel high.
Similarly, from the ideal mathematics view, a line segment has no width; only length.
But, in raster graphics, every line is at least one pixel wide.
Also, in mathematics, a line's length could be 3 units long, 4 units long, or 3.5478664328675 units long, i.e. x units long, x+1 units long, or x.5478664328675 units long.
But, in raster graphics, a line could be displayed as x pixels long, or x+1 pixels long, but nothing in between. Oh, you can calculate it to greater precision, but you can't display it to any precision greater than pixel precision.
For reference, Bresenham's Line Drawing Algorithm provides a living example of the restrictions encountered in trying to display an arbitrary line on a raster display.
So, if real world points and lines take up actual space, how should we allocate them?
What I mean is, if a given point or line takes up physical space, do the points and lines which delineate our squares or hexes belong to only one square or hex, or do they belong to all the squares or hexes they simultaneously touch.
This is admittedly a subjective decision; as the game designers, it's our job to make that decision. In the real world, asking mathematics to make that decision for us would be highly counterproductive.
I would argue that if they belong to all such squares or hexes simultaneously, the math and mechanics of dealing with them becomes horribly complex real quick.
For example, given that real points are 1 pixel wide and 1 pixel high, if our game player happens to click right on that pixel, which square or hex has that player actually clicked in?
We could call that an "indeterminate-click" and ask our player to click again. Our player won't like that, and will soon go looking for someone else's games to play instead.
We could try to develop some sort of algorithm to automatically make that decision for us, but therein lies the "horribly complex" monster once again.
I would suggest that everything would be better if we simply set a convention which says points and lines belong to one specific square or hex only, and which establishes to which square or hex that given point or line belongs.
I've selected what I call the "Upper-Left" Convention for my games.
In the following pages, we'll look at that convention in more detail; first for squares and then for hexes.