New and Modified Scenarios

[LDiCesare]

The only ones I can remember right now is in that it's not possible to have a civilization sub-tag in <unit>, and several events can't be contained within <eventjoin>, <eventunion>, etc.

I fixed the eventunion and such so that all events can be contained in one another. The unit tag doesn't sport a civilization subtag, but the element does. I agree that it should probably be the other way around, or maybe both.

As a side note for planning demos, I won't be able to make big progress on the ai until probably april (it requires lots of focus, and I am a bit busy right now), so I'll mostly fix things until then (and maybe add a military panel).

[Martin the Dane]

Thanks Laurent, that'll make things a lot easier. And yes I think both units and elements should have the civ. subtag. (btw. what about making "civ" an abreviation of "civilization" for tags)

Thanks for the suggestions Mark, but until I get an updated version where the squares does not loose farms when I add pop to the map, I'll have to make the minor civs. start at 5-6000, or they won't grow at all, and I need the populated squares to work out the events.

[Mark_Everson]

Originally posted by Martin the Dane
Thanks for the suggestions Mark, but until I get an updated version where the squares does not loose farms when I add pop to the map, I'll have to make the minor civs. start at 5-6000, or they won't grow at all, and I need the populated squares to work out the events.

Oh Crap, I hadn't ever put it together that the mechanism could Lower farm sites! I'll fix that right away.

All:

We now have numerous fixes and minor features done. I've finished most of the xml for econ and written up the documentation. As soon as I get everything compiled from all the sources I'll send out a new version of the code and testbed. Hopefully that'll be soon!

[Martin the Dane]

Thanks, Mark.
I'll just go ahead. I can work out most of it without the farms, and then finetune it when I get the fixed version.

[LDiCesare]

Thanks Laurent, that'll make things a lot easier. And yes I think both units and elements should have the civ. subtag. (btw. what about making "civ" an abreviation of "civilization" for tags)

Actually, civ instead of civilization would be a bit painful. (If Gary surfaces, ask him why abbreviations are evil).
The way to go would be to provide a dedicated editor (Richard did an online one for the tech model - check it if you're interested), but we don't really have time to spend on that now.
Among the fixes Mark talked about, I added an addpopulationevent as requested.
I'll try to put the civilization tag in units too when I am not too lazy to do it.

[Richard Bruns]

I vote for getting rid of the automatic farm site adjustment, and reducing the populations in Attila and Delenda until they fit the standard terrain values. Balancing tech growth between the early scenarios and the roman scenarios has been a chronic headache, because there are simply too many people in the latter. The imbalance also shows up in the number of military units available. IMO the empires in those scenarios should be similar to what a player would get if they grew their civ from a standard start.

For a long-term fix, 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.

[Richard Bruns]

One more thing. How do I edit the credits? There are several artists that will have to be mentioned. And how much effort would it be to change the code so that both of the colors in the background of civ2 units are set to transparent?

[Martin the Dane]

Richards solution to the farms/ressource units seems fine to me. The same goes for the time scale factor idea. It would be nice to have a few aditional scaling units, that would override parts of the effects of the general scaling units. Ok now I'm starting to sound confusing, so I'll try with a list.

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.

There are probably a few more that would be relevant, but this is long-term (so programers don't panic ).

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

[Mark_Everson]

Originally posted by Richard Bruns
I vote for getting rid of the automatic farm site adjustment, and reducing the populations in Attila and Delenda until they fit the standard terrain values. Balancing tech growth between the early scenarios and the roman scenarios has been a chronic headache, because there are simply too many people in the latter.

If we are going to unify the scales of these scenarios, I'd prefer to do it with the right values for population densities. If anything the dawn etc scenarios have population densities that are way too Low rather than the Rome ones being way too high. Population densities based on low-tech temperate agriculture are usually in the low tens per square mile. With squares about 60 mi on a side this gives populations per square of order 50k+.

The question then becomes is this the right time to make these changes to the scenarios, or should it wait until the release after this one.

For a long-term fix, 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. (snip)

I agree with you and Martin on this in general. Can one of you start a "Distance and Time Scale Settings for Scenarios" or some such thread? (And also put a link to it in this one?) There are some issues that have been discussed before that I need to bring up regarding time scales so that we can discuss them.

One more thing. How do I edit the credits? There are several artists that will have to be mentioned.

That is hard-coded for now. Just send me the additions in the same format as the current credits blurb.

And how much effort would it be to change the code so that both of the colors in the background of civ2 units are set to transparent?

I don't know on this one. You could post in the bug fix thread and see if someone who knows how to do it would be willing to take it on.

Hi Martin, why do we need the others beyond the inital two in your post? Anyway, if you can get together a complete wish list before we do the time and distance fixes (that will be a Big job, at least in Economy) we can try and write the code so that we get as many of your desired mod factors for free.

[Martin the Dane]

Hi Martin, why do we need the others beyond the inital two in your post?

It's to let the scenario editors finetune things, another thing is to allow radically different scenaioes. The final and most important reason is to allow for scenario events to influence these factors for a shorter or longer periode of time, simulating "black-death", golden age, etc.

Can one of you start a "Distance and Time Scale Settings for Scenarios" or some such thread?

I can do that, but I might want a "Secenario tags and settings" thread as well or in stead.

[LDiCesare]

And how much effort would it be to change the code so that both of the colors in the background of civ2 units are set to transparent?

Considering that if you save as gif with f.e. irfanview (freeware) you can set one colour in the palette as transparent, it is quite trivial to edit the images by hand to get the good result. I don't know much about the way java handles images, but I for one don't know how to manage it code-wise.

[Richard Bruns]

I can make one background color for the images. The reason I asked is that the artists use the two background colors to sign their images, and changing it to one background color erases their signatures. I wanted to avoid that is possible, but it is not that important.

[Mark_Everson]

Richard:

Just tried your 7.6 version of delenda. There's some pretty cool stuff in there! I think it will be much more of a challenge with the AI tweaks Laurent has put in that are in the 7.7 testbed. I'll try the others out as I have time, though I may wait for the 7.7 equivalents to come out first!

I am thinking about how to unify the farms scales between all the scenarios. At a crude level if we multiplied all farms and resources sites in the base terrain file by something like a factor of 3-4 (both farm and resource sites) it should work about right. That would still leave delenda with like twice the population density of the more ancient scenarios, but it wouldn't be nearly the difference there is now.

If you guys want to try that, its fine by me. If its not a huge headache balancing the tech, I'd leave it the way it is for now.

Cya,

Mark

[Richard Bruns]

Originally posted by Mark_Everson
Just tried your 7.6 version of delenda. There's some pretty cool stuff in there! I think it will be much more of a challenge with the AI tweaks Laurent has put in that are in the 7.7 testbed. I'll try the others out as I have time, though I may wait for the 7.7 equivalents to come out first!

Thanks. Unfortunately, I will be away for some time next week, so the update could take a couple of weeks, especially if I start experimenting with the econ model.

Can we start putting my changes in the official testbed? Once Martin finishes converting Dawn to my new defaults, there will be no reason to keep the old stuff.

I am thinking about how to unify the farms scales between all the scenarios. At a crude level if we multiplied all farms and resources sites in the base terrain file by something like a factor of 3-4 (both farm and resource sites) it should work about right. That would still leave delenda with like twice the population density of the more ancient scenarios, but it wouldn't be nearly the difference there is now.

Multiplying be 3 or 4 would not be enough. Default values are 8 to 12, and the populations in delenda need 80 to 120 sites to keep forn starving. I may just go through that scenario and reduce all the exponents in the population map by one. Or I could multiply the defaults by ten. I´ll try various things.

Ideally, increased populations would be handled by increased farming tech. But we need to make sure that the economy uses that tech on the first turn, so that no one starves.

[Mark_Everson]

Originally posted by Richard Bruns
Thanks. Unfortunately, I will be away for some time next week, so the update could take a couple of weeks, especially if I start experimenting with the econ model.

Thanks for letting me know. I may convert the 7.6.1 ones to be compatible with the new econ stuff if I have time. (No changes, just make them work with the new code, which will only take about a half hour I think.)

Can we start putting my changes in the official testbed? Once Martin finishes converting Dawn to my new defaults, there will be no reason to keep the old stuff.

We need Laurent's agreement on the army power specs. Since you agreed to use the older combined-arms approach as a defalt I think that's the only to be yet finalized. After that, I think its a good idea.

I am thinking about how to unify the farms scales between all the scenarios. At a crude level if we multiplied all farms and resources sites in the base terrain file by something like a factor of 3-4 (both farm and resource sites) it should work about right. That would still leave delenda with like twice the population density of the more ancient scenarios, but it wouldn't be nearly the difference there is now.

Multiplying be 3 or 4 would not be enough. Default values are 8 to 12, and the populations in delenda need 80 to 120 sites to keep forn starving.

I'd said "That would still leave delenda with like twice the population density of the more ancient scenarios, but it wouldn't be nearly the difference there is now." A factor of 2-3 difference doesn't seem like such a big deal. Differences much larger than this will occur naturally as we play the game. BTW Some of the really large numbers of sites may be meant to simulate imported grain in a crude fashion. Esp. for Rome and Carthage.

[QUOTE]I may just go through that scenario and reduce all the exponents in the population map by one. Or I could multiply the defaults by ten. I´ll try various things.[QUOTE]

I don't like multiplying defaults by 10, that will make populations too big in the primitive settlements. I guess reducing the Rome and Attila ones by 10x wouldn't bother me that much as a temporary thing. But I do think we should change the site numbers to the more-realistic ones fairly soon anyway.

Ideally, increased populations would be handled by increased farming tech. But we need to make sure that the economy uses that tech on the first turn, so that no one starves.

Yep. Roman Agriculture should be probably 2-3x as effective as that in Dawn. Of course taxes will be higher too! I think getting all the tech turned on for turn 1 is very important. If Laurent doesn't have time to do it soon, I'll take a look at it. It should be fairly straightforward.