Wargame+Roguelike+Terminal=???

[Omnivore]

  Ok, my art skills are lacking even for hacking 12x12 fonts 

Anyhow, I'm wondering if anyone has done this and if they have some decent fonts to share?   For something like cp437 it only requires replacing two glyphs, of course it works best with square font sizes.  It is a bit expensive on real estate in a terminal, basically you need double the number of rows and columns.  I don't expect that to be much of a problem on anything but mobiles.

[mushroom patch]

I'm going to guess that what you mean by "this" is representing a hexagonal grid in a standard terminal.

Yes, there is a good way to do this. Use fullwidth unicode characters (which are supported by any terminal your user is likely to have available). These are characters, including (most of ?) the standard ascii ones, that occupy two adjacent terminal cells and are represented (usually) as centered version of the corresponding ascii character.

Now use these, but stagger them line by line so that there is an alternating pattern of offsets of one cell. Let's see if I can make this happen in a code display on the forum...

Code: [Select]

ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
 ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
 ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
 ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
 ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
 ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
ＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ
etc.


Well, it doesn't render very well on my browser, but it would look better in an actual terminal. The point is that you can see how the pattern realizes the same notion of adjacency you have in a hexagonal tiling and it's reasonably visually faithful.

If you care about the orientation of the hexagons for some reason, the termcap library documentation claims that some devices support a half-line offset for subscripts and superscripts, although they say this is a feature of line printers primarily, but it could be that some modern terminal emulators support such a thing. I've never looked into it. If you had such a capability, you could play roughly the same game as above, using column offsets instead.

[Omnivore]

Thanks for the tip, I never explored deeply enough into unicode to discover that.  I could just as easily use a 'pointy' end up hexgrid display (use the extended-ascii vertical line along with two custom glyphs) running in the 'enhanced' local display on BearLib terminal, then easily switch to the unicode scheme you've shown for telnet.

The concern I have with just doing the unicode scheme (or similar) is usability, seems that others who have tried similar layouts without explicitly showing the grid lines found users became rather confused.  With BearLib Terminal, I had the idea of using a refined version of the image I posted as the development display, and then using the capabilities of adding layers and images above and below (background/foreground) to gradually implement a graphics version.  It becomes a bit more viable an approach now with the addition of unicode offsetting to avoid needing custom fonts for telnet users.

[mushroom patch]

In my opinion, the interface downside of hex grids is, as you say, significant, if the main mode of interaction is the keyboard. People seem willing to learn wasd type controls for first person shooters etc. They may be willing to learn a similar hexagonal scheme, maybe weadzx. I wouldn't bet on it though.

[Cfyz]

I could just as easily use a 'pointy' end up hexgrid display

They may be willing to learn a similar hexagonal scheme, maybe weadzx.

That is the problem with pointy-end-up hexagon orientation. Using qw-ad-zx keyboard layout is a real pain: they are not on the same vertical line and require a big upward-downward finger movements. A much better layout, in my opinion, would be qwe-asd: keys are located closely, it is possible to use three fingers instead of two. And it also may be mapped to the usually useless ins-home-pageup-etc. keys, to keep normal keys free and simultaneously move navigation to a pretty usual right-hand arrows area. It does, however, require flat-end-up hexagon orientation. In this sense, the variant from the first post is a good one.

Use fullwidth unicode characters (which are supported by any terminal your user is likely to have available).

I'll be honest, I think you are abusing the "real rerminal" approach. Under Windows, the only noticeably popular terminal emulator is PuTTY and it does not seem to support fullwidths (maybe because available fonts does not include fullwidths and no fallback used? what would be the correct way to check feature support?). With using certain terminal features being unreliable, what is the point using peculiar and restrictive curses API and then require extra software and/or configuration? Unless the telnet-friendliness is a key feature of the game, of course, I do understand that.

[chooseusername]

what would be the correct way to check feature support?

I once tried to come up with a protocol to work out which terminal program, or telnet client was being used, to connect and detailed it here.  It's definitely possible to detect Putty, and other high class terminal programs.  You just need to work your way to it depending on how many badly implemented telnet programs you wish to support as well.  If I correctly, my roguelike mud would detect what the client was and knowing it supported unicode, would use that rather than the graphical characters.  Eventually I ended up using a Chinese language version of Windows and even when I'd injected English into it, Putty was never able to get decent unicode characters and I ended up stabbing myself in the eyes repeatedly with a used needle to try and forget the pain.

Last I looked Putty also looked awful for a Roguelike, as it had antialiasing set to a mode by default (on?) where it distorted the shapely characters like the blocks.

[mushroom patch]

Putty works with fullwidth characters on systems I've tried it on. Admittedly, that's not a lot of systems.

[vultures]

To draw it in OpenGL through Simple Media or any other layer, you'd be best off with the most exact visualization, which is - math.

The most common and, unless you're a prodigal mind capable of drawing perfect natural shapes by hand, the easiest way is via any function capable of drawing circles. You call that function to intersect one, central oval with another six. These six intersecting points are called anchors, and they are relative to your canvas. The latter is, for this example only, the wholesize of your map. Focusing your effort into anchor points is essential because you should be able to use your ViewPort() function to zoom in and out, display minimap or just use scroll as most turn-based strategic games do. Even though it's obvious, the most important anchor point is the central one which adds up to the existing six to use with ViewPort().

This type of grid allows for better item flow across the map and, if used properly, a ton of map items with very few slowdowns.

[mushroom patch]

. . .

[vultures]

I know, m_patch but - most of the emulated consoles nowadays support overlays and OpenGL 2.0 is needed to do so.
I've just expanded on the discussion, outlining what the header file for the object (which is to show the actual hex grid) should be doing. Needless to say, you can make everything else display in a way that resembles native console.

Back to the core discussion at hand.