First, migrant is not a completely natural unit. When you play any Civ, you are a ruler, but by default, rulers have limited power over their nations, with this limit depending on the government. My first idea was to completely forbid building Migrants under Republic and Democracy because there the "rulers" don't have the power to move population from one place to another by decree. Unfortunately, I didn't find a way to do it within the ruleset.

Also, spontaneous migration is available as a server setting. It is mostly beyond control of the ruler, but it can be attemped to direct it... indirectly, by making some cities better to live by building improvements. In theory, people will move there from cities with less prospects. And it basically works.

At the same time, Migrants pose a huge potential for something I see as a massive abuse of game mechanics: build a city at a militarily strategic location and stuff it with migrants for a fat, fat defence bonus: with walls, a unit entering city increases its defence bonus at least four times if city is built on plains. Also, pumping a city moves borders so you conquer territory without military units and then move in military units that now have a home turf advantage where other nation lived possibly from the beginning.

Effectively, a big empire can keep dozens of migrants in reserve and sprout several size-8 (or whatever is the limit) cities in one turn.

And I think that the civilian, nation-building, social aspect of the game should be something entirely separate from military strategy (unless the society itself is spartan, but this isn't supported by game mechanics). I guess it depends whether you are seeing Civ as a strategy game or a historical simulation. If you separate yourself from the latter and embrace the former, you may as well make a Hobbit unit that digs tunnels underneath enemy defences and... you end up with an overgrown game of checkers where the goal is not to combine different levels and layers of decision making and grow as big as possible, effectively competing with others AND with yourself, but instead, only to defeat the enemy, ending with a binary win-lose result. (Digression: this is why I'm so much against restrictinfra off; with it "on", you have to win many battles to successfuly annihilate the enemy; if you win only some, your end result and reward are proportional to your success. With "off", you basically need to win only one, game over.)

Anyway, to get back to the issue of migrants, the unit shouldn't be completely cancelled because of the way city behaviour and growth work: in reality, a growing city swallows neighbouring settlements and incorporates them. In Civ, neighbouring settlements are only a nuisance and are best removed so that the city can use their tiles more effectively. So, with that, the only sane thing to do is disband the settlement and add it to a city. This effectively happens in reality, only by more administrative means and not by removing people and houses physically. So, a Migrant helps with translating reality into language of the existing game rules.

Basically, city mechanics are completely and absolutely unrealistic in Civ because that is not how things work in reality. However, this mechanics represents the core of the game and changing it would require, basically, creating another game. (While I'm all for it, it would require heavy work by someone else, and then there is also other people who may simply decide they are not interested in playing it because what we have here is simple, understandable, at the same time has a certain level of complexity and it works. We could make another - better - game, but it's questionable who is going to play it.)

So, in effect, what is mechanically required is:- more spontaneous migration that you can "direct indirectly", but never control completely (done by a single server setting)- a minimum of "Migration by Decree" (to compensate for the imperfection of city development mechanics)- this "MbD" remaining at a minimum due to abuse

And making Migrants a unique unit does exactly that: you can still deliberately migrate one unit of population per turn (disbanding one size-1 city), but can't use it as a logistical swarm for military goals.

As far as I'm concerned, these are the final changes made. The ruleset can now be downloaded and tested. I'm sure there will be glitches so feel free to test it extensively.

So:- no empire size limit by cities- one unit per turn upgraded by default; Leonardo upgrades 2 more- NATIONALITY: ON; when you conquer a city, 51% of its population will be unhappy if belonging to the enemy nationality- when your palace is conquered, you don't get another one autiomatically, you need to build it yourself- no civil war- Migrants are a unique unit; also "FieldUnit": cause unhappiness in a city where built (removed additional migrant units from previous version)

This is the ruleset that LongTurn 42 will be played with. Starting in roughly a month. Multiplayer test games to be started soon. More info and the official communication channel here. If you wish to join, register here and don't forget to confirm. Discord chat channel here.

My idea about city radius growth: some buildings should be used as limiter of city radius growth, instead of additional bonus for city radius growth.Large city radius lead to high production and high population, which equal to high pollution.Buildings such Mass Transit or Recycling Center should be required for radius (not size, as aq. or sewage) above 9 and 16, respectively (only effect caused by city size, other buildings can still give additional radius independently).

Mass Transit makes sense. It should enable people to move further from the centre of the town. Or increase efficiency / decrease waste (as in "production waste", because people need less time to travel and can use more time to work) once it's built.

However, I don't see why Recyc should do that. There is no way it really limits city growth in reality.

All that said, I'm not sure if it's possible to actually put a limit to city radius in a ruleset. Does anyone know if it's possible?

Category page on radii http://freeciv.wikia.com/wiki/Radius defines the limit _sq to be 26 (5,1). I presume this was also the limit in the GTK 2.0 GUI so all this could change at the drop of a hat. (Is this what you are referring to?)

Edit: on second thoughts the city radius is just an effect so it is entirely up to the ruleset to specify what it wants (within the max mentioned above).

nef wrote:Category page on radii http://freeciv.wikia.com/wiki/Radius defines the limit _sq to be 26 (5,1). I presume this was also the limit in the GTK 2.0 GUI so all this could change at the drop of a hat. (Is this what you are referring to?)

Edit: on second thoughts the city radius is just an effect so it is entirely up to the ruleset to specify what it wants (within the max mentioned above).

Yes, but the only effect managing city radius I could find is City_Radius_Sq which is purely additive: putting a value results in adding that value to whatever else is existing. I don't see a way to limit the radius using only this.

Corbeau wrote:Yes, but the only effect managing city radius I could find is City_Radius_Sq which is purely additive: putting a value results in adding that value to whatever else is existing. I don't see a way to limit the radius using only this.

nreqs (or replacements) is the usual way of defining specific values, that is you specify reqs for value #1, then specify new_reqs for value#2, together with the nreqs for value #1. Can be tedious, but effective.

So for example increase size for building A; increase again for building B, but if you now have building C you want to limit the final value to something less than A+B you have rules with reqs predicates for C, (i) nreqs for A, nreqs for B (ii) reqs for A , nreqs B, (iii) nreqs A, reqs B, (vi) reqs A, reqs B. In this simple example you would have nreqs for C for the rules for plain A, plain B. In practice the rules would be much simpler - one could even use negative values and avoid nreqs altogether.