Distance and Time Scale Settings for Scenarios

[Martin the Dane]

Richard Bruns brought up the question of distance and time scale settings in the New and Modified Scenarios thread.

This prompted me to post a few extra ideas and on Marks urging: this thred.

To the subject:
As map-scales are different for different scenarioes it would be a nice to be able to set scenario scale-factors in the scenario file.

Originally posted by Richard Bruns .. we can add a terrain scale value defined in the scenario file. This scale would represent the length of one side of a terrain square, and would adjust game values. So if the terrain scale was three, each square would have nine times as many farm sites and resource sites, roads would cost three times as much, and units would move one third as fast.

Similarly, a time scale value would also be helpful. The scenario designer should be able to switch the turn length to values other than one year. Setting the time scale to five would make units move five times as fast and multiply all economic activity, tech growth, and population growth by five. Allowing this time scale to be changed by events would be very useful.

This made me propose the following system:

Overall-scaling factors:

• MapScale - sets the length of one side of a map square. Resources and movement is scaled acordingly as per Richards suggestion.
• TimeScale - Set the turn-length, and scales movement and production as per. Richards suggestion.

Spesific-scaling factors:

• MovementScale - Scale the movement-speed of all units.
• ResourceScale - Scale the number of resouce sites/terrain. (maybe one for each type)
• PopGrowthScale - Scale the population growth factor.
• TechGrowthScale - Scale the tech-growth.
• EconScale - Scale the economic activity factor.
• BuildCostFactor - Scale the cost of building units, roads etc.

Except for the MapScale these scaling factors should be changable in events.

My reasons for the Spesific-scaling factors are:
- to let the scenario editors finetune things,
- to allow radically different scenaioes,
- and finally and most importantly: to allow for scenario events to influence these factors for a shorter or longer periode of time, simulating "black-death", golden age, etc.

There are probably a few more that would be relevant, so any comments and additions to this system are welcome.

To the programers: please comment on anything posted here especially if it poses any significant obstacles.

[Richard Bruns]

I don´t see any need for a TechGrowthScale, since the technology defaults already have all the tools you need to change the tech model. Just copy over the relevant bits of teh technology.xml file and change them, and they will get overwritten.

A way to change the costs of military units would be nice. I even tried to do this myself, with the existing xml files, by making an element called "Unit Cost" and having all other elements´costs default to that. It actually was possible, if I defined this unit before declaring the files-all tag, but it meant that if the scenario xml did not have that unit, the game wouldn´t load, so I abandoned that idea as being impractical.

[LDiCesare]

This strongly looks like it is very possible to do it.
Timescale and movementscale seem to do a bit of the same.
Timescale should set the timer for time/year display, then productionscale and movementscale should IMO be independant. That way you can even get timescale to something more evolved (Martin, do you know how that's made in CtP2? I think it is somewhat flexible - sets of periods or something like this).
The tech growth is already there in the globals of technology file. Some globals also exist for the military.

We just have to decide where these tags go (apart from time/calendar, I think they are all econ related, except for movement).

[Martin the Dane]

Originally posted by LDiCesare
Martin, do you know how that's made in CtP2? I think it is somewhat flexible - sets of periods or something like this

I don't know how its done for CtP2, but as far as I remember in CtP1 you set the timescale for each age so that each turn in the early ages are not the same as in the modern and futur ages. In Ctp1 you had destinct ages each having it's own citystyle, and number of years per turn. How it was set up in the mods, I'm not sure, but maybe Dale knows. (I was never much of a modder in CtP, spent my time programing tools for the modders now it seems my role is reversed )

Timescale and movementscale seem to do a bit of the same.
Timescale should set the timer for time/year display, then productionscale and movementscale should IMO be independant.

The reason I proposed to have two levels of scale-factors was to cut down on the number of factors that had to be set in case the scenario-designer decided to change those scales.

Seems like I should have been a bit more specific:
Changing one of the two Overall-scaling factors affects the whole game, while the Spesific-scaling factors affect only a particular area.
For instace changing the TimeScale to 2xNormal would have almost the same effect as pressing the turn button twice. And changing the MapScale by 2x would have almost the same effect as using 4 times as many squares.
Changing the MovementScale on the other hand would only efect unit movement (and possibly the population's perception of distance)

Originally posted by Richard Bruns
I don´t see any need for a TechGrowthScale, since the technology defaults already have all the tools you need to change the tech model. Just copy over the relevant bits of teh technology.xml file and change them, and they will get overwritten.

Excatly what I wanted to avoid. I want to be able to scale things with as little xml-editing as possible. Same reason I use constant-declarations when I write programs.

[Richard Bruns]

I think all of these tags should go in the <Scenario>tag. That is, I think, the most logical place to affect overall scale settings ofr the scenario.

I suppose that a TechGrowthScale could be useful if it simply multiplied the default growthrate in the technology.xml file. That way, if the default file changed, the ratio of tech growth would automatucally update.

I think it would also be good to have tags that change the base cost and upkeep of all military units. That way I don´t have to copy the entire miltary.xml file over to the scenario file just to increase or decrease these values.

[LDiCesare]

Richard just said the global constants already exist, you have to change them only in one place in the technology.xml file, but you can currently override them in the scenario file. Making them a multiplier of the default I am not sure is useful, but we can probably have 2 tags (I probably would need both anyway in the code).

[Simon Loverix]

Be warned that when using extreme scales (1/100 standard size for example) the game mechanics will still be optimalized for the standard size. So migration and economic rules will not be as realistic. This is a limitation of scaling.
But scaling will be very useful and interesting (what if humans normally were born as twins, doubling population growth rate? What if earth was twice as large? etc.)

[Mark_Everson]

Hi Simon:

Originally posted by Simon Loverix
Be warned that when using extreme scales (1/100 standard size for example) the game mechanics will still be optimalized for the standard size. So migration and economic rules will not be as realistic. This is a limitation of scaling.

I'm not sure this will be necessarily true. I would expect we would scale the things you are talking about also. Now obviously some dynamics will be changed. FE the fact will be that people will only diffuse 1km when colonizing instead of 100 when the map scale is at 1/100. But then again, they would soon be under pressure to migrate again. . . Does this seem right, or have I missed your point?

[Simon Loverix]

I'm concerned with things like cities for example: at size 100*100km, a square can contain a city, even several, and that is realistic. But at size 1*1 km or even 10*10 km the city, when growing should contain several squares instead of the squares containing several cities. A 1*1 km area is not even able to support a 6000 BC village, let alone several cities.
So at extreme scales the game mechanics become obsolete. It's like playing soccer on a chess board.
Actually, I think it would be best to design all scenario's as a world map. The game mechanics can always be applied, the world doesn't stop at the edges and things like the plague can sweep over the map realistically: it eliminates the need for random plagues, barbarian invasions etc. For those who want to limit a player to a certain area, we could make a scenario border: passable for the AI, but not the player.
And if that's not possible, small scenario's can use smaller maps instead of making large scaling changes.

[Mark_Everson]

Originally posted by Simon Loverix
Actually, I think it would be best to design all scenario's as a world map. The game mechanics can always be applied, the world doesn't stop at the edges and things like the plague can sweep over the map realistically: it eliminates the need for random plagues, barbarian invasions etc. For those who want to limit a player to a certain area, we could make a scenario border: passable for the AI, but not the player.
And if that's not possible, small scenario's can use smaller maps instead of making large scaling changes.

Hi Simon:

I don't think this idea is really practical. I think most scenarios will be scaled roughly so that they use roughly the same processing power as a whole-world game. To add on yet again maybe as much as 100x or more world to that just won't work. IMO we are stuck with the scenario designer specifying external events through the standard events model.

I am not inclined to worry about the 1-km square size sort of issues. But even then you could have four cities right next to each other. Instead of New York you'd have one named Manhattan, one named Brooklyn, etc. Opinions?

[Martin the Dane]

Hi,

I can se that Simon's concerns are valid, but I think the benefits of having scaling in the scenarioes far outweight the problems.

A possible sollution could be to have both upper and lower limits to the scaling factors. In this way extreme cases where the game mechanisms breaks down can be avoided.

[LDiCesare]

Even though the game mechanisms may not work well at small (or huge) scales, I don't think we should put limits. I admit the game may become buggy at funny scales (1km? why not a 1inch x 1inch square and play as ants instead of humans? err, wait, you may try to do that but that is not Clash intent...).
Scenario builders tend to profit from flaws in unexpected ways, use features in the exact opposite way from what was initially the reason of the feature (like downgrading units with Leonardo's workshop...). So it is free for them to experiment at low scales, or to add events if they want historical scenarios (or others) to follow some course. Processing the whole world behind the scenes would mean the scenario designer has to develop a whole world map in order to be able to scale one region. None would bother doing that.

[Simon Loverix]

Well, it was just a warning. I think that warning should be given to scenario designers also when using scaling and then they can find out the limits themselves.

Concerning whole-world-maps: One could design a whole-world-map for every century and to make a scenario. When a world scenario of, say, AD 1500 would exist, who would want to play a scenario that only comprises part of that world? Just set different goals and maybe change the culture of civs you want to be in the background to arch conservative. This does not apply to fantastic settings, true. It will be there that scaling will prove most useful.

[Martin the Dane]

who would want to play a scenario that only comprises part of that world?

Me! And I would want to be able to play a scenario of Europe with the same number of squares as in a whole-world map.

[Simon Loverix]

That is something you might want to do in civ, but clash is a different game. Civ is a combination of three scales: the world map, the city map and the unit map. In Civ, when a unit stands on higher terrain it gets a defense bonus. That's not right: to have a battle in an area as large as a square on the world map, the armies would be required to meet each other, and they would be in the same terrain, meeting each other and attack each other. No attackers and defenders, just facing armies. The higher terrain bonus does apply when two fighters meet on the battlefield, and one of them stands on a slope and is defending himself from an attack from below. Another one: you can cover the whole world map using all the cities of a single English county. On the map, the English island can not even contain three cities! Scale mixing, a bad habit.
Now, to return to clash: you would not be able to control more cities, more armies or move them farther because the map was larger. You would gain a larger landscape and lose the strategic oversight and nothing else, exactly because scaling would be used. The game would work the same, but now the distance a unit travels is represented by x squares instead of y squares. So there is no real reason to have large maps of small areas. People tend to give up halfway, when they have seen the map but not in the least conquered or dominated it. So as a conclusion: small areas, small maps.