Freeciv

This patch introduces an important change to combat gameplay. Since this ruleset enables the "restrictinfra" rule, units use to need to spend at least 1 turn in the open before being able to attack an enemy city, and it is important the construction of fortresses in enemy territory, or around enemy cities, in order to siege them before the attack. This can also happen in classic freeciv, but I think it is even more important in civ2civ3.

I always found odd the need to send nonmil workers for this task of building forts in enemy territory. For example, when I was trying to make scenarios for WW2 battles, I was always forced to add engineers to the Armor units in order to give them a chance to survive outside cities. I think this role suits better the military infantry.

With this patch, infantry units can be used to secure the position and protect artillery and tanks in the open (or to siege enemy cities) without the need of civil units. It also prevents infantry from becoming obsolete by Mech Inf and Armors, allowing more varied tactics: rush attack with tanks without support of infantry, or slow advance with infantry building fortifications before the arrival of the wheeled units.

This change have been in my "earth" version of the ruleset for years, and I like it, but I'm not sure if it is still ok to introduce such changes for 3.0, or better to leave it for 3.1. I uploaded both patches just in case.

Hm, really a considerable gameplay change. What have you seen, AI uses it? I doubt that currently it does. Among original CivIII military units, only Crusaders could build fortresses. Maybe we could leave this ability to them in this ruleset and include it for all infantry in another one (e.g. why not to ship "earth" with the distro?). Actually, soldiers have limited ability to build fortification (past Roman castors warfare level) and it is modelled by "Fortify" command.

Reply To (Anonymous)

Hm, really a considerable gameplay change. What have you seen, AI uses it? I doubt that currently it does. Among original CivIII military units, only Crusaders could build fortresses. Maybe we could leave this ability to them in this ruleset and include it for all infantry in another one (e.g. why not to ship "earth" with the distro?). Actually, soldiers have limited ability to build fortification (past Roman castors warfare level) and it is modelled by "Fortify" command.

Good points, and they bring up topics I've wanted to discuss for long time...

AI doesn't use it, but neither they use workers to build fortresses, so there is not a big difference for them here. I'm always reluctant to introduce in this ruleset features that AI doesn't know how to use, like bombarding. My reasoning here would be similar to that case: since AI doesn't build fuelled air units, it is not a big difference if those air bombers use the new bombard feature that AI doesn't use either. I see your point though, that this patch actually makes AI a bit weaker because now it easier for humans to build fortresses. But building fortresses is a feature already present in civ2 and classic freeciv, so I guess at some point AI might learn to use them, and it might be easier with this patch.

It is an important change, but I think not that deep: when you want to build a fortress in enemy territory, instead of sending an engineer, protected by a mech inf, you can send 2 infantry units (as paratroopers, marines in helicopters, or alpine troops) to build it in the same time, keeping all those units and different tactics alive for the whole game. Since engineers are cheaper than infantry, and can build fortresses faster, they are still a good alternative.

Combat in civ3 was much different, and even when I try to make the gameplay of these rules a bit more similar to civ3, there are too many missing features from civ3 that makes it impossible to use its unit stats as reference. Since civ2civ3 uses civ2 tech tree, civ2 combat mechanics, and civ2 unit stats, I think it is better to use civ2 as reference in this case. However, I also like to mirror civ3 stats when possible, and I like the idea to give the ability to build fortresses to Crusaders (in addition to infantry), even when the icon in freeciv represent them as cavalry, and was not included in this patch. It is also debatable if cavalry should be able to build fortresses too, but this rule tries to stress the importance of using infantry to protect cavalry and tanks in the open, and right now, an infantry unit in the same tile as a cavalry is not a good protection, nor a good idea, unless there is a fortress in the tile.

About realism, I always try the resultant gameplay, not the way it is implemented, to feel realistic. Also, in most wargames, military units are supposed to include already the engineers, mechanics, medics, cooks, etc, needed to keep the unit operative.

I agree that fortify action might be a good representation of the defensive fortifications that infantry can do. But in game, fortify is not enough to keep units save in enemy territory, they actually need fortresses. Since fortresses can be done in one turn, in the middle of enemy territory, or even adjacent to enemy unit stacks, I don't see them as castles or bunkers, but as an enhanced fortify: temporary military bases, mobile battle camps, trenches, and similar fortifications that military units have historically used and still does. They are implemented as fortresses, but in game they act as a 3 level fortify action that goes from x1.5 defense the 1st turn, x2.25 the 2nd turn, up to x3 the 3th turn. If fortify action is unhardcoded in the future, I'd be interested to use it instead of the fortresses, but right now I'm trying to introduce changes that I have tested up to v3.0.

In the future, I'd also like to add the Castle (already in sandbox), as an upgrade to the Fortress that can only be built in domestic land, by settler/worker units (like airbases with this patch), that claims the ownership of the tile where it is placed (preventing it from being stolen by enemy city borders), and with nokillstack. This one would represent castles/bunkers that military units can't built, but neither can civil units in enemy territory.

Sorry the long reply, I hope it does not discourage you or other people to keep posting critics to my patches. I like to read them, and I take them into account. I actually do not plan to push this patch unless you (or anyone else that is reluctant) agree it is ok.

Reply To (Anonymous)

(e.g. why not to ship "earth" with the distro?).

I don't really like the idea to include "earth" with the distro, I think it is enough that there are 2 rulesets (civ2civ3 and sandbox) already based on my version of the rules. Also, I don't really enjoy the development of a ruleset once it is included in the distro, for several reasons, but there is one that I'd like to comment here: my development of the ruleset is always delayed compared to the development of freeciv because I need to test the new rules in a proper game against an stable AI before being able to start making patches. AI uses to be unplayable in the beta stages (completely understandable), and I use to need to wait until the first open release before I can play a reasonable test game. When I finally feel ready to introduce changes to v3.0, the development of freeciv has moved to 3.2, and I need to make the patches formatted for v3.2, even when I have never tested it. The sad part is that those changes that I fine tuned and balanced for 3.0, will not be available for players until v3.2, where AI will be different and I never tested it. Once I finally test 3.2 and fine tune the rules for it, I will have to make the patches for v3.4, and so on... It has happened the same to me since civ2civ3 was introduced in v2.5, and there is no way I can catch up, because I need to play at least a whole game with the new rules to be sure they are working or reasonably balanced, and the hard work to make the patches just starts there.

This development cycle might work for client and server features (that you can test without the need to play a whole game), but when it comes to rulesets, I think it is much better if they are developed apart. Unless you want a frozen ruleset that hardly change over time and does not introduce new features.