More mapping musings
Replying to Alex Schroeder's blog (http://www.emacswiki.org/alex) where he says that creating a Little Language for map description must have been a lot of work:
The funny thing was that writing the map generator and then entering the data for the features took no more time and was WAY less frustrating than trying to scan the map in and then edit it so it didn't suck with Inkscape or Adobe Illustrator. Plus, once it was even sort of working, feedback was immediate, because I could just emit the map and hit reload on a browser tab (Safari, Opera, and Firefox, at least, all have native SVG support). That was handy when I put corners in the wrong place, which happened a lot.
It's a classic Raymondesque Little Language approach.
I think I've run into its limitations, though. For starters, doing caverns with it is going to be hard, but would be necessary if I were to make this work for the other levels of the dungeon. I have a sort-of-design in my head to do caverns by mapping an arc between points and then walk a....well, let's be honest and call it a turtle...along it introducing random perturbations with a bias depending on how far the turtle is from the arc (to rubberband it back to the path, so the wiggliness is bounded). But if I do this it's going to create a HUGE SVG file, and doing it for closed (possibly filled) polygons may turn out to be a humongous pain.
And then there's something I ran into with the features like tables, coffins, toilets, ovens, spiral stairs in the map: what I really want to do is just define each of these as an SVG entity, and then plunk it down on the map with a location, rotation, and scale. At which point, suddenly, I have semantics rather than just a series of strokes...and I'm well on my way to creating a CAD system with a CSV user interface, which, well, I don't think I want to go there.
Thing three is that I'm just about to have to read and understand the SVG spec. I got this far by cargo-culting, but then a couple days ago I got interested in the question of why Safari and Firefox rendered differently, and determined that I was using the dasharray attribute incorrectly (needed commas) and that text-size had to be outside the style tag (I don't know if that is actually necessary but it seems to make it work with Firefox). Now, it could be argued that if I do that, I will be a happier camper--among other things, I maintain the Linux CLI port of Inform 7, which currently emits EPS files, and I bet that if I learned enough SVG to build my maps, I could make Inform emit SVG easily too--but, hey, I got a day job.
Wow. This turned into quite a treatise. I think I ought to put it up on my own blog too. (Which, if you're reading it here, I did)
Adam
The funny thing was that writing the map generator and then entering the data for the features took no more time and was WAY less frustrating than trying to scan the map in and then edit it so it didn't suck with Inkscape or Adobe Illustrator. Plus, once it was even sort of working, feedback was immediate, because I could just emit the map and hit reload on a browser tab (Safari, Opera, and Firefox, at least, all have native SVG support). That was handy when I put corners in the wrong place, which happened a lot.
It's a classic Raymondesque Little Language approach.
I think I've run into its limitations, though. For starters, doing caverns with it is going to be hard, but would be necessary if I were to make this work for the other levels of the dungeon. I have a sort-of-design in my head to do caverns by mapping an arc between points and then walk a....well, let's be honest and call it a turtle...along it introducing random perturbations with a bias depending on how far the turtle is from the arc (to rubberband it back to the path, so the wiggliness is bounded). But if I do this it's going to create a HUGE SVG file, and doing it for closed (possibly filled) polygons may turn out to be a humongous pain.
And then there's something I ran into with the features like tables, coffins, toilets, ovens, spiral stairs in the map: what I really want to do is just define each of these as an SVG entity, and then plunk it down on the map with a location, rotation, and scale. At which point, suddenly, I have semantics rather than just a series of strokes...and I'm well on my way to creating a CAD system with a CSV user interface, which, well, I don't think I want to go there.
Thing three is that I'm just about to have to read and understand the SVG spec. I got this far by cargo-culting, but then a couple days ago I got interested in the question of why Safari and Firefox rendered differently, and determined that I was using the dasharray attribute incorrectly (needed commas) and that text-size had to be outside the style tag (I don't know if that is actually necessary but it seems to make it work with Firefox). Now, it could be argued that if I do that, I will be a happier camper--among other things, I maintain the Linux CLI port of Inform 7, which currently emits EPS files, and I bet that if I learned enough SVG to build my maps, I could make Inform emit SVG easily too--but, hey, I got a day job.
Wow. This turned into quite a treatise. I think I ought to put it up on my own blog too. (Which, if you're reading it here, I did)
Adam