Planning for Demos 7 & 8

[Mark_Everson]

Thanks Dale!


Laurent:

I posted this above, but wasn't sure if you have seen it.

Another thing is that units built in a square should draw population proportionally from the entire province. That is especially critical in Dawn, where even 2000 people is going to be a Substantial proportion of any square's population.

I have now redone the way military units are built across an entire province. (The old way had some defects.) The units when built in this aggregated way appear in a square selected randomly with the chance of each square being the home of the unit proportional to its contribution to the build cost. But now that its done that way, builds have a small probablility of happening in a square without enough population to build the unit. That's why I need the change quoted above.

Thanks!

Mark

[LDiCesare]

OK Mark, I'll do it. Any clue where I should look for those proportions? I'll tackle this this week end. I have to merge all the tons of code you and Gary flooded my mail with while I had trouble accessing it.

[Gary Thomas]

I am back from a pretty bad bout of illness.

Since I have got so far behind on commenting on things, these remarks will be a bit scattered.

First, Dale, I was really impressed by your effort in preparing the Dawn prompts. To reproduce the various levels of text size and emphasis the text will need to be in html format (properly presented these will appear correctly in a Java frame). I can do the conversion if you like. The display panel code is written and I expect to finish debugging it today (here it is 10 am Friday).

On the subject of unit sizes (and posting in the wrong thread, seeing I am responsible for the military model), I have always felt that units (elements, actually) should be of variable size, with the size specified as the number of soldiers in the element. The present system appears to be designed with a tactical level battle system in mind. This in itself contravenes Mark's idea of grand strategic battels. I find the fixed size elemnt concept wrong in historical fact and in terms of the game objectives. It also leads to a lot of code complication, without, I feel, adding anything to game play. My preference would be for elements within a unit to be all different (cavalry, heavy infantry, skirmishers, missile troops, and so forth), rather than having an archer unit with 8 archer elements and 2 skirmisher elements, for example.

I would have no problems with a unit consisting of a single element containing 100 scouts, for example. In this way, the size of the forces could be adjusted to the context.

Hans Delbrucke is an author I have a lot of time for (though others disagree). In his monumental history of warfare series he has a lot of comments on army sizes, most of them I find convincing. In particular he gives the following figures:

Greek and Macedonian:

1. Athens total hoplites: 5000
2. Sparta total hoplites: 5000
3. Corinth total hoplites: 1500
4. Thebes total hoplites: 2000
5. Both Greeks and Persians at Marathon: 4000 - 6000
6. Plataea: 5000 Spartan hoplites, 5000 Athenian hoplites, 10000 other hoplites and 20000 unarnoured men, 40000 total, with the Persians having a similar total.
7. Granicus and Isis, Alexander about 30000 men, with the Persians probably somewhat less.
8. Gaugamela, Alexander with around 47000 men.
9. Battle on the Hydaspes, Porus had only 85 elephants.

(these from pages 63, 72, 112, 185, 210, 220 of "Warfare in Antiquity")

Roman:

1. Cannae, Romans 55000 hoplites, 8000-9000 light infantry and 6000 cavalry.
2. Cannae, Carthaginians 32000 heavy infantry, 8000 light infantry, 10000 cavalry.
3. Carrhae, Romans 36000 total.
4. Bibracte, Caesar 36000 - 40000 total.
5. Subjugation of the Belgae, Caesar 50000 combatants.
6. Alesia, Caesar 70000, Vercingetorix probably 20000, with the relieving force about the same size.
7. Civil war: Caesar 11 legions, Pompey 10 legions.

In "The Barabarian Invasions" we get:

1. Augustus's 25 legions, with support troops: 225,000 men (equals 1/3 of 1% of the population, in the tensest period of the 2nd Punic War the figure was 7.5%).
2. None of the various barabarian forces exceeded 15000 (and this was quite large). Many of the battles had less than 1000 barbarians involved.
3. By the 4th Century the Roman army had degenerated to an immobile militia, all the actual fighting was done by Germanic or Asiatic mercenaries.

With the advent of the dark ages, the ability to sustain and supply large armies disappeared, with the result that an army of 10000 was a very large one.

FE the 4th C Roman Empire had a standing army of something like 350k [Penguin Atlas of Modern History, p5]. Even at 5k/unit that's a LOT of units.

Almost all of these were actually just farmers, who had a sword hung over the fireplace. There were maybe 50000 available, effective, mercenaries, but spread over the whole empire. And unreliable too.

I do have one major concern about unit size. 5000 men? OUCH! That's HUGE! Even by Roman standards that's 5 Phalanxs!!!! Remember how the Romans came up with unit hierarchy:

- 10 slaves = company (they would pick up weapons when attacked) (10 men)
- 10 companys = legion (100 men)
- 10 legions = phalanx (1,000 men)
- 10 phalanxs = army (10,000 men)

Dale, this seems pretty fictional to me. Do you have any sort of reference. I can't accept a legion of 100 men. Nor did the Romans refer to a "Phalanx".

5000 = 2500 men + 2500 women
2500 men = 833.3 kids + 833.3 young + 833.3 old (just averaging here)

For Germanic tribes, Delbrucke gives around 1/4 of the tribe as warriors (barbarian warriors did not retire!) which gives 1250. Still a bit small for our unit.

This really should be in the military thread, but since it is definitely relevant to Dawn 1, I have posted it here.

Cheers

[Mark_Everson]

Hi All:

I think we need to try and push to get D7 out in the next 2 weeks or so. Its time to pull it all together and show off what we've been working on! I realize two weeks may be cutting it a bit close, and obviously we won't release until we're ready. But lets push for two, and accept three weeks if we have to.

To that end, please, everyone that hasn't, look over the Plan and Tutorial draft in the posts of the previous week in this thread. Lets get agreement on the final specs and divide up the work! I will be sending out another version of the testbed with the working events model from Gary probably tomorrow (I need to add a little bit of code of my own).

Various team member issues...
Richard is out for a bit more, on vacation, but hopefully he'll be able to check out tech when he returns. Laurent may be limited in what he can do since he has to get a new comp. this weekend.

Looking forward to gettin' this baby out!

[Mark_Everson]

Well, since time is passing by, and nobody has objected to the plan developed about a week ago, I'm going to post a tentative to-do list and start working on it. There are several cases where we can do something by xml, in which case its Gary's job, or we can do a quick kludge, in which case someone else can do it. One example is in setting starting tech levels by civ. This can be done via xml, or by just a quick lookup of the scenario name, followed by loading the correct values. Gary, I'll wait to hear your preferred ways of doing these.

The list is not in priority order. A preponderance of the items are discussed in posts above, if the short version doesn't make it clear what needs to be done.

0. Check D6 bug and small feature list and determine which items designated for D7 need to be done at this point. (Mark will prioritize, Ideally some of the new coders can find some of the bugs as their small starting projects.)

1. removing population from the province as a whole upon unit build (Mark)

2. Ship boarding GUI (Gary)

3. Small AI improvements per my suggestions in the D7&8 thread (I'll do this if nobody else takes it)
Plus AI takes over just plain squares once cities taken (Mark)
More AI stuff detailed below.

4. BuildingOrders xml issue -- in BuildingOrders, currently always use false, false for the last two arguments That is not correct. Several of the items have arguments that aren't false. (Gary)
Implement many orders as hidden for Dawn1, hide a few for Delenda (Mark)

5. switch the hidden map off in Delenda (fairly low priority, can skip)

6. As far as indicating that units have settlers, I [Gary] have tracked down a wagon picture and will arrange it as a small overlay on a settler carrying unit. (Gary)

6b. Fix settler bug where using only part of colonists attached to mil unit to settle results in part not used disappearing. (Mark)

7. Dawn tutorial (Dale)

8. Use events or other mechanism to put barb incursions into Dawn1
[Implementation issues: determine whether to use Events model or hard-coding to generate barbarian appearances. ] (TBD Gary if XML, Mark otherwise)

9. use discovery of the horses tile plus generation of horse technology research points (say once you settle the horse square, or given as a big blob of RPs upon discovery (Gary)

10. specify technology levels for civs at the start of the scenario. The Dawn scenario is pretty much ok starting at minimum tech levels, but levels for many techs in delenda should start near a value of 10 or so. (Gary if done by xml, Laurent or Mark if a kludge)

11. Victory Conditions Dawn1 achieving building of a chariot unit (Gary)

12. Give civs default economic orders that will use their production capacity effectively. (Gary for xml, Mark for specific orders )

13. Difficulty levels modify initial force levels. Propose this be done as separate scenarios for now. FE Dawn1 and "Dawn1 Hard" Actually, I guess there would need to be two versions of the Hard one in Delenda, since there would have to be a "hard playing Romans", and similarly for the other side. (Mark)

14. Even though Hannibal is a large task force/command with phalanx and light horse components, the light horse always outruns the phalanx, giving Hannibal much less odds than would be the case if the TF moved together. I think that's a bug it's important to change to give the AI some punch. Another confusing feature of this behavior is that when you click on a square with any component of the Hannibal force, you see the whole thing. (Mark or Gary if I can't figure it out!)

15. Another AI problem was that sometimes AI forces just sat there even when there were plenty of city targets available. (Mark or Gary)

16. Low-manpower versions of units for Dawn1. Maybe 1000 or even 500-man units. (Laurent)

17. Fix domesticate Wheat message bug (Gary)

18. When in move mode, if you right-click on the target square, movement path shows as normal, but moves are never executed. Is this a bug or a feature? (Gary) If its a feature we should explain it in tutorial.

[gonzo_for_civ]

"18. When in move mode, if you right-click on the target square, movement path shows as normal, but moves are never executed. Is this a bug or a feature? (Gary) If its a feature we should explain it in tutorial."

AAhhhh!!! I was playing 6 and i think this is what was happening. I have been playing Demo6 for the last few days a lot trying to come up with ideas and suggestions.

[LDiCesare]

I played the Dawn scenario based on the june 9 source Gary sent.
Here are a few remarks: I mark with a !!! those that are more important.

1!!!) It is difficult to know one's population. You can get it pe square but I found no way to get it civ-wise.

2!!!) Linked to 1. I had several squares with pop 50000, 30000, and covered almost all the map with squares popluated by at least 1000, and the game didn't end. I thought for a while it should end at 200000 and not 20000 but it continued. Are victory conditions tested?

3) I settled, waited a bit, took a few people with the settler, and settled a bit farther. When there were enough squares settled automatically so they all connected, I had funny borders: Try it, I don't know how to describe it.

4)I took 500 settlers from one square, moved, and took 600 from there. I got 600 settlers only attached to my unit. I am not sure what happened to the 500 other fellows.

I think point 1 and 2 should be checked before we output D7.
The chariot icon down the unit is pretty good.

[Mark_Everson]

Hi gonzo_for_civ, thanks for checkiong out the demo, looking forward to your comments and criticisms!

Hi Laurent, you can see total population if you do civ econ orders and look at the labor number at the top of econ info. I don't know if we should have it prominently displayed somewhere or not...

I guess the VCs don't work yet. The xml says 30k is the population target IIRC. On the funny borders, this is a very early implemetation of that stuff, we'll get it to look better later! I understand what happens in 4, just need a fix in the code.

BTW, what do you think of changing "Primitive WarriorBand" to just "Warriors" or something? It overflows the name field in the econ orders menu...

[Gary Thomas]

I did not comment on Mark's D7 list at the time because I was too ill. Here are my observations.

0. Check D6 bug and small feature list and determine which items designated for D7 need to be done at this point. (Mark will prioritize, Ideally some of the new coders can find some of the bugs as their small starting projects.)

Good idea, I think. Is anybody actually attacking the minor bug list?

1. removing population from the province as a whole upon unit build (Mark)

I am very much in favour of this, and I understand that it has been done.

2. Ship boarding GUI (Gary)

Certainly this is escalating up the priority list. Whether it can be done for D7 is another issue. The problem is not the boarding, but the modification of the path-finding algorithm to allow ships to enter coast squares. I estimate about a week's work.

3. Small AI improvements per my suggestions in the D7&8 thread (I'll do this if nobody else takes it)
Plus AI takes over just plain squares once cities taken (Mark) More AI stuff detailed below.

I understand that this is being done.

4. BuildingOrders xml issue -- in BuildingOrders, currently always use false, false for the last two arguments That is not correct. Several of the items have arguments that aren't false. (Gary)
Implement many orders as hidden for Dawn1, hide a few for Delenda (Mark)

I think that this is now (finally!) fixed.

5. switch the hidden map off in Delenda (fairly low priority, can skip)

This is done.

6. As far as indicating that units have settlers, I [Gary] have tracked down a wagon picture and will arrange it as a small overlay on a settler carrying unit. (Gary)

This is done. Ugly, but done.

6b. Fix settler bug where using only part of colonists attached to mil unit to settle results in part not used disappearing. (Mark)

Will check this.

7. Dawn tutorial (Dale)

This actually requires some more code to allow the nicely formatted messages to appear. This is different and more comprehensive than the simple existing dialog action. However, it is not a big job. About a day's work, all up.

8. Use events or other mechanism to put barb incursions into Dawn1
[Implementation issues: determine whether to use Events model or hard-coding to generate barbarian appearances. ] (TBD Gary if XML, Mark otherwise)

This should be done properly, but I do not see it as a particularly big job. A day's work.

9. use discovery of the horses tile plus generation of horse technology research points (say once you settle the horse square, or given as a big blob of RPs upon discovery (Gary)

I am a little uncertain of how to implement this (though I agree that it is actually necessary for D7). I have, unfortunately, got a bit out of touch with progress of the tech model. I had assumed that techs would have possible conditions included, the tech is only activated when the condition is met. The problem here is that techs are currently (and, in my view, wrongly) global (like military units). I will make another post on that issue generally, since it has ramifications.

10. specify technology levels for civs at the start of the scenario. The Dawn scenario is pretty much ok starting at minimum tech levels, but levels for many techs in delenda should start near a value of 10 or so. (Gary if done by xml, Laurent or Mark if a kludge)

Part of the previous issue, and it should be addressed for D7.

11. Victory Conditions Dawn1 achieving building of a chariot unit (Gary)

Might need a bit of collaboration with Laurent and Mark, but I see no difficulty here. Perhaps 2 day's work at worst.

12. Give civs default economic orders that will use their production capacity effectively. (Gary for xml, Mark for specific orders )

In short I want to be able to have the Carthaginians have default orders to
use 40% of tax resources to build elephants and 40% phalanx or something like that.

I did not understand this, but, in a private email Mark sent:

(A) Give each side default economic orders that will use their production capacity effectively. At the simplest this could be putting all tax resources into building the best military unit available. (I would specify
best combined arms task force, but we currently don't have a way to mass units into TFs once they are built.) an alternative route for some of the taxes would be investment in military technology to make existing armies fight better.

This makes it a lot clearer. Mark, if you would write out for me the GovtEconOrdersInfo calls needed to achieve this (with a single float parameter where needed) I will add them to BuildingOrders. This seems to me to be the only way this can be achieved for D7.

13. Difficulty levels modify initial force levels. Propose this be done as separate scenarios for now. FE Dawn1 and "Dawn1 Hard" Actually, I guess there would need to be two versions of the Hard one in Delenda, since there would have to be a "hard playing Romans", and similarly for the other side. (Mark)

I will comment on this in a separate post.

14. Even though Hannibal is a large task force/command with phalanx and light horse components, the light horse always outruns the phalanx, giving Hannibal much less odds than would be the case if the TF moved together. I think that's a bug it's important to change to give the AI some punch. Another confusing feature of this behavior is that when you click on a square with any component of the Hannibal force, you see the whole thing. (Mark or Gary if I can't figure it out!)

Make sure that they are put in the same task force. If they still outrun, it is a bug which I will attack.

15. Another AI problem was that sometimes AI forces just sat there even when there were plenty of city targets available. (Mark or Gary)

Will look into this.

16. Low-manpower versions of units for Dawn1. Maybe 1000 or even 500-man units. (Laurent)

Done.

17. Fix domesticate Wheat message bug (Gary)

Done.

18. When in move mode, if you right-click on the target square, movement path shows as normal, but moves are never executed. Is this a bug or a feature? (Gary) If its a feature we should explain it in tutorial.

As noted in my email this is a feature, not bug. It allows you to check what path the path-finding algorithm is going to use. However, it becomes unnecessary if, for a bad path, the whole movement orders list can be cancelled (which it can) and redone. This is now my preferred method. The great advantage is that it makes a right click available for a popup menu, which is what it should be for.

Cheers

[Gary Thomas]

13. Difficulty levels modify initial force levels. Propose this be done as separate scenarios for now. FE Dawn1 and "Dawn1 Hard" Actually, I guess there would need to be two versions of the Hard one in Delenda, since there would have to be a "hard playing Romans", and similarly for the other side. (Mark)

Here we have a huge can of worms.

I agree entirely with the separate scenarios approach, now and forever.

If "difficulty levels" means the sort of nonsense that occurs in Civilization ("Chieftain", etc), then I am strongly against it, permanently. My reasons are several.

1. The literature on game design constantly stresses that the game should always be winnable. Putting in a deity level, for most people, contravenes this stipulation. It attracts NO new players, just makes some of the diehards a bit happier. Forget them, they are going to buy the game anyway. The more normal player is likely to feel that they have been unable to "complete" the game, and not bother with upgrades or other games by the same author(s).

2. The actual implementation of difficulty levels is fraught with pitfalls. At the simplest level, there can be sliders which crank up the probability of computer controlled civilizations winning things, or crank up their production level. This, I am convinced, dilutes the intent, and fun, of the game, and gives no positive (but many negative) effects.

3. The code implementation is exceedingly complex and has ramifications right through the code. A reasonable implementation would require around 1 to 2 months work.

Don't get the idea that I am against different levels of difficulty as such. In particular I would accept a tutorial mode which could be applied to any scenario (this is not the same as tutorial scenarios). This mode could allow various explicit cheats, so that the player KNOWS what is the effect of the tutorial level. This mechanism is a useful and helpful aid in the learning process. However, someone who completes a scenario at the tutorial level will not feel that they have really done that scenario.

Each scenario, at the normal level, should have provided an assessment of the level of difficulty for each Civilization involved. Overcoming the Roman Empire as the Essenes is probably a lot more satisfying than taking over the world as the Romans at "Deity level".

So, I believe that it is far better to provide graduated difficulty levels by providing graduated scenarios. Incidentally, random scenarios can be treated in the same way.

Cheers

[Gary Thomas]

I have been very concerned for some time now at the policy of having global data files. There has been a strong insistence from some quarters that every time the game is run, all the civilizations, regimes, religions, technologies and military units should be read into the program, even if only a small proportion of this data is used.

There are, I believe, two real problems with this approach.

1. The sheer volume.
I exect, for example, something like 10,000 different unit types being ultimately available. Probably this can be read in in 15 minutes or so. Maybe. Every time the program is run. Then, of course, the civilizations have to be read in. Then...

2. The fact that this is static.
It is my belief that every scenario should stand alone, and not be dependent on some global system decided by someone else. So, for the Delenda Scenario, we need Roman Legions. Maybe 5000 men per unit. For the Dawn 1 Scenario, we need a little band of warriors, maybe 1000. In either case we certainly do not need to read in the specifications for an Aegis Cruiser. Similarly the tech requirements, indeed the tech tree, is totally different for the two situations.

I have no problem with the idea of a library of pre-coded civilizations or units, but they should only be read in when required. The actual coding for this could perhaps be complicated, but, like all purely coding problems, it could be done. In fact, I believe that such a library should be accessed by a scenario editor, and the scenario should be built as a single stand-alone file. This would allow scenarios to be emailed around the place without worrying about dependencies. The present system is extremely messy and confusing.

For D7, I propose that we put the relevant parts of military and technology files into the scenario files (the civilizations are already done that way).

Cheers

[Gary Thomas]

For my own activities in the near future, I have, essentially four options.

1. Go over all the posts in the forum to make sure that everbody is fully informed on what is going on, and that every question is answered.

2. Debug and extend the current code, trying to get D7 out as soon as possible.

3. Work on the infrastructure of Clash. This is the part that really pays dividends in the long run. The work that I put into the xml system over the last few months has already made possible things that could not have been done in any other way. The next big infrastructure project that I see is to save and restore games.

4. Work on my pet project - random map generation.

It seems that the preferred priority is 1, then 2, then 3, then 4. My personal preference would probably be 4, 3, 2, 1, but then I have never pushed my own preferences very hard.

Are there any opinions on this?

Cheers

[Gary Thomas]

Since I mentioned game save/restore in the last post, I would like to outline the way I see it being done. This method has never been tried in any game, and I am a great believer in firsts.

1. All saves in xml format, zipped. If and when we want to stop people cheating by hand modifiying the xml file, we can triple DES encode it. That should stop them.

2. Each save to be incremental, recording only the things that have changed from the beginnning to the end of each turn. We do not need to record HOW these things changed. For example, a unit needs only to have its end characteristics recorded, and then only those that changed.

3. If bringing this up to date on loading proves to be slow, occasional summaries could be inserted, to skip moves up to a certain point.

4. At the end of each turn, the save file has a new zipped file added to the end of it.

So, a single save file for each separate game. Not the hundreds that Civilization inflicts us with.

Oh to be at the leading edge!

Did I mention polygons recently?

Cheers

[Gary Thomas]

I played the Dawn scenario based on the june 9 source Gary sent.
Here are a few remarks: I mark with a !!! those that are more important.

My comments on this.

1!!!) It is difficult to know one's population. You can get it pe square but I found no way to get it civ-wise.

Good point. I feel that we need a proper civilization summary. I rather think that the turn event (not the event model) mechanism could be extended to do this, divided into the four sections as it is now.

2!!!) Linked to 1. I had several squares with pop 50000, 30000, and covered almost all the map with squares popluated by at least 1000, and the game didn't end. I thought for a while it should end at 200000 and not 20000 but it continued. Are victory conditions tested?

Partly. At the time you tested it, the events did not work. Now they do, but I haven't had time to test the population part.

3) I settled, waited a bit, took a few people with the settler, and settled a bit farther. When there were enough squares settled automatically so they all connected, I had funny borders: Try it, I don't know how to describe it.

Each time you resettle, a new province is formed. I have "allow reorganization of provinces, task forces" on my to do list.

4)I took 500 settlers from one square, moved, and took 600 from there. I got 600 settlers only attached to my unit. I am not sure what happened to the 500 other fellows.

This is on the bug list.

Cheers

[Mark_Everson]

Hi Gary:

Well, that's quite a series of posts! I'm going to go through more or less in order and hit the high points with this post. That's probably all I have time for tonight. In general if I don't say anything it means I basically agree with your take on things.

The only active work on bugs presently is from our Demo 7 list. I am in the midst of updating the demo 6 lists , and will farm those out to anyone who is willing! I'm certainly going to dedicate myself to it as full-time as possible until Demo 7 comes out.

On #2, ship boarding GUI, a week to delay is more than I'm really comfortable with. It has been almost six months since we've gotten a demo out, and I'd really like to get Demo 7 out within a month or less. I guess it depends on what you and Laurent think, but my vote would be to do this as part of Demo 7.1.

#12

This makes it a lot clearer. Mark, if you would write out for me the GovtEconOrdersInfo calls needed to achieve this (with a single float parameter where needed) I will add them to BuildingOrders. This seems to me to be the only way this can be achieved for D7.

Will do.

"Difficulty levels" as in the sort of nonsense in civilization are in fact a long-term goal of mine. I want to be able to play a whole-history game, and be able to give any arbitrary advantages to the computer players that I deem necessary. If I spend a good chunk of a decade working on Clash, and can beat it every time, I will consider it an utter waste of my time. I agree there are some potential coding difficulties involved, and frankly don't give a damn what the latest enlightened marketing philosophy for games production says.

However, it appears that scenarios of differing level of challenge for the player would achieve my goals fine for the next several demos. Since that part doesn't bother you, let's focus on those, and defer the argument on difficulty levels for a later date. If worse comes to worse and I'm outvoted by the rest of the team, it would be simple enough to put in effective sliders at a few key points in the code to give me what I want, and I can have a "Mark version" of Clash if necessary.

On your third post, covering global data files vs. scenario-specific ones, I still, as in the past, prefer the global ones. However, if you are willing to code this central warehouse in which a catalog of items can be kept and drawn upon for scenarios, my objections are a lot less severe. Laurent and Richard (if he cares) are the major stakeholders in the current approach. I guess if they go along I've got no big problem with it. I frankly think your arguments by-hyperbole about 10,000 types of units are stretched extremely thin.

For my own activities in the near future, I have, essentially four options.

1. Go over all the posts in the forum to make sure that everbody is fully informed on what is going on, and that every question is answered.

2. Debug and extend the current code, trying to get D7 out as soon as possible.

3. Work on the infrastructure of Clash. This is the part that really pays dividends in the long run. The work that I put into the xml system over the last few months has already made possible things that could not have been done in any other way. The next big infrastructure project that I see is to save and restore games.

4. Work on my pet project - random map generation.

It seems that the preferred priority is 1, then 2, then 3, then 4. My personal preference would probably be 4, 3, 2, 1, but then I have never pushed my own preferences very hard.

Are there any opinions on this?

Well, you have me pegged. I would definitely vote 1-4, although it seems you've pretty much taken care of 1 at this point. I have to be honest in that there are a lot of things I would prefer to see before save and restore games. Getting the tech and government models, which are very far along, actually working in the game and with interfaces come to mind. I have never yet had a desire to save the game of Clash because simply not very much happens so far. Until we get to the point where a single game can hold someone's interest for more than a half hour, I maintain there is little point in save games. The only exception I can think of is if those save games are supposed to serve as scenarios for others. Axi is also hot on getting save games, and it's still eludes me why the two of you want them at this point.

As to the specifics of your save game plan, I've expressed my reservations with various parts of it when it was discussed earlier this year. It seems to me that keeping track of "what has changed" will require an enormous amount of code infrastructure that is much more likely to generate huge amounts of bugs and code confusion than anything a difficulty levels system could. I have to admit that the concept is intriguing. Frequently however there are very good reasons why nobody else does it a particular way... That said, most of us are in this project to break the rules, so I can't fault you too much on the last point!

I feel that we need a proper civilization summary. I rather think that the turn event (not the event model) mechanism could be extended to do this, divided into the four sections as it is now.

Sounds fine to me!

Each time you resettle, a new province is formed. I have "allow reorganization of provinces, task forces" on my to do list.

Yeah, that's a good one! Been meaning to bring it up myself.

It occurred to me while I was mowing the lawn today that there are no economic specials of any sort in either of the scenarios. (Aside from the possibility of making in Dawn either horse or wheat or both specials in an economic sense.) I seem to recall that you were pretty much ready for specials quite a while ago in the XML. Is there any reason I can't grab some of gar's images and put some specials in our scenarios? If I am overly-favorably remembering where progress is in this area, I'm willing to skip it. But if everything's basically done I'd like to go forward with it. I may even be able to do something with merchants on a quick basis... and would like to if I can come up with something worthy of the player's notice. Anybody got any good ideas on this?