Plans for D8

[Gary Thomas]

I am now working on the refactoring for D8. There are a substantial number of quite significant improvements involved, the most visible of which will be a reworked economics gui, and the ability to save and restore games.

There are, however, a number of contingent issues which need to be addressed.

My immediate problem is how to deal with cities. The way cities work now is that a map square gets flagged as a city (with a city name). There is no other effect at all. Cities have no effect on production, trade, population or social events. This seems to me to be rather underrating the position and capacities of cities.

I rather like the idea of, effectively, treating a city as a square within a square - it would have all the characteristics of a square (sites, population, economy, social model and so forth), but be treated and calculated separately from the containing square. Hence it could have quite different economic and demographic characteristics from the containing square.

We will also need some means of deciding when a city is generated in a square, but that would be an automatic process depending on population.

I would prefer to get some feedback on this before launching into the coding.

Cheers

Gary

[Gary Thomas]

I have just thought of an incredibly elegant way to implement cities in the way I suggested above, and may go ahead and do it. Implementing it will take nearly 30 seconds! Changing it back, if there are severe
objections, will mean changing a single line of code!

As a byproduct, it will allow more than one city in a single square. While we do not intend to have that, one must always remember the polygons lurking just over the horizon.

Cheers

[LDiCesare]

Why do I foresee unforeseen complications?
Anyway, the idea sounds nice although a bit too detailed IMO.
How will you raze cities?
What control do you have on cities/what are they here for?
I think they are mostly eye candy now. They give a name to a square, but unless you want to somehow give the econ GUI a way to choose from civ/province/square/city, cities (and square from the econ point of view) are useless, so how we model them is not very important.
The only point I see where gameplay would be affected is siege. Cities can fight sieges, and a whole new model for warfare would follow. You'd have a siege when the square is occupied by A and the city by B. But I let you think of the UI problems this provides. Lots of stuff to say "I attack the city with my cavalry" (well, maybe they should use catapults instead but...), or "I lay siege, and starve them into surrender", with an option like "if you don't surrender I kill or enslave you all", also "I try to rout the besiegers with my cavalry", "I ask the city to surrender", "I raze the city"...
Do you see any other impact of cities in a square upon gameplay?

[Mark_Everson]

Originally posted by LDiCesare
Why do I foresee unforeseen complications?

LOL! Why should this be different from any other changes

I have just thought of an incredibly elegant way to implement cities in the way I suggested above, and may go ahead and do it. Implementing it will take nearly 30 seconds! Changing it back, if there are severe objections, will mean changing a single line of code!

Hard to complain too much about that one, Gary. But isn't that a "future". Cities don't do much yet, and until they're ready to do so, I'm not sure what we gain. What do we gain?

In the long run my fiendish plans are to:

1. Have production bonuses for cities, especially during the Clash equivalent of modern (1500AD+) history.

2. Have trade bonuses for cities. Actually cities will be the nexus at which a province trades with the rest of the world. This is both an important RW (real world) effect, but also makes the merchant trading system much more manageable.

3. I've had vague plans for cities with walls and sieges as Laurent has brought up.

4. Because cities will be a different economic environment (due to 1 & 2) there will be population diffusion into cities for much of the game, making them economic prizes.

And I'm sure there are important things I've forgotten.

Those things that make cities unique in Clash are not ready for prime time in the game yet. So it seems to me worrying about city coding seems premature. (Then again if it only Really takes 30s I don't much care.) Siege rules and other city-specific military aspects could be pursued now I guess. Is that the most important thing to do in the military area? Could be... defensive fortifications are certainly an important part of ancient warfare. What do you guys think? Personally I think even the first crude step toward a military AI is more important, but that will clearly require much more time than the city stuff.

Once the econ refactoring is done, the trade aspects of cities will be relevant. I have to admit that absent city walls and sieges I don't see the advantage to specifying realistic cities now. I had pretty much thought that trying more refined cities should be done in conjunction with polygons.

[LDiCesare]

Military-wise, important things include:
- Naval warfare.
- AI.
- Healing of units.
- Siege warfare.
- Experience and training.

Probably in that order.

[Gary Thomas]

You both managed to cover a hell of lot of ground in a very few posts!

Why do I foresee unforeseen complications?

Deeply ingrained pessimism?

Anyway, the idea sounds nice although a bit too detailed IMO.

The interesting thing is that the code is hardly changed.

At present I have something called an AreaLevelClass which extends AbstractLevelClass. The AbstractLevelClass has things common to all levels (square - read Capital, port, name, description, abbreviation and a branches link). The AreaLevelClass adds a list of sublevels. SquareLevelClass extends AbstractLevelClass and the others (ProvincialLevelClass, CivilizationLevelClass and MetaLevelClass) all extend AreaLevelClass.

My proposal is to have SquareLevelClass extend AreaLevelClass and a new class (essentially identical to SquareLevelClass) called CityLevelClass extend AbstractLevelClass.

So then all the mechanisms are present to add (or raze) cities -everything needed is already there. As I said, about 30 seconds work. We can then use it or not. Personally I think that cities do have a current fuunction, as visual points of interest and as the squares on which things get built.

How will you raze cities?

In exactly the same way you remove a square from a province, but one level lower.

What control do you have on cities/what are they here for?

See above, and Mark's comments.

The only point I see where gameplay would be affected is siege.

This was one of my main reasons for wanting a separate city. The exact implications of a situation where a city is controlled by one player but the city by another will have to be worked out.

Cheers

[Simon Loverix]

Multiple cities close together are difficult, primarily for display reasons. While we are using squares it is best to assume that there is one dominating (city) center in the square, the institutional, economical etc. center of the land area represented by the square. there might be smaller cities around the major one or several equal ones, but there has to be one to carry the title.

When switching tot polygons and coördinates the display problems will only slightly be eased or the player will be limited to play at a very close zoom in order to discern the separate cities. Imagine Flanders or Northern Italy in 1500 for example. So it will probably be necessary to impose a(n arbitrary) mininum distance between cities, just like squares (and the possibilities for cities are very clear with squares).

Furthermore it might be easier just to indicate how much (%) of a square's population, industry, infrastructure is city area, instead of separating the city of the rest of the square: this makes it unnecessary (in the case of industrialization) to transfer population and production capacity from the countryside to the city internally, on the same square.

[LDiCesare]

In military terms, having different "squares" for city and country is very interesting, as sieges will be straightforward to code (once I know how I am supposed to code them).
In terms of population migration, it is also easier, because migration goes from square to square. thus a %age would be an additional variable worth 0 for most squares, and cause programming headaches as you would have to know when people migrate to a new square if they want to go to the country or the city. And ifs in code should be avoided when possible, IMO. (Here is an interesting question: can we make a programming language without ifs and conditionals? probably not but still...)

[Gary Thomas]

Multiple cities close together are difficult, primarily for display reasons.

There is absolutely no plan to have multiple cities in the forseeable future. I merely observed that the system I had in mind allowed them.

Since that post I have had second thoughts about the mechanism I suggested. Not about separating cities from their surrounding countryside, but about having them at a lower level in the hierarchy. I have not reached any definite conclusion, but there is a problem if the city is controlled by a different civilization from the one that controls the square. The control hierarchy is a tree. We would have a situation in which the leaf of the tree is not controlled by the same entity that controls the next level up. Not insoluble, but it requires some thought to ensure that anomalies do not occur.

Another approach which has some advantages and some diasadvantages is to put the cities on the same level as the square. This would still allow seiges, and would, cleanly, allow the square and city to have different control. However there are problems relating to display.

you would have to know when people migrate to a new square if they want to go to the country or the city

Under the existing system they go to an empty square, only, so there is no city for them to go to. I would not envisage changing that.

Cheers

[Mark_Everson]

Hi Simon, good to "see" you again!

Originally posted by Gary Thomas
Another approach which has some advantages and some diasadvantages is to put the cities on the same level as the square. This would still allow seiges, and would, cleanly, allow the square and city to have different control. However there are problems relating to display.

I put my vote behind this one. Its what I meant by my "waiting for polygons for detailed city handling" comment. I think this approach makes everything fairly straighforward, and I don't think the display issues will be difficult to solve either. We may, as has been noted, need some arbitrary rules to keep cities at some distance from each other.

[Gary Thomas]

We may, as has been noted, need some arbitrary rules to keep cities at some distance from each other.

If we allow only one city per square there is no problem.

However, the more I think about it, the more I like the idea of more than one city per square. The place to display the multiple cities (and I would not expect more two, or at most three) would be in the detail frame which will handle this rather nicely, including indicating who controls what. On the other hand, I do not give it a very high priority in the code writing scheme of things.

Cheers

[Richard Bruns]

I like the idea of multiple cities per square. I also hope for larger polygonal provinces, and this new city code will aid that scheme nicely. However this may be another area where the core code has advanced beyond the limitations of the GUI.

[Simon Loverix]

If a city is a center, how do we treat an area (polygon or square) with multiple centers?

[Gary Thomas]

If a city is a center, how do we treat an area (polygon or square) with multiple centers?

What do you mean by "treat"? We could maybe buy them a beer...

Cheers

[LDiCesare]

I think "treat" is "traiter", thus "manage" or "handle". Maybe we should use French to communicate in order to avoid those translation problems.