I'm working on a system so that maps can be generated usng raw code in a wiki, rather than relying on an expert with map editor skills. And it occurred to me that every hex is made up of a number of elements:

Some of these will be hard to implement, but I think by using precision css image placing and alpha transparent png files, a lot of it can be done. I'm thinking every base image could be encoded by a three letter code which will then be parsed by the wiki. The first letter will encode the background colour, the second a dingbat (which may be context-variable on the background colour), the third a river/coast layer.

For a (relatively) quick example, you could use the GIMP brushes posted by birchbeer. In theory, an even better solution would be to use SVG (e.g., an SVG-edit extension or plugin with vector hexes and a hex grid).

From a technical point of view, the background and dingbat are relatively easy to implement and encode in text. However, rivers and coastlines would be rather difficult to do properly, unless one accepts a lot of straight lines instead of curves, or implements something much more complex.

agathokles wrote:For a (relatively) quick example, you could use the GIMP brushes posted by birchbeer. In theory, an even better solution would be to use SVG (e.g., an SVG-edit extension or plugin with vector hexes and a hex grid).

SVG would probably be better, especially since modern browsers should support it.

From a technical point of view, the background and dingbat are relatively easy to implement and encode in text.

Each hex would have to be numbered with a toggle-able overlay for identification with its wiki-source since the wiki text can't exist in the same grid shape. Even if you started out the text like

you'd start to have positional problems unless you made each layer excluding water (land, feature[coral, magic point, etc], city, roads, text) as its own text hex "grid" then make the html/svg maps into layers. Hmm. Never mind, I guess it could be done, but whitespace would matter...

However, rivers and coastlines would be rather difficult to do properly, unless one accepts a lot of straight lines instead of curves, or implements something much more complex.

This is the kicker (along with borders, plateaus, etc). You could express them in complex mathematical formulas, but it might be best to have coastlines be an SVG overlay from the start so that the wiki-using folk just input hex data. Assuming this is for Mystara, there is the benefit that we already know most of the coastlines (although past and future versions are unknown). Basically, whoever starts a project draws up some coastlines in an SVG editor and make that the starting point for others

That's the first letter. The second letter would encode a dingbat. This might need to vary depending on the context of the first letter.

For a river, we know it must start in one hex side and end in a hex side (possibly the same hex side). That's 36 possible graphics. We can further say that the path will make either a short route within the hex or a long route within the hex, making a total of 72 standard river graphic overlays to be made.

Coast graphics would require 144; the pathway would be described as for rivers, but an additional question of which side of the wandering line is the high ground would need to be made. Effectively, they form an overlay graphic in "coastline blue" that would be placed over a land hex.

Deeper levels of water would be represented by different colour water hexes. Again, in order to make for nice patterns of transition, a set of 144 tiles per isodepth boundary line to be drawn would be needed. These would work identically to the coast graphics in general usage.

One limitation of such an engine for drawing coasts and ocean depth isodepth lines is that you can't have more than one in a single hex.

I have a feeling that the code for a river/ocean overlay graphic would need to be quite long. <aybe a TLA of its own:[start hex side 1-6], [end hex side 1-6], [route descriptor code]

Ashtagon wrote:Hmm, I suspect this probably falls into teh realms of technically doable, but the end-user interface would probably be worse than just teaching someoen to use a decent map making app.

That's pretty much my thought, too. Even before you get into the complexities of making curved paths appear on the grid, it would be very time-consuming to put together maps. You'd need to build an editor, really.

It's an interesting concept, but it would require a lot of development work to implement it.

A long time ago, I wrote an editor for Bard's Tale style maps (very similar to TSR offerings of the time in appearance), using javascript. I could edit maps and render them (surprisingly fast too, given the computers of the day). It would also generate code that could be copied and pasted into data files (javascript lacks that kind of functionality).