Map Generator Model

[Mark_Everson]

Henrique:

I come down mostly on the side of your choice 2. Although if these aren't enough for game play purposes, it would probably need to throw in some of the larger deposits in your category 1.

While clearly in reality each square should have a potential to contain any of the many resources, the current plan in the economic model is to have only one "special" (and minerals are among these) per square. So although I think it's worthwhile to calculate deposits and their chance for every sort of square, I just wanted to make it clear that the game mechanics will probably cut off most of these possibilities. So, for instance, while there might be tin in Greece, the early Greeks had to go to near Rome and other places to obtain tin. If there aren't nonuniformities in the distribution of tin, we will miss out on effects like that.

Thanks for working on this!

[Henrique Duarte]

Mark
Lets see if you like this:

step one
Allocate geographical position and abundance of resources on the map (with geological credibility)

1 - They will be divided in surface and deep resources.

2 - resources are exploitable only if you have the knowledge to do so and if you have found them (this will require infrastructure investment - covered by econ model; and prospection investment - not covered yet.)
ex. a big % of surface deposits will be readily available to the player, for the rest of surface and deep deposits they will have to be hable to explore (prospection) on a square/province level and create production infrastructures.

How to make the player A really need those products that only B has?

Well... small deposits will only give you a little bit of production, way bellow your needs, and tendency will be for them to get smaller.

The very large anomalies (that can be simulated in example 1 as well as in two) will be 100 to 1000 times bigger and also much more productive (and this is not unrealistic!). The deposits in these regional anomalies (something that should be 2-10 squares big if the scale is 60 miles across)will be huge and hard to deplet (germany still produces huge amounts of coal :-))

The idea is to make everybody able to produce a little bit of everything (even if to make it so they have to invest a lot, and STILL not being able to satisfy product needs - one small deposit will only produce a max amount of ore no matter how much money you put into it) but make it much more cost per unit efective to trade.

I believe this will give a few more interesting things for the player to do, namely to bet in mineral exploration if he wants to - note that in the beggining of the game you might be sitting on top of the "mother load" and you wouldn´t have the faintest idea. Has tech progresses old territories gain new importance :-)

[Mark_Everson]

Henrique:

I like your idea on this a lot. If nobody strenuously objects, that's the kind of thing I think we should go with. Perhaps we can handle the smaller deposits in a statistical way even, so the player doesn't deal directly with them. The player would know there is some tin locally, but that the economy could use a Lot More...

[Lord God Jinnai]

I want to know what the amount would be needed to develope them for use on larger scales. FE Japan although there was copper, never had a bronze age because there just wasn't that much. So i'm wanting to know, does it take a large area to actually produce the material for anything more than trinkets?

[Henrique Duarte]

Lord Jinnai

There is one thing you must take into account regarding the development of metallurgy and availability of resource.
The region may have the resources but they may only be exploitable if the mining tech is available.
The resource production technology used for the discovery of bronze/iron deposits is extremely rudimentary and only high grade (big nuggets) surface deposits where exploited. So if you can´t even get a bit of concentrated cooper + tin you will never be able to develop bronze (by the way for bronze metalurgy you must have coexisting tin and cooper deposits, after the discovery you can start getting cooper from square A and tin from square B to make bronze)

I believe you can make the availability of resource a prerequesite to develop a metallurgy tech.
ex:
you must produce copper+tin to be able to develop bronze metalurgy

Iron for iron metalurgy (la palisse :-)

And to make it fun you can make the amount of progress on bronze vs iron metallurgy research dependent on the exploitable abundancy of the prerequesite resources.
So if you have much more iron than bronze+tin you will probably develop iron first (and make any development on bronze obsolete)
On the other hand if you have plenty of copper+tin you get bronze first.

This, of course, must be weighted by the basic amount of research you need to get each tech... it is obvious that iron met is much harder to get than bronze (which means you must have a lot more iron than copper+tin to get iron first)

[Paul Crocker]

Our coder, MCA, seems to have dropped from sight. Unfortunately, he has the only copy of the code for the map gen model. If anyone on the forum has access his page (via the link in the forum), please check your caches to see if you have a copy of his website saved. If we're lucky, we won't lose the code that MCA started. The following steps should work:

1) Log off the Internet (they MUST be offline)
2) Click the link. If it's cached on their systems, they'll get the web
page. http://danish.visl.ou.dk/~mca/clash/
3. Save the page file with a different name, and forward a copy to me, Kull, and Mark.

Thanks!

[mca]

Ack! Sorry about that. IP numbers and DNS entries were changed here some time ago. No need to check your caches, it's at
http://mca.visl.sdu.dk/~mca/clash/ now. But it's true that I've dropped out of sight - I am no longer coding the map generator (I still lurk around, though)


Martin

[Paul Crocker]

Thanks a ton for the update, and for all the work that you put into the model, MCA! Sorry that you couldn't continue with your efforts - we're always open to suggestions, or to welcoming you back onboard should you change your mind about the coding.

[Richard Bruns]

It seems to me that we are starting to hardcode different land types. This is fine for the standard setup, but it limits customizability. I think that we should plan for a terrain system something like this:

There is a terrain editor that allows the user to alter the map tiles. It has the following options:

Movement: Sets the type of units can enter the tile and how difficult it is for them to move. In conjunction with this, every unit has a movement type defined. I think we are already doing this for units.

For example, a Tracked unit type would be unable to enter a swamp, while an Infantry unit would go in with a movement penalty. An Amphibious unit, like a DUKW, would be able to enter the terrain and travel with no movement penalty.

Power Modifier: Sets a bonus or penalty to a unit’s power in a certain type of terrain, For example, Chariots are much less effective in hilly or forested terrain.

Note that land and sea are not coded differently. They simply have different movement settings. They also have different habitation and economic settings, as described below:

Roads eliminate these movement restrictions and penalties. All roads are about the same, except for roads over hills and mountains. The editor would have the ability to define the cost of the road and the upkeep it requires, as well as the movement required to go over the road.

In addition to effects on units, the terrain editor should allow a designer to set the economic impacts of the terrain, as follows:

Habitation: Sets the ability of people to live on the tile. This can be No Requirement, Never, or a technology level requirement. There should also be the ability to set a structure or improvement as a requisite for habitation, FE Undersea Colony.

Structures and Improvements: Allows the user to alter the ability to build things on the terrain and the cost and upkeep of those improvements.

Vegetation and Resources. Allows the user to alter these aspects of the tile. I am pretty sure that in the current model, vegetation is mostly independent of geology, and I think this is good. I don’t think vegetation should have its own different terrain type, like Forest. Depending on the climate, vegetation can change over the game. Also, altering vegetation should be much easier than altering land structure.

There should be the ability to create entirely new resources, like Mana or Dilithium. This can be done by defining a variable, having terrain add to that variable, and make applications that require that variable and subtract from its pool. If we plan for this now in this model and the econ model, it won’t take much extra coding effort.

Each terrain type in the game would be defined this way. For the map generator model, we can hard code things like “Plates Collide = Terrain # 3 at junction” but if someone wanted to make a custom map, they should have the ability to dramatically alter the terrain and its effects.

Also, at present there seems to be only one type of ocean terrain. I would like to see a game where undersea colonies or mines are possible, and for that to happen there would have to be different types of ocean tile. Even in the present day, they routinely build oil platforms, which are possible for some types of ocean terrain and impossible for others. At a minimum, there should be a difference between continental shelf and deep oceans. The terrain on the shelves should be variable like it is on land tiles, because a reef or kelp forest will have a big impact in the amount of fish in the area. This vegetation would be vulnerable to pollution, and its loss would impact the resources of the ocean tile.

These kinds of things could work with the same Alter Variable equations that the techs and applications would use.

This won’t be in Demo 5, but I think we should keep it in mind as we make the terrain model. There should be enough flexibility in terrain to create any number of new worlds. If we include the flexibility from the beginning, we will have a much easier time and the product will be better. An "Editor First" coding plan is IMO the way to go.

[F_Smith]

Richard:

I think you've got it exactly right. I believe Mark agrees, and has planned it this way too. He's just been too busy to do this particular analysis/design yet. (I think he's having too many Pina Coladas at night, the slacker!). Hehe.

But there needs to be a 'terrain' object defined ASAP, before any coding is done on any model that uses terrain objects.

It needs these methods/behaviors, as you outlined:

object Terrain --
public methods:
setTypeName(String n);
getTypeName();
setMovementModifier(int m);
getMovementModifier();
setCombatModifier(int m);
getCombatModifier();
setHabitationRequirement(Object r);
getHabitationRequirements();
addPopulation(Population p);
getPopulation();
addImprovement(Object i);
getImprovements();
addResource(Object r);
getResources();

This is important to do as early as possible, actually. Because hard-coding the info means all that code will have to be modified later -- a serious waste of time, especially once the program gets complex (which it already is!). There will be plenty of coding to be done without having to go back and redo anything.

It's also important to consider that instead of variables for movement modifier and combat modifier, we can use objects/systems to create dynamic modifiers. If that is to be the case, it needs to be known now, before too much code gets written relating to the movement/combat of units.

Otherwise, we lose power (the ability to have a dynamic system) and we lose time (all that code that has to be changed). And we lose customizability, as you noted.

In other words, if we don't do the object design up front, the world will come to an end and children will begin listening to Lawrence Welk! And I wouldn't wish that upon our children at all . . .

[alms66]

Another thing about units moving across terrain is the climate.
For example, Hannibal tried to get something like 38 elephants across the Alps. One of those elephants made it, they just aren't cut out for the cold.
The same is true for explorers in the arctic. Many explorers tried to reach the north and south poles. Many of those early expiditions failed because the people died in the cold.
I think we should try to include somethink like this in the game.

[Richard Bruns]

I don't think that climate will change the movement rate much, but you are right in that it should change the rate of attrition your armies suffer.

[Mark_Everson]

Richard:

This model is meant to generate a realistic map based on scientific principles. That is distinct from the "active" map in the Clash game per se, and any map editor that derives from it. For these reasons, most of the stuff that you described is already planned (and some of it implemented in code) but there is no mention of it here. Some of that there is no distinct mention of anywhere except in the code.

That said, I don't know exactly how we are going to handle a lot of these issues. And one new thing that I'm glad you brought up was the possibility of people living at sea. I had the notion of Clash being ahistorically limited game, so it never occurred to me that we might actually want to have people taking up shop on or under the ocean.

I do not think their roads should eliminate movement restrictions entirely. The reason is that as one gets toward more modern weapons, use of roads in combat situations becomes problematic. As they near a battle site (or are subject to aerial attack) units have to disperse over a much wider area than the roads can accommodate or they will suffer tremendous losses. You can see my general thoughts on this (which are probably wrong at least several specifics) in the current military thread under the ticks system.


F. Smith:

You know, my initial attempts at organizing the Clash project, which you were part of, involved carefully crafting everything upfront and then beginning coding. You know what happened??? Everybody, including you, took off about one month into the four-month process. While I agree with you in general that we should do as much up front as possible in terms of coding specs, there is only so much we can do. Each programmer will do their own coding definition as they have time. I know that this somewhat cavalier way in which we are going to do it is going to involve some wasted effort. But when put up against the risk of the project imploding because of insufficient progress in terms of demos and such, that cost fades into insignificance. We are not a professional project that has a known amount of resources, and can call on them at will. Our extremely valuable programmer time must be put into making tangible progress, not ornate specs. Your commenting on some other part of our approach would IMO be more valuable at this point.

[Richard Bruns]

Mark:

You're exactly right. I wasn't talking about combat movement. My view is that a unit can move on a road over bad terrain with no penalty, but if it is attacked it suffers the same kind of penalty as a ship in port.

[F_Smith]

Mark:

It is true that finding qualified programmers is not easy.

But I don't think that is a reason to abandon architecting the system. My fear is that your current approach will allow things to move along until it gets highly complicated. And I was afraid that at that point the entire thing becomes so confused it can fall apart irretrievably. As you've said, as far as coding goes, what ya'll have so far is basically simple stuff, altho a ton of work has been done. It will get much, much more complex. You will have several complex systems, which are going to have to talk to other complex systems. A gui will have to talk to everything. And this can not be done with algorithms -- a comprehensive object hierarchy is your only hope for finishing this. Please take that advice as being worth exactly what you paid for it.

As I've said before, it is your project. I wish I had time to make your project mine, really I do. But life is life. I told you all this up front. As you know, I'm working on other projects as well. I'm sorry. I have gotten the feeling that my input is not proving valuable to ya'll, since most of the people on the project seem to disagree with my focus on a good object design as the heart of any program. So to avoid any more difficulties, I will now to go back to lurking, permenantly. I'll check back in from time to time, but I don't think my comments are proving helping to ya'll.

But one final thing: architecting the system does not mean doing a careful crafting of everything up front. Quite the opposite -- you build an object hierarchy and then a prototype, then refine the objects, then a new prototype, and on, and on. It gives you the demo versions you seek. And the models write themselves perfectly. I really wish I could communicate more effectively my understanding of software development. Ah, well. I truly hope that things work out for ya'll. I look forward to playing Clash someday soon.

Ciao, my friend. Please forgive me if I have in any way made things more difficult for you. May the road forever rise to meet you.