3d central Thyatis

A directory of geographical maps for the world of Mystara.

Moderators: Seer of Yhog, Thorf

Re: 3d central Thyatis

Postby Big Mac » Sun Sep 24, 2017 11:08 am

aklanda wrote:
Big Mac wrote:How did you infer height data from Thorf's original 2D map? Did you invent some sort of rules for terrain having slopes?

First thing was to digitalize the map itself. For that I had to analyse the terrain-tiles of Thorf for the amount of black, red, green, blue, cyan, magenta, yellow and black pixels, which are typically for a given tile. The result of the analysis looked like the following excerpt (the last seven numbers do represent the amounts of dots of the named colors, as already stated, the third column holds the info about the average color, which is later used in the 3d map for coloring the hexes):

Code: Select all
                                                                              
1   Capital      &cB77944   3   1   1         183   121   68                                       45   54   0   0   0   41   58
2   Metropolis      &c536F38   3   1   2         83   111   56                                       2   59   3   43   1   2   57
3   City      &c58763B   3   1   3         88   118   59                                       2   62   2   40   1   1   60
4   Town      &c496231   4   1   4         73   98   49                                       1   51   1   50   0   0   50
5   Village      &c5A783C   5   1   5         90   120   60                                       2   63   3   38   1   2   61
6   Palace      &c57743B   7   1   6         87   116   59                                       2   62   3   40   1   1   60


I can provide the full file, but if anybody is really interested, I can update the upload-link of the simulator, so that you can generate your own file(s).


I'm not sure I could do anything with your files to be honest. But there might be some more creative people than me who are able to recreate what you have worked out and use your process on other hex maps.

aklanda wrote:Afterwards I read in the pixel-map of Thorf. Then I entered the x and y-offsets in the software, so that the position I assume for Thyatis (x=0, y=0) equals the position, where you can find Thyatis on the map. Afterwards I had to try out several scaling factors, so that the hexes in the map equal the hex-size I assume in the software:

Image

Then the computer had to read-in any single hex of the map (that is all the pixels in the map, that correspond with a hex). This takes some minutes, but can take up to a full hour with bigger maps (see my later postings).
The pc then compares the read-in amounts of read, green, blue ... with the stored amount for the tiles and thus assigns a tile to read-in hex.

The the pc stores the tile-number for the hex together with the position of the hex. This looks like that:



Code: Select all
x-Position / y-Position TAB tile-number)

0/0   1
-30/-30   38
-28/-30   38
-26/-30   37
-24/-30   37
-22/-30   37
-20/-30   39
-18/-30   39
-16/-30   39
-14/-30   39
-12/-30   39
-31/-29   38
-30/-29   38
-29/-29   38
-28/-29   38
-27/-29   37


The hole map of central thyatis by thus can be store in a file not larger than 30kB.


So does the TAB number represent your inferred height relative to Thyatis? Or is it a label that your program is creating for an individual hex, so that it can call on that number later? It looks like the former, as you have four 37s, six 38s and five 39s. That's a variation of 2 TABs over the area of the map.

If TABs are a "unit of height" there is then the question of how much height 1 TAB is equal to. :)

aklanda wrote:As you may have noticed the file format let you extend you map to any given direction without any problems, as you only specify the koordinates in regard to Thyatis.
You might also extend the file format itself. I could imagine adding a third koordinate z for "highness" and you might also add additional info after the tile set, thus as the name of a city or village. I'd be glad to hear your suggestions to this matter.

But there are also limitations:

1. Without further developed tielset-recognition the recognition of tilesets is not fool-proof. I had to limit the amount of tileset the pc is able to distinguish to about 10 (grassland, hill, mountains, cities etc.). The pc is NOT able to differantiate between a city and a village, as the amount of black pixels is nearly the same in both tilesets.
2. Some maps don't scale well, especially, when you have bigger maps that are assembled from smaler maps

The last step was the making of the 3d map, which was quite simple. I just had to read-in the generated map, create for any given location the 6 points of the hex as 3d-points and elevate them accordingly to the tileset. I only had to make sure, that "sea" alwasy stays sea-level and add some random-alternation for the other tilesets.


I can see that you have a process here and that it works again and again, when you stick in more maps. If you are comparing hexes with other hexes to infer the height, I can see how adding more hexes would cause you to need to make more comparisons. And if the TAB numbers are generated from hex colours, I can see how a big map might cause potential disputes in the interpretation. So that might make the process take longer and longer, if areas are expanded and cause computing time to get bigger and bigger.

Do you have problems with edges? On the edge a map, you have a cut-off of data, so if you are inferring TABs from their surroundings, I can imagine that the loss of data would potentially cause problems for edge hexes.

Do you get the same results if you rerun this process multiple times? And do you get similar results if you chop up maps in different ways, run your process and compare the results?

aklanda wrote:If you need any further info, like:

1. Some of the files stated above
2. The code-snippets for tileset-recognition or creating the 3d map
3. The created 3d-files (in obj-format, which is importable by blender. e.g.)

Just tell me.

If you want to make the process by yourself, just drop me a note. I can update the download link to my software, so that it also includes the part that allows the 3d- map-making.


Thanks for the two offers. Like I said above I'm not sure I could do anything with your work.

But I do find this sort of thing interesting.

I've been following the work of Anna Meyer, who spent over ten years making a 3D model of Greyhawk. I've seen her map get bigger over time and I've seen the quality of her map get better over time.

I've also been following Thorf, when I can. He has been doing some amazing mathematical 3D work on figuring out the implications of the size and shape of the polar openings on Mystara and how the influence the Known World and Hollow World maps.

Now here you are doing something new. And it looks like you are still fairly close to the start of your process (so I've not missed all the fun) and you are learning stuff and making your process involve. I'm not sure exactly where you are going to go with this, but I can see it's got legs and it's galloping off in some sort of direction. :cool:

aklanda wrote:BTW: I would like to ask you some questions, as this seems the right place to ask them:

1. The file-format of the map-file seems rather natural to me. But maybe I missed something, should add something or anyone knows about a canonical file-format that is already present?
2. As stated, the recognition of the tilesets is not always reliable. Should I implement a way to modify the map after it was automaticly created by the pc (That is, modify/correct hexes)? This would take some time, but if anyone wants this feature, I can give it a try.
3. As stated, the height of the points in the 3d map is created by the pc in accordance to the tileset. I can try to make them editable (though this may be the toughest thing to implement), if there is need for it
4. I enumerated the tilesets, as the tilesets of Thorf suggest. That is "1" for "2" for metroplolis" and so on. Is this an acceptable way or is there already another enumeration?

Thanks in advance for helping with my questions!


If you want to discuss potential formats for 3D mapping, that seems to be a separate topic to an individual map for a 3D Central Thyatis. It might even be something that goes beyond Mystara that could help fans of all RPGs. So you might want to consider making a separate topic. :)

I think that you need cartography experts to give you their opinion on this. I'll see if I can cast the Summon Cartographer spell on Anna Meyer and/or Thorf. ;)
David "Big Mac" Shepheard
Newsflash!: The Piazza is moving!
Please join The Piazza's Facebook group, The Piazza's Facebook page and The Piazza's Google + community so that you can stay in touch.
Spelljammer 3E Conversion Project - Spelljammer Wiki - The Spelljammer Image Group.
Moderator of the Spelljammer forum. My moderator voice is green.
User avatar
Big Mac
Giant Space Hamster
 
Posts: 21328
Joined: Sun Jun 15, 2008 3:52 pm
Location: London UK

Converting 2D maps to 3D maps

Postby aklanda » Tue Sep 26, 2017 1:45 am

Hello Big Mac,

thanks for your interest. Before writing more about it, I first have to say, that I am no native speaker, so my answers might not be as precise as they could, as I sometimes don´t know how to express myself. But I will try my best.


Big Mac wrote:I'm not sure I could do anything with your files to be honest. But there might be some more creative people than me who are able to recreate what you have worked out and use your process on other hex maps.


Well, to be fair, I tried to explain it very technically and didn´t even supply all the info you need to understand it. I will try to make it better right now:

Pixel-maps (as the ones of Thorfin are) look extremly good as they are a piece of art and they are also extremly helpful for human beeings, as a human brain can easily extract lots of information out of them, like:
"What kind of terrain is over there, right next to a mountain?"

Unfortunatly to the computer it is much more complicated to extract this kind of information out of a pixel map, as a computer doesn´t have such a good picture-recognition-system as our human brain is.

So, if you want your computer to be able to "work" with the terrain of a map (like modifying the terrain, calculating how long it takes a player to move on this terrain, calculation how much gold the ruler of the dominion, to which this terrain belongs, gets out of the terrain) you first have to teach your computer to identify certain terrain-types (forest, mash, grassland,...).

You probably already knew this, but I posted it anyways, as there might be other who are interested in. So let´s move on:

I am not a professional programmer, but I have fun trying out algorythms and so I tested a rather simply approach to this problem:

The idea was, to teach the computer to recognize terrain-types in a pixel-map by either

- let the user "click" on some hexes in the pixel-map and let the user tell the computer which kind of terrain this hex stands for or
- by providing the computer with terrain-tiles (small pictures in hex-form, which show a forest or a grassland or a desert,...) together with the info, which terrain-tile (for example: the green picture with trees) represents which terrain-type (in this kind: forest).

Afterward we let the computer determine, which aspects of the provided terrain-tile are specific to it.

For example the terrain-tile for forest might have a high amount of dark green pixels, probably not so much blue pixels and even less red pixels.

We do this for every terrain-tile/terrain-type and thus get a database, which holds informations for the computer, how it could recognize terrain. This database might look like this:

Code: Select all
Name   LongName   Terrain   Material   Vegetation   Resources   rCount   gCount   bCount
1   Clear, Farmland   Flatland   loam   agricultural land      0   100   0
2   Hills   Hills   silt   grassland      100   0   0
3   Mountains   mountains   rock   tundra      100   0   0
4   Light Forest (Predominantly Deciduous)   Flatland   silt   forest light      0   100   0


As you may see in the tables, a hex in the pixel-map, which contains 100% "mostly green" pixels (gCount!) will be assumed to be a terrain of type "clear, farmland".
A hex in the pixel-map, which contains 100% "mostly red" pixels (rCount!) will be assumed to be a terrain of type "Hills".

At this point you might object, that hills aren´t red at all (which is true), but all the pixels in the hex in a pixel-map, that represents the terrain "hill" have lots of red in them, as they are brown (and in brown there is red).

You might also object, that by this way there is no way to differentiate between a hex of "hills" and a hex of "mountains", as both have 100% "mostly red" pixels, because the first is brown and the other one dark brown.
This is true and it is the reason why I also had to include other markers, as there are:

- average percentage of red in the pixels
- average percentage of green in the pixels
- average percentage of blue in the pixels
- average color of all the hex
- amount of "mostly black" pixels
- amount of "mostly cyan" pixels
- amount of "mostly magenta" pixels
- amount of "mostly yellow" pixels
- contrast of the pixel-colors
- brightness of the pixels


So an entry for the "grassland-terrain" in the database actually looks like this:

Code: Select all
Name   LongName   Terrain   Material   Vegetation   testR0   testG0   testB0   AverageColor   rCount   gCount   bCount   blCount   cCount   mCount   yCount   contrast   brightCount
1   Clear, Farmland   Flatland   loam   agricultural land   60   80   40   &c96C864   0   100   0   0   0   0   100   0   100
2   Hills   Hills   silt   grassland   84   75   33   &cD2BB52   100   0   0   0   0   0   100   84   100
3   Mountains   mountains   rock   tundra   62   48   21   &c9B7834   100   0   0   0   0   0   100   146   99
4   Light Forest (Predominantly Deciduous)   Flatland   silt   forest light   57   77   37   &c8EC05C   0   100   0   0   0   0   100   55   100


Once, this database is created, the computer can apply it to any other hex of the given pixel-map, simply by comparing the amount of "mostly red" pixels in the hex in question (and the amount of "mostly green" pixels,...) with the entries in the database. If the result of the comparison shows, that the amounts of "mostly red" pixels (and so on) of the hex of the given pixel-map are not too far away from the entry for "Hills" in the database, it would be fair to assume, that the hex in question is representing the terrain "hills".

Sometimes a picture is better then thousands of words:



Once you have done this for all the hexes of the pixel-map, the computer now "knows" the terrain.

You can then "save" the map by simply storing the koordinates of the hex, followed by the number (in this example: 1,2,3 or 4) of the terrain.

Let´s have a look at the file-format of the thus stored map:

Code: Select all
x/y/z   terrainTileNr   terrainMaterial   terrainVegetation   terrainResources   terrainInfluencer   height   settlementName   settlementSubtype   Country   Dominion
-31/-30/0   3                           
-30/-30/0   1                           
-29/-30/0   3                           


Big Mac wrote: So does the TAB number represent your inferred height relative to Thyatis? If TABs are a "unit of height" there is then the question of how much height 1 TAB is equal to. :)

No, this info is stored in the newly created column "height", which I don´t use right now, but which will make it easy to alter the height of a hex by the user. Thanks for the idea! And yes, you are right, there is the question about the measure of the height. I choose a rather intuitive approach to this, but someone already pointed out, that the mountains are far too high if you assume the hexes to be 8-miles-hexes.

Big Mac wrote:Or is it a label that your program is creating for an individual hex, so that it can call on that number later?

No, the key/label to an individual hex are it´s koordinates x/y/z (which are, as you already assumed, relative to a fixed place, let´s say a special capital).
Even the z-koordinate isn´t the normal "height" of the hex as in "height of a mountain". I introduced it to be able to create several levels of maps (let´s say an underground map, a map for the upper world and a map up on a flying island in the sky). So the meaning of z would be:
z=-1: underground
z=0: upper world
z=1: flying island
By thus you can create literally "infinite" numbers of maps at different levels, each of them positioned above another...

In case I understand your questions well, the "TAB numbers" (which are the numbers 3,1,3 in the above example, right?) represent the terrain-type.
To simplify things you could say that "3" stands for "mountains" and "1" stands for "Clear, Farmland", but this is not the full truth. I can explain this in another reply, if you are interested in, but I can already "reveal", that I have another approach on "terrain" (as you might already guess by looking at the colums "terrainMaterial" or "terrainVegetation" ).

Big Mac wrote:I can see that you have a process here and that it works again and again, when you stick in more maps. If you are comparing hexes with other hexes to infer the height, I can see how adding more hexes would cause you to need to make more comparisons. And if the TAB numbers are generated from hex colours, I can see how a big map might cause potential disputes in the interpretation. So that might make the process take longer and longer, if areas are expanded and cause computing time to get bigger and bigger.


I probably didn´t explain that right in the first place, so I will try to do better:

The progresses of "reading in a pixel-map" and "creating a 3d-map" are totally different progresses. You can read in a pixel-map (or one pixel-map after the other, "scanning in" more and more terrain) and store it (in the file-format described above).
Month later you can restart the software, load the stored map and choose to create a 3d-map out of it.

The progress of "reading in a pixel-map" is NOT error-prone, as the computer might easily not be able to differentiate between a hex with "forest" and an hex with "light forest" in the pixel-map, as the amounts of "mostly green" pixels and so on might not be very different. So you will get interpretation-errors.

A totally different thing is the creation of the 3d-map. This part is error-prone as the software simply has to create a 3d-model for every stored hex and add up these models to one huge 3d-model of the map.

But there´s another problem in here:

The computer has no information about the height of a hex, as this information is simply not available in the (flat) pixel-maps.

So what the computer does while creating a 3d-map: it is making assumptions about the height of every hex:
Mountains should be high, hills a bit lower, grassland lowest (but still above sea-level) and sea of course at sea-level.
So it does apply a height to each hex (or better to say: to the six edges of a hex) according to the terrain-type of the hex and modifies this height just a bit with random values.

You are right, that for to infere the height I have to compare the height of one hex with the height of the hexes around this one. But as I only compare with the nearby hexes, the time, that this algorythm needs, is only proportional to the total numbers of hexes (and not overproportionatly). But, of course, it takes more time to convert a big map into a 3d-map than to convert a small map, as you already stated.
(Actually this part of the algorythm caused me some headaches, not because it´s difficult to calculate the medium of two heights, but because I choose some funny approach to it and made it more complicated as it might be. Might choose to revise this part, but as the saying goes: "never change a runnning system").

Your implied idea, to not only compare with the nearby hexes, sounds good, as this might result in higher mountains in the centry of a mountain chain, but time prevents me from covering this aspect and as you already stated, this might lead to much longer conversion-times.


Big Mac wrote:Do you have problems with edges? On the edge a map, you have a cut-off of data, so if you are inferring TABs from their surroundings, I can imagine that the loss of data would potentially cause problems for edge hexes.

Yes, you are right, the edges doesn´t look well, especially when the terrain at the edges is "mountains". I assume it is simply because one "side" of the mountain is missing, or to speak in 3d-models: the "face" on this side of the mountain is missing, which makes the mountain transparent on this side.

Big Mac wrote:Do you get the same results if you rerun this process multiple times? And do you get similar results if you chop up maps in different ways, run your process and compare the results?

In case you refer to all the map: Not in terms of "heights", as these are partly calculated randomly (which might easily be turned off)
In case you refer to the edges: I don´t really chop up maps. The 3d-map is always calculated totally new form the stored map (which can be created by "interpreting/scanning" a pixel-map)

Big Mac wrote:Thanks for the two offers. Like I said above I'm not sure I could do anything with your work.

But I do find this sort of thing interesting.

I've been following the work of Anna Meyer, who spent over ten years making a 3D model of Greyhawk. I've seen her map get bigger over time and I've seen the quality of her map get better over time.

I've also been following Thorf, when I can. He has been doing some amazing mathematical 3D work on figuring out the implications of the size and shape of the polar openings on Mystara and how the influence the Known World and Hollow World maps.

First time I hear about Anna Meyer. Thanks for the hint. Will have a look at her art.

Big Mac wrote: And it looks like you are still fairly close to the start of your process (so I've not missed all the fun) and you are learning stuff and making your process involve. I'm not sure exactly where you are going to go with this, but I can see it's got legs and it's galloping off in some sort of direction. :cool:


I am at the beginning. But the map-stuff is only a small part of the idea and the already finished work. The main reason to make this part was to have a map, where I can let the computer calculate traveling-time and simulate dominions with income, armies and stuff like that. The 3d-map was only another way to display the map. But I will continue to work on it.

Big Mac wrote:If you want to discuss potential formats for 3D mapping, that seems to be a separate topic to an individual map for a 3D Central Thyatis. It might even be something that goes beyond Mystara that could help fans of all RPGs. So you might want to consider making a separate topic. :)


Yes, you are right, the audience might be wider, but I have so much fun to work with the maps I loved to play in as a DM years ago :)

Actually I wasn´t so much looking for formats for 3D mapping, but instead for formats for 2D mapping and I assumed there had already been some canonical ideas about it.
I had a look of the file-format of hexographer. It looked pretty clean, but missed some information I would like to include (dominions, resources and so on.)
So I stayed with my own file-format (and implemented an import-function for hexographer-maps.)

Big Mac wrote:I think that you need cartography experts to give you their opinion on this. I'll see if I can cast the Summon Cartographer spell on Anna Meyer and/or Thorf. ;)

Thanks

If you have more suggestions or questions feel free to post them and I will try to reply.

I will try to provide an updated version of the simulator, including the import for hexographer maps and pixel maps, in some weeks, so you will be able to "play around with it" on your own...

*Edit* included some pictures to visualize the text
Place hundreds of orcs against a company of elves: Aklandas Large Battle Simulator
User avatar
aklanda
Gnoll
 
Posts: 118
Joined: Sat Apr 22, 2017 2:38 pm
Location: Europe

Re: 3d central Thyatis

Postby Big Mac » Tue Oct 03, 2017 12:37 pm

Thanks for all the information Aklandas. And don't worry about your English. I understand you just fine.

The issue with me asking quetions is purely down to the fact that you are working on a highly artistic process that I don't know how to do.

I hope things move forward for you on this, and that you find some experts who can look at what you are doing and come up with some good questions that give you new ideas.
David "Big Mac" Shepheard
Newsflash!: The Piazza is moving!
Please join The Piazza's Facebook group, The Piazza's Facebook page and The Piazza's Google + community so that you can stay in touch.
Spelljammer 3E Conversion Project - Spelljammer Wiki - The Spelljammer Image Group.
Moderator of the Spelljammer forum. My moderator voice is green.
User avatar
Big Mac
Giant Space Hamster
 
Posts: 21328
Joined: Sun Jun 15, 2008 3:52 pm
Location: London UK

Re: 3d central Thyatis

Postby aklanda » Sat Oct 07, 2017 1:22 am

Big Mac wrote:Thanks for all the information Aklandas. And don't worry about your English. I understand you just fine.
I hope things move forward for you on this, and that you find some experts who can look at what you are doing and come up with some good questions that give you new ideas.


Thanks!
Place hundreds of orcs against a company of elves: Aklandas Large Battle Simulator
User avatar
aklanda
Gnoll
 
Posts: 118
Joined: Sat Apr 22, 2017 2:38 pm
Location: Europe

Hex-Map of Ireland and Britain

Postby aklanda » Sat Oct 07, 2017 1:25 am

Wanted to know, if this method also works on real maps.

So I scanned in the British Isles, converted the map to hexes of 8 miles and added settlements from 800 A. Click on the picture for to zoom in.

Image
Place hundreds of orcs against a company of elves: Aklandas Large Battle Simulator
User avatar
aklanda
Gnoll
 
Posts: 118
Joined: Sat Apr 22, 2017 2:38 pm
Location: Europe

Re: 3d central Thyatis

Postby agathokles » Sat Oct 07, 2017 9:41 am

Once more, very cool! BTW, if suitably refined, this method would be very useful to create hex maps out of existing world maps -- from the real world or from other D&D settings.

GP
agathokles
Red Dragon
 
Posts: 6560
Joined: Sat May 24, 2008 6:42 pm
Location: Milan, Italy

Re: 3d central Thyatis

Postby aklanda » Sat Oct 07, 2017 12:11 pm

agathokles wrote:Once more, very cool! BTW, if suitably refined, this method would be very useful to create hex maps out of existing world maps -- from the real world or from other D&D settings.

GP


Thanks!

Yes, thought of converting europe some time later. Unfortunatly it only works with kind of topographical maps, as the color (dark-brown:mountains, light-brown: hills, green: flatland) is the key for the conversion. Hand-drawn pencil-sketches will not be recognized correctly.

Still it will create large files, especially when I export the hex-maps as pictures...
Place hundreds of orcs against a company of elves: Aklandas Large Battle Simulator
User avatar
aklanda
Gnoll
 
Posts: 118
Joined: Sat Apr 22, 2017 2:38 pm
Location: Europe

Re: 3d central Thyatis

Postby agathokles » Sat Oct 07, 2017 12:48 pm

Of course. The classic map from the Lord of the Rings would not work. That said, many maps from TSR settings use a style similar to that of RW maps -- think Birthright or Forgotten Realms or Dark Sun.

GP
agathokles
Red Dragon
 
Posts: 6560
Joined: Sat May 24, 2008 6:42 pm
Location: Milan, Italy

Re: 3d central Thyatis

Postby aklanda » Mon Oct 09, 2017 12:19 am

agathokles wrote:many maps from TSR settings use a style similar to that of RW maps -- think Birthright or Forgotten Realms or Dark Sun.


Yes, you are right, that might work too.

Right now I will have to concentrate on getting rid of several bugs in the simulator.
I´d also like to proceed with the dominions (economics, civilisation-grade, income etc.)

Ireland and Britain will probably be my test-setting.

Here´s an picture showing the dominions in Britain and Ireland at about 800 AD:

Image
Place hundreds of orcs against a company of elves: Aklandas Large Battle Simulator
User avatar
aklanda
Gnoll
 
Posts: 118
Joined: Sat Apr 22, 2017 2:38 pm
Location: Europe

Re: 3d central Thyatis

Postby Big Mac » Wed Oct 11, 2017 8:25 am

Very nice.

There are a couple of RPG settings based on a distorted British Isles.

Westeros (A Song of Fire and Ice/Game of Thrones) is an upside-down Britain, with Ireland stuck on the bottom.

I think the other setting is called Valorean. (Not sure on the spelling there.) That was a setting used to test D&D Next. It was also upside-down.
David "Big Mac" Shepheard
Newsflash!: The Piazza is moving!
Please join The Piazza's Facebook group, The Piazza's Facebook page and The Piazza's Google + community so that you can stay in touch.
Spelljammer 3E Conversion Project - Spelljammer Wiki - The Spelljammer Image Group.
Moderator of the Spelljammer forum. My moderator voice is green.
User avatar
Big Mac
Giant Space Hamster
 
Posts: 21328
Joined: Sun Jun 15, 2008 3:52 pm
Location: London UK

Re: 3d central Thyatis

Postby aklanda » Fri Oct 13, 2017 11:56 pm

Big Mac wrote:Very nice.
There are a couple of RPG settings based on a distorted British Isles.


A nice idea!

Posted an update for the simulator, if anyone should like to play with the map-creating-tools.
As it was time to start a website for all the stuff (simulator, maps, animations), you can download it directly from the website:

Aklandas Simulator new Website


The included documentation is a bit outdated, but I will try to also update this.
Place hundreds of orcs against a company of elves: Aklandas Large Battle Simulator
User avatar
aklanda
Gnoll
 
Posts: 118
Joined: Sat Apr 22, 2017 2:38 pm
Location: Europe

Previous

Return to Geographical Mapping

Who is online

Users browsing this forum: No registered users and 1 guest