Map generator model II

[Gary Thomas]

This thread is a continuation of the previous Map generator thread
I am starting a new thread for the Polygon/Microterrain discussion, since it isn't directly relevant to the topic here. So please post any relevant material there.

Cheers

[thenuts]

Hi all, I got a lot of ideas from the clash models to my own game, the first thing I will do is the map generator, and since yours are a litle stoped, i will like to help, probably, my generator will not be as deep as you all want, but if help at least temporaly until the final version. good, i just like to give something back

[thenuts]

I will begin making a factral map generator, the main reason to this is the number of algorithms I found.

I like a lot the simulation Idea, but i don't know how I identify the plates generated by the faults, the best I came up was a floodfill like algorithm, but i think that will be time consuming and cost a lot of time to implement.

well that's it , I will like sugestions

[Mark_Everson]

Hi thenuts, and welcome to Clash

On the details of the map generator, I guess you need to do whatever you think is right for your project. I wasn't really impressed with the fractal maps at the link you sent me by email ( http://circuitpsyche.com/fracplan/ ). The code Rudiger did quite a while ago is available off his web site if you haven't seen it. Its at the end of the Map Gen thread before this one.

Gary is very interested in this topic, but unfortunately RL is limiting his forum access for the moment. I am sure he'd like to be in the discussions for what should be done.

Thanks for being willing to help out!

Mark

[primemover]

My own algorithm

Hello, I am new. I offered my introduction here on this thread. If I join this project (which I am considering) I will insist on a realistic map generation model. (Which will use plate tectonics as well as a weather system to place continents, terrain, and goods.

I have actually started my own map generator that would do what I had in mind (and largely what it seems you guys originally wanted too) I have some ideas for implementing tectonics. If we put our heads together, I feel we can think of something.

Instead of a flood fill, I am thinking of a crack pattern method where the cracks will create the plates. Flood fills demand too much in the way of determining where the edges lie and what kind of margins we have (if you want, I can send my executable that opened my eyes to why this was so).

[Mark_Everson]

Hey primemover:

As you said, what you want in a map generator is what we've pretty much wanted all along I'm not sure what point your floodfill comment pertains to. . . but seeing as we need some way to start the plates, based on limited info you preferred approach sounds ok by me. Can you post some screen shots of results from your approach if you've gotten that far?

[primemover]

my point

Here was my point...

It appears the members of this group have been discussing how to generate the plates. They have suggested using a flood fill technique. This is the easiest method to use when generating the plates because you can pick a starting point and randomly grow the plate until it encounters another that has been growing as well.

Unless I have misunderstood "flood fill," (it could also mean using the crack method described below and then filling in... which I think will work better), I have, through my own C++ program, discovered that this will not work well.

This was the first method I tried. I soon discovered that it did not work well the way I was implementing it because it gave innacurate results when trying to define what kind of margin we had (subducting, transform, divergent... etc).

In an attempt to correct the problem, I decided we needed to know where all "edges" were to the created plates. In trying to write a routine to do this, I discovered that it was extremely complex to do something this way and decided it would be better to start with the edges first, and then fill in the plates.

I do not have a complete algorithm yet for the second method yet. The only example I can show you is what happened when I did it using the "flood growth" method as I will now call it, I can show you screen shots of the actual plates, their velocities, and of the calculated margin types (which are usually wrong).

By the way... I know this has its own thread... and may be put on the shelf for now, but we may need to know what kind of map we are going to use before we implement this... at least in terms of polygons vs. an absolute coordinate system because it may make a difference in the algorithm we use to define plates.

We don't necessarily have to decide on which polygon we are going to use... just if we are going to use them and how.

Another comment... we may want to use a combination of systems. I don't think translation between them will be all that difficult, but I think we may want to discuss this whole thing here and now.

I will post the pictures in another reply (sometime soon I hope), because I need to explain how all this worked in my prototype.

[Mark_Everson]

Re: my point

Hey primemover:

BTW I can delete the post above that went into the wrong thread if you'd like.

On the plates, I'm game to go with your cracking algorithm. It sounds like you've gotten further into this than we ever did.

Originally posted by primemover
By the way... I know this has its own thread... and may be put on the shelf for now, but we may need to know what kind of map we are going to use before we implement this... at least in terms of polygons vs. an absolute coordinate system because it may make a difference in the algorithm we use to define plates.

We don't necessarily have to decide on which polygon we are going to use... just if we are going to use them and how.

Another comment... we may want to use a combination of systems. I don't think translation between them will be all that difficult, but I think we may want to discuss this whole thing here and now.

Hmmm. . . I don't see why we'd need to know much about the small-scale features like polygons, squares, or whatever at this point. In any case a simple interpolation algorithm can go from whatever the plate algorithm uses to whatever we are using for terrain subdivision. Can you give an instance where major problems could occur if you don't know what the underlying terrain subdivisions are?

[primemover]

Problems would not necessarily occur if we changed the number of sides on a polygon, or even if we changed from a globe to a sphere... if we are still using polygons. I was expecting to do this anyway... its just a matter of dealing with another dimension or two to the coordinate system.

The problems might occur if we changed the nature of our approach to implementing the map.

For example: If we chose points versus polygons (which may actually be a better approach if we plan on turning this to a sphere. Polygons would still be part of the picture, they would just be used for user convenience... the real plotting, distance, and coordinate system would just be baised on points instead.) it would change the way we program the techtonics/weather pattern simulator somewhat. (A strict polygon system may actually be impossible to use on a sphere in the long run, but I will address this in the polygon discussion when I have done more research).

PS... yeah... go ahead and delete that post (and the following one).

It would really change things if we were using polygons of different shapes and sizes.

The thing is that a geology simulator needs to be able to handle the gradual motion of entire continents. It needs to calculate the new positions for all "parts" that make up the plate (and continents). It also needs to take into consideration changes in height in the terrain due to folding, erosion, and volcanic activity.

Different methods of dividing the map are going to introduce different sets of problems. If the parts are all different shapes and sizes for example, then it is going to have a dramatic effect on calculating what happens when folding occurs. (I actually don't like the idea of using this approach at all... it may be impossible to use if we are going to involve a geology simulator Subdividing units for smaller parts of terrain is still ok, but the its going to be very difficult to simulate tectonics unless we have a defined smallest possible unit and all larger units are in terms of the smaller).

[Mark_Everson]

Originally posted by primemover
It would really change things if we were using polygons of different shapes and sizes.

Ok, now I understand your objections. But I believe there is no conflict with arbitrary size and shape polygons for the
'normal' game map. You would use whatever system you want to generate the map. Squares, triangles, whatever. Once the map is evolved, geology is over, and you don't need to maintain whatever system you used. The map generation result would be translated to polygons for the game map.

Part of the reason for the polygons was to make economically useless areas be relatively large polygons, since they're not where the action is. The econ model is quite computationally expensive, so the fewer populated polygons the better. The plan was also to use large polygons for ocean. Unit positions would be handled on a coordinate basis.

This whole process was envisioned for a game that terminates near contemporary times. If people have huge sprawling settlements on mountain ranges, or in the ocean then that polygon idea won't work as well. Individual concentrated cities in these areas would work ok, I guess, and might be a dodge that would reconcile your desires with Gary's polygon aims.

[primemover]

Promised Screen Shots from my first attempt at a map generator:

Ok... the next four posts (not including this one) include screenshots of my first attempt at creating a program that would implement a system of plate tectonics.

This code was written late in 2001/early 2002. In mid-2002 I started rewriting the code (not finished) to attempt another algorithm. It is written in C++.

P.S. Could someone tell me how to post images as images instead of attachments so that I can put them all in one post with thumbnails?

[primemover]

Custom World Dialog

On the custom world dialog, the only sliders that currently work to change anything are average continent size, terrain variablity, and mountains. Average continent size will change the plate size (and number of plates), mountains will change the average continental drift speed, and terrain variablity will change the deviation of drift speed from the average (see geological data view below).

[primemover]

New World Dialog

The GLOBAL DATA section was not developed because I haven finish the world creation routine which gives creates the initial map.

The Status boxes at the top are being used for viewing cell stats (A cell is a single spot on the map represented by the little squares). Currently the map is cartesian. Eventually I am going to use a spherical grid... But for now, this way simplifies things a great deal.

Currently only two views work on the map: Plates and geological data. The "views" on the menu show most of the different concepts that my map engine was to concern itself with. All of these features would affect the map and the gameplay.

Please NOTE: These views are for development only. Once the map is made and the game is to begin, the player would not have access to these views until they developed appropriate technology. They would also not be able to see the map during its creation.

[primemover]

Plate View

This simply shows the randomly generated plates on the map. Wrap around is active so plates that go off a border will show up on the other side.

The "views" listed on the menu show most of the different concepts that my map engine was to concern itself with. All of these features would affect the map and the gameplay.

[primemover]

Geological Data View

This view shows plate direction (the head of the "arrow" is pointed in the general direction the plate is going), plate speed (the numbers), and edge zone type. It will eventually also show hotspots, volcanic activity, and earthquake zones.

About Plate speed (continental drift speed):

Plate speed is affected by the mountains setting and the terrain variablity setting. The higher the mountain speed setting, the greater the average plate speed. The higher the terrain variability setting, the more variation one will see in plate speed.

About Edge zone type and plate direction:

If you know anything about plate techtonics, you will discover that my current algorithm for determining zone type is not working properly. I am redoing the entire thing. Plate direction will not be randomly generated as it currently is. Spreading centers will be semi-randomly selected and these spreading centers will determine continental drift direction. This will be more realistic in that this is what determines plate direction in the real world. If you click on a colored square (or even a white square), the status box will tell you the zone type for the cell you clicked. Here is the color key:

Blue: supposedly divergent (spreading center)
Red: supposedly a subduction zone.
Yellow: supposedly a transform margin
Green: supposedly a passive folding margin (zone).

I say supposedly because currently, it is often wrong.