24-08-2002 02:52									#1
	Plans for D8 Support Apolyton, buy Galactic Civilizations

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

	24-08-2002 03:03									#2
	Support Apolyton buy from Amazon

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

	24-08-2002 03:51									#3
	Support Apolyton, buy Galactic Civilizations

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?

	24-08-2002 05:54									#4
	Remove this text

quote: Originally posted by LDiCesare Why do I foresee unforeseen complications?

LOL! Why should this be different from any other changes

quote: 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.

	24-08-2002 13:35									#5
	Help yourself to an AD-FREE life

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

Probably in that order.

	25-08-2002 03:42									#6
	Got spare money?

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

quote: Why do I foresee unforeseen complications?

Deeply ingrained pessimism?

quote: 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.

quote: How will you raze cities?

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

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

See above, and Mark's comments.

quote: 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

	27-08-2002 15:02									#7
	Inflate your Upload Space

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.

	27-08-2002 20:37									#8
	Full PM-box? Change here!

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...)

	28-08-2002 03:20									#9
	Support Apolyton buy from Amazon

quote: 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.

quote: 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

	28-08-2002 06:39									#10
	Full PM-box? Change here!

Hi Simon, good to "see" you again!

quote: 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.

	29-08-2002 02:51									#11
	Enter the AD-FREE zone

quote: 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

	29-08-2002 11:35									#12
	Support Apolyton or Terrorists Win

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.

	02-09-2002 15:54									#13
	Support Apolyton, buy Civilization III: Complete

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

	03-09-2002 07:52									#14
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

quote: 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

	03-09-2002 11:15									#15
	Support Apolyton buy from Amazon

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

	04-09-2002 04:33									#16
	Increase Your PM Length

Certainement! Mais alors vous devez traiter mon francais de college!

A votre sante.

	09-09-2002 17:45									#17
	Lose 30 kilos (of popups)

Bizarre. ça me parait egalement la même chose, dans ce contexte.

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

	20-09-2002 06:37									#18
	Suffering from ads?

Only one city (if any) would be the provincial capital. The only other functions of cities are to have markets. There's no problem having multiple markets in the same square/polygon. So I guess my question is what issue were you thinking of being a problem Simon?

	20-09-2002 11:20									#19
	Increase the size of your Attachments

quote: Originally posted by Mark_Everson Only one city (if any) would be the provincial capital. The only other functions of cities are to have markets. There's no problem having multiple markets in the same square/polygon. So I guess my question is what issue were you thinking of being a problem Simon?

What about multiple national capitals?...obviosuly that's mute if there is only one province....

	25-09-2002 00:36									#20
	Remove this text

Well, if those cities behave the same why are there several ones? If they don't behave the same there could be problems when some cities join a rebellion and others do not. Or when one city is conquered and another one is not, how much of the territory belongs to which city? When there are different ethnicities or religions, how are they divided between the cities? How many cities in one square? Are suburbs cities? When several cities grow together, what is the name and position?
If we stick to squares, it would be more coherent to assume there is one capital, assuming all other urban areas of that square are included under that title. Cities would not need to be kept track of separately from the rest of the square, so industrialisation FE could be more fluent: it doesn't matter where the production increase happens, in town or not. That would be simpler.
Using polygons, the exact position of the cities can play a role, but there is a cost in calculations and complication.

It could even be interesting implementing things such as Jewish gettos and Greek trade enclaves, but I don't think it is good to implement much sub-square issues, since we're avoiding micromanagement.

	25-09-2002 17:10									#21
	Support Apolyton, buy Call to Power 2

Hi Simon:

quote: Originally posted by Simon Loverix Well, if those cities behave the same why are there several ones?

I don't think close-together cities would be very important in a whole-history game that a player starts from scratch. Its more in my mind just a capability for scenarios. If in FE Italy there were many squares with more than one noteable city. If I were the scenario designer I'd probably skip them, but for some its important to have everything as correct as possible. In short I don't view this as something of major importance for the game, but just a nice detail feature. For that reason I'm not really into discussing it in great depth.

quote: If they don't behave the same there could be problems when some cities join a rebellion and others do not.

Why would this be a problem? Cities would be like squares, with their own population, land etc. If one square rebels and another doesn't there's no big issue IMO.

All your other points seem to be non-issues also if we use polygons with dedicated land for any city. City land could then grow according to some TBD algorithm. Cities could merge if conditions were right, and the name could just become a hyphenated concatenation of the two names.

Whether all this is worth it, I'm with you that I'm not sure it is. But most of the people commenting here seem to think it is. If it turns out its more trouble than its worth, we can always ignore it. But IMO its simpler in terms of bookeeping and algorithms to treat a city and hinterland separately than have complicated algorithms to determine on the fly who is in the city and who isn't. YMMV.

	25-09-2002 21:46									#22
	Support Apolyton

Several cities in a square are worth having. Often, countriside has been controlled by one force while cities remained in control of the defender. Such "sieges" could last several years (Catharres for instance). Thus having several cities in a square which are controlled differently would be OK for me. If the only problem foreseen is complexity and potential slowness, don't worry. It is not more complex to have several cities instead of one, and complexity will be incurred only if such multiple cities happen, which is not clear right now as we don't know how cities are formed. They are currently designed by the scenario, and the scenario make can put them and test performance, and skip them if he wants to.

	01-10-2002 14:47									#23
	Suffering from ads?

I'm not against the principle of several cities, but only a little worried that it is almost asking for micromanagement. But we agree that we could omit it when the complexity outweighs the benefits.

	08-10-2002 03:21									#24
	Got spare money?

quote: Originally posted by Simon Loverix It could even be interesting implementing things such as Jewish gettos and Greek trade enclaves, but I don't think it is good to implement much sub-square issues, since we're avoiding micromanagement.

Micromanagement isnt synonymous with detail. Just because you have all this extra info deosnt mean you need to manage it directly.

	08-10-2002 15:00									#25
	Browse Apolyton AD-FREE

Agreed, but if such things are hidden in a detail pane and managed automatically, most of the players will never know it's there. Adding details that do not require fundamental changes in the way the game works later is rather easy, as opposed to pruning the excess fancy stuff without function.