Closed leftiness closed 7 years ago
one hex
/ \
| . |
|\ /|
\|/
tiled
/ \
| . |
|\ / \ / \
\| . | . |
/ \ / \ / \
| . | . | . |
|\ /|\ /|\ /|
\|/ \|/ \|/
stacked
/ \
| 1 |
|\ /|
|\|/|
\|/
stacked tiled
/ \
| 1 |/ \
|\ /| . |
|\|/ \ /|
\| . |/
|\ /|
\|/
Rendering ascii art might be harder than drawing sprites. Game/editor need a renderer. May as well get started on it. Renderer takes a collection of hexes and draws them as sprites. More complicated rendering includes lighting, animations, etc. Not sure where user input fits in. The point is that some basic renderer would be more useful than a wasted ascii art generator.
Not in scope for hex math library.
Travel() is the easiest function to consider. Distance() isn't so bad. Range() is getting harder. As these functions get more complex, they're harder to visualize. Trying to determine if there is a bug in the logic which draws line of sight will be very difficult without writing some code for visualization.
It doesn't have to be complex. I'm thinking that I could write something which takes an input set of prisms and renders it as ascii art.
Height differences could be handled in different ways. The easiest would probably be to put a range of height numbers inside the drawn hexes. So it would be drawn from the top down, and a point which is the only drawn point at that QR point would have its QRT coordinate values: (1, 2, 5). The way to convey a coordinate with multiple hexes at different heights would be with QR[T]: (1, 2, [3,4,5]). That's interpreted as an array of QRT values: [ (1, 2, 3), (1, 2, 4), (1, 2,5) ].
I was thinking that eventually I'd like to include images in my docs. Those would be game images eventually. Rendered as proper sprites. In the meantime, maybe I could use something like this ascii visualizer because, again, it's hard to understand a series of point values without a picture.