The game I'm currently working on requires me to assemble and draw an tessellated group of hexagons. The program logic therefore needs to determine:
- The screen coordinates of a given hexagon
- The coordinates of the vertices representing the corners of a hexagon
- Whether or not two hexagons are adjacent
- Whether or not two hexagons are in the same position
- How to rotate a group of hexagons in 60-degree steps around a chosen "pivot" hexagon
This lets me perform my hex-group rotation operation fairly quickly, but presents a problem when I'm trying to determine whether two different locations in the hexagonal grid are adjacent to each other. I'm sort of cheating here by mapping my hexagonal coordinates to X-Y screen coordinates, and then checking the proximity of those coordinates to see if they are sufficiently close to one another to be adjacent hexagons.
My design document (a sheet of scrap paper sitting on my desk) is full of scribbled diagrams showing hexagons and vertices and congruent angles. It's good that all of the time I spent in school messing around with protractors and such is finally showing some benefit, but if I wind up designing a game that requires some calculus, I'm just going to integrate someone's math library. I honestly never want to see another integral sign again.
No comments:
Post a Comment