Its not the stack size itself, its the total volume of units. Fewer units = less processing resources, fewer crashes and faster turn times which will lead to an easier playing of later eras as well.
I was using 'attack' size as simply an example. IMO there is no significant gain of building 50/100 unit stacks that you cant get from a 15 or 20 size stack.
It would also mean fewer city defenders just sitting in cities doing nothing but eating processing resources.
If thjs approach is taken then other factors would need to be tweeked. For example fewer uu per culture, more city defense % dmamged per siege, more effect per police and disease units/promos.
In short I'd rather see 25 units as a massive death stack than 100.
A few points to consider:
1) City Defenders take up very little processing as most of them simply take their seat in the city and pass pass pass. There's some, yes, but not much.
2) I get what you mean about memory usage being eaten up by a lot of units. Alberts2 and I have a lot of work to do to streamline unit data usage (while making room to add more for other projects) and make it possible to cycle around so that old and dead unit IDs get reused. That's a major project that sucks because nobody will really feel like anything is getting done because it won't appear to achieve anything (unless you would've otherwise hit a MAF.)
3) Size Matters does a pretty good job now of condensing units both for the player and for the AI but it does NOT do it in a memory saving fashion - though it DOES help for so many units processing their decisions. I will be doing some things to get it to at least be no worse than the standard game as far as mem costs and it has been improved this version.
4) The thing about stack sizes and stacks of doom and such is that war really begins at building military, not just when the war is announced. So when 2 nations are preparing for war against each other they're in a race to get not only better but MORE units than the opponent before they feel ready to strike. This is quite historically accurate really. And it's nearly impossible to make the AI SMART without giving them this motivation to try to get a volume edge up on their intended target before launching an invasion. This can end up with a lot more units than you'd think was necessary.
5) The WAY AIs build and measure their stack building needs does need some help because I believe at times it can become fractured and end up planting many seeds for many stacks unintentionally. I've seen some weirdness there that I'd like to try and address by some proposals I've made to UnitAI mechanisms.
6) Limiting stack size can never address this, only hinder the code from playing out the way it's designed and can inhibit the AI from ever feeling like they are ready to do anything warlike or to feel comfortable with their defenses... it can actually make them overbuild because they can never hit their target volume in their stacks, a target determined by measurements of assessed strength of the intended foe.
The unit movement is still too slow even with the changes i made to speed it up, there must be a simpler faster solution.
The healer production code in CvCityAI::AI_chooseHealerUnit is very slow how could that be simplyfied?
I can't see why BuildUps should slow things down at he moment.
1) Unit Movement is something I believe some things can be saved that actually help and don't inhibit the intention of the changes while there are other things that must be placed back to being grossly oversimplified for now. I have some ideas as to alternative ways to go about that for a second try but not to be attempted before v36. This will be my first effort this weekend.
2) I'll look at AI_chooseHealerUnit for ways to simplify. I think the root issue may take an extensive modding effort but could then be used elsewhere for other similar very intelligent AI decision making to be equally streamlined. For quickfixes, you may be able to find better ways to address some things. I just know that caching is dangerous for multi-player so I'm reluctant to use that as the ultimate fix unless it's done very carefully.
3) The main reason I was concerned about buildups is because I made some changes there and noticed a slowdown which I expected but felt it was more severe than I suspected it would be - though I may have fixed that now and what Joe and SO are experiencing is just a matter of getting deeper into the game and beginning to suffer from the above issues that don't make such a big impact until later on.
There is code associated with Sea Tunnels that Is a problem (has bugs) whether you Love them or not. Until that is fixed then Sea Tunnels should be turned Off.
Whether you turn them off as a player or not won't change whether the code causes such an impact. It's a deep fundamental coding change that let a unit evaluate ASPECTS of units it could see rather than just its own abilities or inabilities as to whether it could attack that unit or not that made for such a great slowdown. This was done initially to fix movement rules for tunnels but it causes too much evaluation when units go to move in all movement determinations every round that it creates a major slowdown once you get a lot of units in play. Therefore, I need to return it to the oversimplified rules in the code and then tunnels will return to being flawed again - at this point we should turn them off or let players deal with the buggy interactions.
However, I have another way to solve this in mind that should keep the simplicity while enabling a bit more rule agility - not as much as I'd hoped but a compromise at least. So I suggest not REMOVING tunnels, just urging players not to use them until this is fully addressed.
And as for the healer problem I'm hoping that the changes I want to make to Diseases after v36 release will abate the need for massive amounts of healers early game were that problem starts. Same for TW line and Crime and no I'm not looking for a bunch of new crime fighting units either. But rather a simple reduction of early Disease and crime and moving to later Eras the brunt of both. Right now it's mostly front loaded.
I promise, if we both do what we have in mind, we'll have a truly improved system there. I strongly believe that despite misgivings, once those units are fleshed out it will mean a huge improvement in the game experience.
Also unit upgrade costs are all over the board. But in the game play itself it becomes easier to delete older units and just build new ones. So upgrades become unnecessarily burdensome.
This is one very very big reason to give more granularity to the amount of unit upgrades as technology progresses.
Example: Do you think the AI as well as the player wants to spend 500+
to upgrade from Healer to Apothecary? Especially when the game makes you and the AI to build dozens of healers per city to combat disease by the time you can build Apothecaries. When it's just easier production wise to build several new Apothecaries and delete the old healers. Or keep all the promoted up healers even if it means by late med Era you have 30+ in your cities. And by Ren Era I've seen AI cities with 50+. And the same happens for the TW line too.
Add a step between Healer and Apothecary and it will feel much more reasonable. The problem is the amount of time the game goes here without another upgrade for the Healer.
So does the AI need to be taught that it needs to delete old units to build new? Right now it's taught to keep the old because it has more promotions, that is were the current weight seems to be.
Actually the new will probably have more promotions due to more buildings and such giving XP to newly built units. Civilian units like healers don't have TOO many ways to gain XP so the amount of time they spend in the game doesn't often overcome the improvements to XP granted to units upon being initially trained as time goes on. This is one reason I'd like to develop the Ongoing Training mod in full soon.
As for the AI, I'm not sure how advanced they are with this but I've seen them eliminate older units that aren't useful... there IS code for that. At what point they choose to do this is what's potentially in question. Would take a lot of code research to see what determines these kinds of decisions.
After my test play I can only say that upgrade cost of healing units is screwed. For example upgrading my Sherif to Police Car cost me 2.500 Gold (reasonable
and upgrading Surgeon to WWI Ambulance 12.500 Gold
Again... look at the distance in the X layer between a Sheriff and a Police Car and then the difference between the Surgeon and the WWI Ambulance. (You also missed upgrading the Surgeons to Medics in there.) That's a huge difference in the amount of time between them and that's why there's such a huge difference in the build cost between them and that's what defines the upgrade expense.
I kinda like the idea that at first player could only build one tile tunnels but after a certain tech ( maybe megastructure engineering or such ), he could make them longer. I don't know if game engine allows this but if not, i'm very happy with the current system. Tunnels are also quite expensive to make and easy to break.
With underwater cities, the tunnels could act as a highway system and could maybe be upgraded like roads. Hmmm... not bad.
The streamlined movement rules I intend should help to set us up for Underwater stuff to be better developed in general as well. But it will take 2 steps. One to remove the new developments that make tunnels work properly but cause a HUGE slowdown in turn times later in the game. The second to add a more streamlined mechanism that involves clearly defined Z layers on the map for unit interactions.
