Very cool! Kudos - a ton of work obviously went into this, and I'm a sucker for vector-based graphics.
It will be interesting to see if this way of building a map is easier for people to use than the bitmap-based apps that have come before. I suspect that ultimately the map artist is going to do a similar amount of work, but if this way is more intuitive/usable than others, so much the better.
People will want to know if their HexDraw maps can be used in VASL. The answer is kind of detailed.
ANY map can be used in VASL, as long as it's packaged in the way that VASL expects. That is, it needs to be a gif with the name
bdX.gif, where X = whatever you want, and packaged into a zip archive file (no compression, and with the .zip extension removed, like
bdX) along with a file called
data (no extension) that can be empty, but is generally used for version information.
If you want VASL to understand the coordinates of your map, you need to either use a gif of standard size (1800x645 pixels for a geomorphic map) or tweak the
data file by adding dx,dy parameters that basically tell VASL how far apart your hex dots are spaced. HASL maps often use these.
If you want VASL to use its cool terrain-changing capabilities for your map (turning the ground white in snow, etc), then you need to ensure that VASL understands what your map's colors are. The easiest way to do this is to use the standard set of colors that come prepackaged with VASL boards.
Another option is to add a
colors file to the
bdX archive, which basically overrides VASL's colors with ones of your own choosing. This works fine, but you may also want to tell VASL how your board's colors should change according to the various conditions such as Mud, Winter, etc. In that case, you'd need to create a
colorSSR file that does this, and include this file in the
bdX archive.
It gets complicated, but it's all described in the Ye Old Booke of VASL Mapmaking Secrets:
http://home.comcast.net/~tomrepetti/misc/YoBv6.pdf
OK. How does this relate to HexDraw maps. As a vector-based program, I assume that when HexDraw exports a map to an image file (gif, bmp, jpg, whatever), it has to render each terrain object into a bitmap. Here's where the trick lies - many rendering tools
antialias the result in some way, basically creating shades of color on the edges of an object as a way to enhance the smoothness of the result and avoid the pixellated look of many computer images.
The problem is that VASL really needs to see a limited number of well-defined colors in order to do its color-based transformations. When Winter is in effect, it looks for a specific shade of green for its Level 0 Open Ground and turns it into white. It looks for specific Red/Green/Blue pixels for Grain and turns them into the (winterized) Open Ground color for whatever level they lie on. Etc.
So while HexDraw output can easily be converted to some kind of gif that VASL will read, it'll take a bit of tweaking to enable VASL's full color-changing abilities for that map. Not saying it can't be done, but it's definitely a processing step that needs to be taken.
One possible solution is to create HexDraw libraries that use VASL-specific colors, but they won't work in VASL if HexDraw antialiases its output when it renders the image. Another solution is to tell VASL to handle the HexDraw colors by using
colors and
colorSSR files as described above, but again, things get hairy if there are lots of colors generated by antialiasing.
Another solution is to simply modify the rendered HexDraw image to use a more limited set of VASL-specific colors (either the preset VASL colors or ones specified by the artist with the
colors and
colorSSR files). The result won't look exactly like the original, but it'll work.
I'd be glad to look at a HexDraw-rendered image file and see what's possible. Ultimately, the Map Elves are glad to have more hands working at the table, and we'll do what we can to enable people's dreams.
Tom