Forums

One could consider a system where capture points and garrison capacity scale with population. That said, it would likely introduce additional complexity. Even if feasible, it might be preferable to tune fixed values around reasonably standardized scenarios.   That could work, although there are additional variables to consider. Capture time will always depend on the size and composition of the army. Are we talking about basic or elite units? Melee or ranged? Are heroes involved?   Yes, that seems like a relatively simple solution to implement. As for collisions, they already exist. As shown in the video, when no formation is active, many units are unable to capture and instead try to find alternative paths. I think a certain degree of overlapping is actually beneficial for battles (though not for capturing), otherwise unit behavior can become somewhat clunky. It’s probably a matter of fine-tuning the parameters under specific circumstances.

"Another potential solution" is the opening of my text, and it’s perfectly clear to any English speaker that it’s meant as an additional idea. It doesn’t replace anything, it literally says “another.” It could have been “instead,” but it isn’t. You seem to enjoy these little internet arguments, don’t you? lol The Roman Army Camp can hold 20 units. Strangely enough, when you destroy it, an additional capacity of 30 units appears. 

Exactly. "Isn’t 20 soldiers too few for a fortress?" is not the correct approach, but "which percentage of your max population is 20 soldiers"? Then it's not a small garrison. Just increasing it doesn’t seem right. What is worse, if one increases the pop cap, leaving the garrison caps fixed, all considerations of what is big or small are out the window… unless collisions are used. This always fixes the max amount of units trying to take a building. It also helps in fixing capture points, after a decision is taken on how little time capture should take (it cannot be that it’s not known if 5 seconds will become maybe 5.5 or 6 seconds, things should be calculated the other way around, first deciding an acceptable minimum capture time, and working backwards). And it applies for buildings that don’t have any of the mentioned Fortress or Tower defensive techs. If there’s a formation exploit, then I guess better if that’s solved, instead of collisions removed. If I understand correctly what’s happening from the videos, couldn't formations be temporarily disabled when units are taking on any of those tasks? Whatever needed since collisions does seem a step in the right direction. Collisions seem necessary, but maybe not sufficient, thus: I agree with 1. because of the regeneration problem pointed out, but disagree on how to exactly implement 2. because it doesn't seem very common that a given tech does more than one thing. On the other hand, someone said recently "the two techs for towers for greater range and more default arrows" "are also too expensive to be viable during the period of the game when towers matter", so I'd remove the Arrow Shooters tech and give that range increase to the Stone Tower for free, because, if I understand correctly, with no techs both it and the Sentry Tower have the same range (10 to 60 m, even when it’s taller). If Sentry and Professional Garrisons are not interesting enough, I’d make them do more of what they already do. Regarding increasing capture points +50% to Towers and +100% to Fortresses, I’d either give this for free, or have a mutual tech that gives +50% to both towers and forts, and from the start give forts for free whatever is needed to complete the +100% wanted.

You should usually have to raze a fortress to the ground, rather than capture it. While that may not be historically accurate, it makes sense given the style of RTS, rather than something like Total War.

If I recall correctly, Roman Army Camp used to be able to hold 40 soldiers. Granted, when the collision issue (or just the formations exploit) is fixed, a full Fortress will be almost impossible to capture at full health, which might be a good thing lol.