Demo 8.1 Goals and Plan

[Mark_Everson]

Please check out and comment on draft plan

Could everyone look over the draft D8.1 plan that i've outlined above. I would like to get agreement on it soon.

Thanks!

-Mark

[LDiCesare]

Mostly ok:

-AI for naval units including loading and unloading land units

This needs a scenario to test it. I can use Delenda for that though.

order to pursue/attack particular enemy TF

I don't get this one? Units can have a target "nearest enemy". I get that you mean to hunt the unit when it has moved, while currently they may stop in the square previously occupied and go onto something else?

some start on an over all military AI including fronts (demo 8.2?)

This one will need a dedicated scenario for testing too.

[Mark_Everson]

Originally posted by LDiCesare
I don't get this one? Units can have a target "nearest enemy". I get that you mean to hunt the unit when it has moved, while currently they may stop in the square previously occupied and go onto something else?

Correct, the nearest enemy order is nearly worthless now since it won't follow the enemy. An order that actually follows would make hunting down enemy TFs, and forcing combats much easier. There are obviously fine points involved, like smart pursuit paths and how much knowledge you should have about enemy unit movement, but we can discuss them later.

Thanks for checking it out Laurent.

BTW is the AI threaded now or is it done between turns? If not threaded is that a good goal to get into the near-term plan? Esp with larger maps it will make a big difference.

[LDiCesare]

The ai is not threaded and will not be anytime soon. I think it would only lead to more concurrent modification exceptions if it was run at the same time as the game logic changes things (like kills units). I'm not familiar with multi threaded programming and my first tries were much slower than the unthreaded version. The ai would require a deep copy of its world view in order for that to work and we're not there yet (it knows who controls a square it explored once for instance, and doesn't keep a copy of estimated enemy units). Such a deep copy will be needed for good functionality and is a prerequisite to fiddling with threads. I feel it would do more harm than anything if I try to do multithreading now. (I also remember Gary thought that this was generally a bad idea.)

[Mark_Everson]

Thanks for the info Laurent, obviously a longer-term thing. I still hope we can do it eventually since good AI will take Serious Time to process. And the only time the players wont mind it using is during the turn.

[alms66]

Originally posted by LDiCesare
I like neither settlers nor explorers. Settlers would just clutter the map. in my opinion. If you want to settle somewhere, commission some units, add population and move them. The random part disappears, but then migration cannot in real life be controlled by the powers that be, so having our random uncontrolled migration is something I like.

I wanted to bring this up again because, from this comment, I can see you misunderstood my intentions with the settler unit and since you never responded to my initial response to this, it's unclear whether I clarified it or not.

Now Settler probably isn't the best name for this unit, so let's forget I called it a Settler Unit - let's call it a Migrant Unit. In fact, Unit isn’t proper either, so let’s drop that and just call it a Migrant. The Migrant is a visual representation of the people who have decided to leave their home square and live elsewhere. They are not under the control of the civilization that spawns them. In fact, they could very well migrate to a tile in a neighboring civ’s borders.
The Migrant is automatically created under certain circumstances, such as when people decide to migrate due to the population limit on the square, when enemies invade or if there is a nearby city to move to. This isn’t a complete list of possible circumstances, but these three are reasonable possible to include in the current demos. For now, the only change to what we do with migration currently would be that instead of deciding a migration will occur then immediately teleporting the population, you create a Migrant in the square that the population is removed from.
The turn after the Migrant is created, it plans a path to the destination it would like to live in. This destination could be anywhere that has been explored by the player, but must not be the tile it is standing on. If that destination isn’t owned by anyone, then it could be treated as a colony of the mother civ (a new province – this would automate settling of distant locations so that the player wouldn’t have to load “settlers” on a unit and bring them to far off locations, though he still could, if desired), or a new civ entirely (if the Migrant is fleeing from oppression – but that type of behavior is for the future). If the destination is owned by someone, then the Migrant simply adds to that tile’s population and does not affect ownership.
The turn that the Migrant reaches its destination, it stops there, obviously. The following turn it settles down, adding to the population of the tile. So, basically, the only changes to the current migration code I’m suggesting is changing from a process that occurs in a single turn, to a process that takes three (or more if the Migrant doesn’t have infinite movement – that’s certainly open to discussion). In addition to automating long distance settling, this also gives the player a visual representation of migratory patterns, which, while not something you want to view all the time, is something that the player needs to be able to view.
This idea can be expanded far beyond simple population movement to cover refugees (as mentioned above and in the initial post), nomads (simply a Migrant that never stops looking for a new place to live), and any other sort of migratory behavior we need to model in the future.

Originally posted by LDiCesare
About explorers: Losing part of the map is definitely something I shall never code. It's just bait for "let me write the map on a paper please". Making an explorer unit with low supply cost and low attck/defense scores is entirely possible right now. Even making it with a small amount of personnel and pitiful morale you would achieve most of what you describe, except the 10 turns limit. This limit I can understand as "amount of supplies you carried" but I am also pretty sure I would rant if my unit reached the limit one turn before it had reached the spot I wanted it to go to.

After my last post regarding explorers, I realize now that even though that approach was fun, it’s not really realistic.

I still feel very strongly that we should do our best to discourage exploration with military units. The only historical “exploration” of terrain that occurred with military was really an army conquering unknown lands as it went. Historically, leaders have commissioned explorers though and, at most, given them a direction to explore in. Egypt, for example, commissioned explorers to sail down the coast of Africa to find new trade routes. Columbus was told to sail west and find a viable trade route to the orient.

In order to model this correctly, we need explorers. Though, I’m now thinking that we may want to do this in a similar way to the Migrant that I explained above. It’s similar, but not the same, so I’ll go through a detailed explanation here as well.

The civ needs to first commission the explorer (I’ll leave the details of that open for debate). Once the explorer is created, the player issues an order of explore DIRECTION and LENGTH, where DIRECTION is one of the 8 directions of the tile and LENGTH is the amount of time the player wants to devote to the expedition (this has a huge factor on the cost of raising the unit, as most supplies are taken with the explorers). The explorer then vanishes from view for the amount of time desired by the player (we’ll need to provide some sort of GUI depicting the expeditions underway, with their Direction and Length – or time remaining). When the explorer returns, it provides the player with a fresh map of the areas it explored. Once the map has been given by the explorer, we could either force a disbanding or allow the player to send it on another expedition.

Now, what actually happens when that explorer is “gone” offers some interesting possibilities. Historically, there have been many expeditions which have never returned from where they were sent, thus I think Clash should actually put the explorer under AI control and have it maneuver around the map. This opens up the possibility of disease or disasters finishing off the explorer (later), attacks wiping out the explorer (can do now), attrition of tiles killing off the explorer (we could probably do this now, though it may not be worth it), or even contact (or news) of new civs being brought back home (not to mention disease being brought back – again later).

Anyhow, do you think this approach is better? I think it is. And since most RTS games nowadays have an auto-explore option and people were begging for an auto-explore option on the civ3 list (same on the civ4 list I think), I think most players would actually welcome this sort of automated exploration, though some will hate it, but in a good way, when an expedition doesn’t return.

[Mark_Everson]

Hey Alms:

Originally posted by alms66
So, basically, the only changes to the current migration code I’m suggesting is changing from a process that occurs in a single turn, to a process that takes three (or more if the Migrant doesn’t have infinite movement – that’s certainly open to discussion). (etc.)

This is very similar to what the long-term vision for migrations. The current migration code was meant to be a crude first step that was reasonably easy to implement and didn't chew up too much processor time.

After my last post regarding explorers, I realize now that even though that approach was fun, it’s not really realistic.

Once the explorer is created, the player issues an order of explore (snip). The explorer then vanishes from view for the amount of time desired by the player

Seems like a decent proposal to me. But given all the code infrastructure needed to do this, I'd put the idea on hold for a while, with the possible exception of having a new explorer unit.

[LDiCesare]

Settlers if limited to long range migrations (or exodus) are okay. I don't want to see them for one square or one turn move. (Attacking them and killing them looks like a fun prospect.)
The explorer ideas presented here look good. But then again it's not going to be coded soon.

[alms66]

Originally posted by LDiCesare
I don't want to see them for one square or one turn move.

Sometimes I (and I think you as well) would want to, though not always, so I'd suggest an option to turn off internal migrations (those within your own borders) off. I'd suggest the same for external migrations (those outside your own borders). This option should not be a simple on/off switch, but a number which indicates the minimum distance of migration the Migrant must plan on moving before the Migrant is shown on-screen.

For example, I might set the Internal Migration limit to 5 and the External Migration limit to 10. This would mean that any internal migration would have to plan on traveling at least 5 tiles to be shown to the player (otherwise it still occurs, it just isn't shown), while any external migration has to plan on traveling at least 10 tiles outside your border to be shown to the player (otherwise it still occurs, just isn't shown).

In addition to these two options, I'd also have a third option, which could be a simple on/off switch, called "Show Foreign Migrants", which, when on, would show any foreign migrant in the player's visible area. I doubt anyone would want/need qualifiers for this one since, as a player, I would either want to see them (to capture and/or kill them) or not.

[LDiCesare]

Here's my current status based on original list:

AI:
-Checking ai siege and reinforcement code. (mostly OK )
--> Reinforcement uses PursueUnit which should be better.
--> Siege simulations used no wall - this is corrected.
--> But Reinforcement should avoid moving units by singles...
-AI for naval units including loading and unloading land units (0%)
-AI for exploration ( OK )
--> Need testing. Note the ai uses the same cheat as the player that lets them see the path into the black and thus know sea/land squares.
-order to pursue/attack particular enemy TF ( OK )
--> PursueUnit replaces previous plan.
-AI knows to attack province capitals ( OK )
--> done. Could be refined as the value is only that of the square.
-AI to compute the distance for take capital plans ( OK )
-AI to split taskforces when they are too strong for their target ( OK )
-some start on an over all military AI including fronts (demo 8.2?) (0%)
-some start on overall planning [The ai would be much better if it had a high level planning that decided whether subplans should be explore and defend, attack and defend, attack explore and defend, and what in what proportion. Add in shifting economic stance from peace time to war time eventually] (demo 8.2?) (0%)
--> AI to use a better map view with knowledge of where enemy units were when last seen, etc (20%).
--> This implies a change in the map display code because if someone doesn't know a city is in a square, then they shouldn't see it. ( OK )
--> This MapAI will then be usable to have better knowledge of enemy positions, and to better assess the value of each square depending on military presence. Also it should help exploration.
--> Needs icons to show where battles happen(ed). ( OK )

Military (Laurent)
-refine city wall availability, cost and effect (0%)
-supply level affects movement rate (can be offset by foraging which can damage economy) (90%)
--> Affects movement rate, foraging not taken into account.
-Add some wall vision capability ( OK )
-Reduce visibility of units so cities/walls expand the "explore" radius but not the "visibility" radius.

Tutorials (alms)
-overall intro (Dawn)
-economy, military, government/social, and technology

Diplomacy (Vovan, Laurent)
Some diplomacy with the ai to handle it. Simple ways to handle war to peace and peace to war transition. adjust depending on what Vovan thinks he can achieve

technology (alms, Mark, Laurent)
more complete ancient Tech tree. As has been pointed out many technologies will need game functions
before they are interesting to the player. Integrate technology changes better with economics and social models, and modify military model as needed. Take ten to twenty technologies that currently have no effects and give them game effects
- need some more combat activities: Ground Combat, Naval Combat, Siege Combat...( OK )
- integrate activity tag with subtag weight/rank inside technology tag (20% - activity now has a wieght instead of proportion so you don't have to do all the compuations by hand, but it's not yet integrated)
- add message when new unit becomes available - also lets see what's available at startup if you show the events on first turn ( OK )

Government and social models (Laurent, Mark, alms)
Enhancing social model code. Give all government social policies meaning in terms of economic productivity, technological development rate, military effectiveness, and in other areas as appropriate.

Economy (Mark)
-outline rudimentary economic AI to handle war to peace transitions, and perhaps several different philosophies of economic development.
-population growth depends on more than food (infrastructure, medicine level, etc.)
-real military supply system, food for troops comes from somewhere identifiable, supplying troops outside of civ becomes expensive (8.2?)
-economic effects of troops and battles, pillaging...
-use return-on-investment criteria to produce a right-sized army with few player orders

Scenario editor (Gary)
progresses as time is available (demo 8.2?)

Miscellaneous (TBD)
City Creation Ability (founding cities at least, but automated creation would be extra gravy). One thing that could be done is to automatically chose cities as capitals of provinces instead of the current system (when a province is lost). Plus relocating capital by the ai.

Graphics
-show provincial and civ capitals on map (star in civ color or something) ( OK for province - needs another graphic?)
-rivers and lakes (8.2?)

[demipomme]

Love the idea of a migrant unit. Definitely under AI control, with militia level attack. Interception of migration would be great fun.

Originally posted by alms66

I still feel very strongly that we should do our best to discourage exploration with military units.

I agree, but is a unit the best way of doing so? Perhaps it should be modelled like diplomats and spies, i.e. an options window where you select investment and desired area of exploration.

Also on this issue, much of the map would be revealed by travellers and traders in an unfunded manner. Perhaps in the turn dialog it could say "Travellers arriving from distant lands have given us new information about the world outside our borders" and then update the map. The amount you recieve these updates would be proportional to a nation's trade significance.


EDIT: Would be cool to have a "Jump X turns" button, especially for testing demos.

[LDiCesare]

I agree, but is a unit the best way of doing so?

I think we all agree units aren't the best way of exploring. Traders, spies; tourists (well, rather the epansion of people of your facored ethnic groups) and abstract commissionned explorers could probably give maps to the player.
Jump X turns could indeed make a comeback. Jump 10, jump 100, or jump and provide an input?

[Mark_Everson]

Originally posted by LDiCesare
Jump X turns could indeed make a comeback. Jump 10, jump 100, or jump and provide an input?

How about 3,10,30, and 100? That would do it for me, and be easily done with a drop-down menu. The real difficulty to do it right is to have the auto-turns terminated when a specified interrupt condition happens, FE War declared, rioting generating military units, etc. But that can be for the future.

[LDiCesare]

3,10,30,100 sounds good. A drop-down menu too, but our drop-downs tend to pull down anywhere but where they should, so I'll probably have to fix that first.

[alms66]

Why not let the player specify the number of turns to jump?