It does but maps, units, cities and other things still use some memory even if they aren't displayed. You can see that with Graphic Paging or Viewports already both reduce the memory usage by hiding parts of the map from the graphics engine. But big maps with lots of stuff on them still use lots of memory.
Right... you still have CvPlot having a lot more to remember and store. I get it. But it could be possible to make a save and load sequence for CvPlot whenever the map switches, for some select information, so that even some of the underlying stuff can be a bit more streamlined. Things like the visibility memory and there are many others that can be stashed away when not in use. It WILL add time to the transfer between maps but I strongly feel that those among us who want the multimaps as badly as we do are MORE than willing to deal with such a delay. Even a good portion of unit datas for units on the maps we aren't on can be stashed away in a save to at least give us a lot more room to work with at once.
Especially things like plots and units increase the memory usage because there are thousands of them in a game. Units had lots of stuff added and all that stuff takes memory. Also there are much more different kinds of specialized units which are increasing the number of units in the game and that increases the memory usage even more.
It's recognized that units are an issue there. Some of the cost and building rebalancing projects that are currently underway are intended to help a lot with that. You've made points about how imbalanced some of that is and you've been right of course. We don't HAVE to structure the game so that there are so many units for each nation as we get right now but it's an incredibly interwoven web of factors that need to be brought under control. Nevertheless, I'm not at all pessimistic about our ability to do that.
I also do recognize that a lot of new unit data is in place here over vanilla and yet more is planned. I also think a lot can be cleaned up and a LOT more room can be made by converting numerous original array storages to vectors.
I have a Computer Science question for you on that, though... I don't have much knowledge about how much ram the game has to reserve to simply initiate and maintain a vector or map. Obviously, an array can store a tremendous amount of information that is unnecessary to store (lots of 0s in the full chart it allocates resources to) but is the mere initiation of a vector or map all that costly? Another question along similar lines, is it possible to avoid declaring some information storage systems for units of types you know are never going to use it? AKA, in CvUnit.h, for example, when you declare an integer, I realize that alone allocates an integer variable storage and whatever integer is defined there is held there, whether necessary or not. So can I safely avoid the declaration if the CvUnitInfo shows a particular bool being true for example? I realize I'd also have to equally control the establishment of a base default, clearing of the value on removal, and in the save/load wrapper sequences, but theoretically, this could work to buy us a lot more room in some cases, wouldn't you say?
Then how about a game option? Are those established early enough that a declaration in CvUnit can be made contingent on the existence of a game option?
Things like the property system take alot of memory as well. Without the property system enabled a big game can save 200MB of memory easily. That's because of the generic way it is programmed if the properties would be simpler and hard coded in the dll like commerces or yields they would use less resources.
You've spoken about there being better ways. I will strongly agree with you that the manner in which the generic programming has been done there is frustrating to work with and I have been wondering about the cost in memory. If we can replicate the property system without having to use the overwhelmingly generic approach, I would be all for that... meaning the math process doesn't change but we make the method work more straightforward and memory efficient then hell yeah, I'm onboard. The way properties work in game is, imo awesome. Especially after my current project completes... I have a lot of optimism about the end result being very satisfying. But yeah, the memory costs of the property system... I've been worried about that because I don't really get any kind of concept of how much memory is being allocated unnecessarily here. Your comment points at an answer I have begun to fear may be the case.
Does the use of % Modifiers instead on integer modifiers also increase memory usage because of the processing a % modifier would seem to need?
No. Processing doesn't increase memory allocation except for throughout the very temporary amount of time that local values are initialized in a function, then when the function is left, local declarations are broken down and are removed from use in the ram. What you have to be concerned about in memory is all the stuff that the game basically has to maintain in memory in long-term... how much it has to juggle at once. The more we can let it forget and later recalculate to come to an answer when it's needed, the less we tax the memory, but the more we tax the processing time. Most solutions for speeding up the game will tax the memory more because it attempts to get the system to remember the last time things were calculated (as long as the factors involved in the calculation have not changed) so it doesn't have to process the calculation again.
It's actually kinda amazing how much memory room we have and how fast things process... It's just that as we begin to press the boundaries, at times we need to take a look at how we can dramatically improve on bad methods used in the past and update them to better ones so that we give ourselves more room where we need it.
I think we can make multi-maps work. I don't think it will be easy. And I think if we jump the gun before we complete other desired mods and streamline our approach to a lot to make room for MM, Alberts is then right that it becomes pretty silly to try it. But I can still see a lot of ways to streamline and give us more room. We are defeated first and foremost by pessimism. When has our project ever NOT been about pressing boundaries and then finding ways to break through them? As I grow in skill and understanding, which happens every day, even in large part due to mistakes I've made, I see more and more how things can be done and less how things can't. Programming is all about finding the best way to skin a cat from a thousand ways to skin one. And almost anything that's been done can be improved on. Given how tolerant the code has been for some sloppy and less optimal approaches that have been used, we have a huge amount of margin to condense by improving methodologies.
