I've been trying to finish up my lumber harvest script, and I realized I need a way to control the Biomes of a map so that the system would know where to spawn trees. I was thinking these would be handled with regions, but regions are made up of rectangles. Map biomes won't be rectangular and lacing rectangles together to make the actual bio shapes is not only tedious, but kind of ridiculous.

I'd like to be able to control biomes and regions on a map that is both generated (thinking of my map generator project), but also with existing maps. On a generated map this would be trivial since it has a regular graph like structure, but on hand drawn maps and stock maps that lack a structure there isn't a clean way to do it. I'd have to build an external tool to allow the definition of a region path, or shard admins would have to go around to each point in game and add it.

The other issue is that for generated maps, I need a good way for admin to get around in them. Since they won't know before hand what the map will look like, it would be good to have an ingame way of viewing a map. I now there was a project a while back that converted bmp format into gumps, but I think it was extremely inefficient.

At the moment, I'm looking at generating maps with just the outline of the continents to keep the gump size down. It's actually a really interesting problem. I've been experimenting with potrace which converts bmp to scalable vector graphics (svg). Since map mul files are just like big bmps, this seemed like a natural fit. But to be able to build up the gump I need to build a SVG renderer.

Anyway, here is my first attempt:

ai22.photobucket.com_albums_b347_Praxiiz_landmass.png

This could be added to a gump pixel by pixel. The gump would not have to hold every pixel in the image, just the outline which is black pixels. PoTrace doesn't do a bad job, but I have a feeling this kind of gump would have too many little images on it to be of any practical use.

The odd/out-of-place map shapes are likely due to the fact that I'm just using the wet tiledata flag and not checking the actual tile ids.
 
Last edited:
This method seems chaotic. Drawing random trees with the borders of land masses would be to general.. It would have to be more refined like this. To prevent trees from being just everywhere. Trees are actually drawn on top of certain textures in UO. There is forest/jungle/& swamp like so.
 

Attachments

  • Example copy.png
    1.1 MB · Views: 26
  • Example2 copy.png
    1.1 MB · Views: 19
  • Example3 copy.png
    1.2 MB · Views: 16
I agree Otimpyre, I've been thinking on this very idea, I came to the conclusion that basing the placement on land types can be done threw a random rule set. So if a land name is forest, we could spawn a tree around preset conditions, one being altitude, spawn certain forests at higher altitude that are different then lower altitudes. This idea needs a lot more discussion IMO but could be an amazing addition!
 
For the lumber system, I am just tracking where trees were and re-spawning them. It turned out to be much easier.

For the procedural content generation, Each biome would have one or more textures which could limit the places trees spawn. It's actually easier to figure out where to spawn trees once you know what biome you're in.
 
For the lumber system, I am just tracking where trees were and re-spawning them. It turned out to be much easier.

For the procedural content generation, Each biome would have one or more textures which could limit the places trees spawn. It's actually easier to figure out where to spawn trees once you know what biome you're in.

(Talking about map generation overall as I believe your UL system is capable of such a task)

I see where your going, just a question though, wouldn't the biome just be X,Y Coordinates? meaning, could we just use the Coordinates as part of the condition system, by adding checks within X,Y, for example : we randomly place tree types depending on z height, random could be the percentage of tree coverage we predefine?

:)
 
If you look at my procedural content generation thread, you will see the part of the content generation where it builds up Voronoi polygons. The reason they are used instead of a tile by tile biome definition is because of memory over head. It's a lot less memory to track a bunch of groups of tiles stored at polygons (we're talking a few thousand) instead of by tile (7168*4096 = 29,360,128).

The coverage percentage is a great idea - each biome could be checked against it's coverage percentage and then trees get spawned in the biome until the threshold is met. I think the actual locations of the trees will be determined by some kind of perlin noise inside each Voronoi polygon since Perlin noise can give use a good spread across the polygon. See http://devmag.org.za/2009/04/25/perlin-noise/
 
I do agree, as I have tested UL at converting every tile on a trammel sized map, took about 10 mins to run the code, but worked, that is why I was exploring how to do chunks of the map, just to make the code run smoother with out a 10 min lag spike lol! Upon reading this though, I do believe my efforts are in vein as this will be 100 time more effective then what I was planning. I now look forward to your map generator, if you need any help on research or what not for the system, let me know!

Will say this again and will not be the last, Amazing work Praxiiz!
 
Back