Hex Grid Prototype Question (Moved to avoid cluttering Tools thread)

[harborpirate]

I realized I might be about to hijack the Tools thread with a side discussion, so I'm moving this question to its own thread.

An offset vertical square grid is easy. You just have to know when you're in an even column and apply a half square offset to the Y axis. You then divide the X and Y coordinates by the square size to get your array coordinates. I was doing that back in the 80's in Turbo C.

I started with offset squares originally. In more recent versions, I rendered hexes using transparent PNGs. The corners of the images overlap. It looked like a real-deal hex layout, and the layers made it really neat.

Here's an example:
HexMapPrototype by harborpirate, on Flickr

As I recall, I got clicking the central portions of the hexes to work. The key issue: Having areas of the hex that were not triggered when clicked caused problems, because it allowed hexes from layers below it to potentially be triggered instead. (The mouse pointer coordinate would "fall through" the empty space I wasn't detecting and hit the "active" portion of a hex in a layer below.)

[zircher]

Ah, that's more challenging fun. The easiest way would be if each hex pillar was an object. It would know where its top face is in screen coordinates and check that against the mouse X/Y. If the mouse is reasonably close, you do a little math and see if the pointer is inside of an oval that covers most of the hex face. It sets a flag or perhaps updates the hex cursor/selector's location. What to do for overlapping hexes? You apply a rule, taller is always better. The only kicker is that hidden/lower hexes can not be selected that way, either you move the hex selector with the cursor keys or add map rotation (aka MissionForce CyberStorm.)

If you don't have a 'smart' map or can't afford the CPU overhead, the other way you can go is to have your hex cursor/selector not controlled directly by the mouse. It instead walks the map array and tries to follow the mouse. Essentially the selector is 'dragged' along the map and gets close as it can while staying on the grid.

[harborpirate]

It occurs to me that object-based detection, while crude, could be somewhat effective if I were culling tiles that cannot be seen. This was a quick and dirty prototype, so I hadn't bothered to do any optimization yet. I think what it did when I had object-based mouse triggering was that it fired for all objects under the mouse pointer, which included all the layers not visible to the user.

This all came up originally because I love destructible terrain. It also makes me appreciate games like SimCity 2000 and XCOM all the more, because even though they didn't have to solve mapping hexes to mouse coordinates, they did have to map to an angled grid, which has a lot of the same challenges.

[zircher]

That would work, you would still need a tie-breaker rule like higher tiles have priority (since they will naturally be the one blocking view of the lower titles behind it.)

[tombombodil]

Sorry I'm way late to this. If you're interested I recommend looking into quad-trees and popular culling algorithms. This stuff is quite a bit more "mathey" and "computer sciencey" than a lot of the things hobbyists like to (spend time figuring out, but it's pretty fascinating and not that hard to get your head around if you've don't any kind of linear algebra or basic tree-traversal math/algorithms.

Most modern games have sophisticated real-time systems for determining what to render, and can calculate based on what the arc projected by the camera hits first, exactly what surfaces and objects the player can interact with.

These systems have become so air-tight in their design that problems they suffer from is usually stuff like numerical drift or other problems that arise from shoddy implementation of the system.