ToME: the Tales of Maj'Eyal

Maybe ToME's geometry should be based on the hexagon.

I don't think it would be difficult to code--probably just do a find-replace, changing 4 everywhere it appears to 6.

So it would be easy, and I bet it would look really interesting. In fact, if it were done, I think there would be a chance ToME could win the Nobel prize for games.

Didn't someone do this for an experimental addon at some point?

yeah some Hell based one.

It worked well from what I understand.

I also believe this was brought up in the past and there was some reason they didnt want to do this

This was the last I can find of it being spoken of.

Apparently its totally doable just need map generation re-written.

The topic died over a year ago, not sure why

http://forums.te4.org/viewtopic.php?f=4 ... n&start=15

See:

http://forums.te4.org/viewtopic.php?f=46&t=30875

http://forums.te4.org/viewtopic.php?f=50&t=33182

http://forums.te4.org/viewtopic.php?f=45&t=35232

http://forums.te4.org/viewtopic.php?f=40&t=34473

http://7drl.org/author/yufra/

Screenshots from Grey's "Rogue Rage":





Screenshots from yufra's 7drls:







Hence, the engine has no difficulty with hexagonal grids. Gameplay and mechanics-wise, ToME can switch between square grids and hexagonal grids just fine. The challenge for making ToME (the game, not the engine) hex-friendly is modifying all the fixed maps so that all areas are connected. It's a bit of work, but it's something that is very doable with an addon.

Holy crap, those look AWESOME.

Somebody do this!

Seconded! This would make a great new way to play the game, and extend replayability, by having a hex mode to play in!

Man, those look just incredible. I can't believe this is already largely done...static maps is the major issue? No need to rework the random dungeon generator?

I wonder how you'd read and store a static map....since you can't just start in the upper-left and go across in quite as simple a way...

MalReynolds wrote:I wonder how you'd read and store a static map....since you can't just start in the upper-left and go across in quite as simple a way...

IIRC, the even (or odd?) numbered columns are just shifted down half a tile.

MalReynolds wrote:I wonder how you'd read and store a static map....since you can't just start in the upper-left and go across in quite as simple a way...

You can, since every hex can be uniquely addressed using only two of the three possible axes.

Here's one example (found via Google Image Search):
https://forums.station.sony.com/ps2/ind ... map.77529/

Oh, it's clear that you can have a system to read and store. That's basic Cantor.

It's just that there are wiggles in the hex-tile lines, y'see.

I looked at your coordinate system image: that strikes me as an odd convention. There's no easy way to know if a coordinate exists; so you would think that C4 would be close to C8; but C4 doesn't exist. Using that image's convention, whether you have a square-bounded map or a hexagon-bounded map, you'd need a formula to determine if a coordinate even made sense. But that convention is interesting, in another way: if your numbers increase like C4,C5,C6, you are going in the first of the "three cardinal directions"; if your letters increase like C4,D4,E4, you're going in the second cardinal direction, and if one increases and the other decreases (as in C4,B5,A6), you're going in the third cardinal direction. Interesting. Sort of like how changing both numbers at once in square coordinates means going diagonally (and the relative signs means which particular diagonal). But sort of simpler, because there are only six directions to go (instead of 8 in square tilings, including diagonals).

I guess I had thought of using square-like coordinates, so you would start in the upper-left, and going horizontally would be fine but as you went vertically, you would zig-zag a little. Since most castles/towns/etc. are built on a square grid, that sort of made sense to me. You'd just need a convention for whether the upper-left was an innie or an outie, so to speak--so whether your first step vertically down took you a bit left or a bit right.

The thing is, it doesn't matter if a coordinate doesn't exist (for pre-drawn maps).

The computer knows every existing coordinate. Thus, validity is a simple table look-up.

You could have arbitrary map shapes & sizes.

For generated maps, yeah, you'd need an algorithm to lay out the borders... or not. You might be able to get away with growing the map from a starting cell, and not really care overmuch about borders.

Rectangular with a bit of a zig-zag is about right. For example, the very first posted image of hex grids in ToME is in Derth:



Movement is actually pretty intuitive when using a numpad (even though most exploration is still done via auto-explore!).

Modifying static maps is the bulk of the work that probably needs done, although one might be able to post-process maps as they're generated to ensure what should be connected actually is connected. The map generators weren't modified, so there is still room for improvement.

Heh, to test it out, you can download beta38 and the addon... although I'm not sure where the addon is on te4.org. You can check out the addon here:

https://gitorious.org/tome4-addons/tome-hex

There are also a few, mostly small-ish improvements that I think could be made to make the hex experience more enjoyable, which I listed here:

http://forums.te4.org/viewtopic.php?p=130089#p130089

Hum, and I don't recall whether FoV can be symmetric for hex grids not. If not, then just a little more work is needed.

I think there have been more smaller modules in development (or 7drls) that have used hex.

So, if people would like to make a tome-hex addon, I'd support the effort! This work wasn't outright abandoned, I just got, well, really busy

Tile graphics would need to be redrawn to get the smoothing working again.

This would be really fun to explore. I can see that it might change gameplay/strategies a bit; being "surrounded" means 6 enemies, not 8; AoE would be slightly smaller because every tile is a bit closer together, as it were: for example, using mucous would cover fewer tiles, etc. If you are putting your back to a wall to limit the number of enemies you face, you could have 3 instead of 5 around you. Interesting.