[MAP] Multi-maps suggestion idea.

[Somebody613]

Since this topic is still coming up on and off all the time, here's what I came up as a THEORETICAL suggestion for it (may or may not sound stupid, sorry).
So, the major downside of making it a "real time switch between mono-maps" is MEMORY limitations.
And that means you should AVOID loading more than one map at a time, no question there.
So, I thought, how do we SYNCHRONIZE multiple maps without loading all of them at the same time?
Well - with Map Scripting (or is it Python, whatever)!
Given how WorldBuilder SAVE files ("scenarios") are literally *text* files (and thus are super easy to EDIT) - all we need, is a way to automatically SAVE your End Turn maps separately as "scenarios" and then LOAD them whenever you "move" to them.
Sure, game pacing would be QUITE SLOW (with big maps) - but this is unavoidable already due to the game's AGE itself (and hence limited MEMORY size used).
Basically, all you need is a rather simple (lol) Automatic Save Editor that would trace your map's changes in turn-real-time and keep your "planet map saves" up to date (pun intended).
And then you need to automate Load Game for those planets (because doing it manually would SUCK) - and voila, you have literal Multi-Maps that you can play on each in any order and do there the same things you can do on Earth (which would simply be ONE OF THEM to begin with).
Oh, and a Move To Planet MENU, of course, being accessible both from the Planet View (aka "normal game screen") or the Galaxy Overview (kinda sub-Main Menu of the current player).
For fun, you could even implement two Timeline Modes: Simultaneous (synchronized moves) and Separate.
The latter simply means playing on several planets as separate games - not exactly Multi-Maps, but more like just Space Maps.
The former, though, would be an actual Multi-Map and require an additional Python (or whatever) to synchronize the DATES between several SAVES (as in, not letting you proceed on any planet until you End Turn on ALL of them, loool; this should be reflected in the Galaxy Overview Advisor as well, since it'd suck to load a dozen of your planet maps merely in order to hunt the unfinished one).
Yes, it sounds ambitious as Quack - but I believe in your skills, TEAM C2C!
Any comments are welcome, lol.

EDIT:
Just realized that you'd still need to SAVE normally as well due to in-city stuff and so on, which isn't as easy to edit.
But I guess this simply means you'd need to Automate Save and Load anyways, thus the major invention should be an Automatic Turn Saver/Loader, so to speak.
In fact, if you go for separate-planets-as-saves, ALL you'd need is basically an automatic (and synchronizing) mechanism of Saving/Loading normal save files.
Just put all Current Galaxy saves into their own separate save folder to avoid any mix-up - and make each planet's End Turn state visible in the Galaxy Overview Advisor (accessible from ANYWHERE, be it On-Planet view or Current Galaxy view).
Sounds really much easier than achieving simultaneous map loading - even if this WILL SLOW DOWN the game play immensely (but like I said, this is unavoidable anyways).
Pheeew, lol.
So, any comments?

MORE EDIT:
And as of Space Travel, under this system it becomes quite easy.
All you need is to remove "spaceships" from where they "take off", and then place ("land") them on "another planet SCENARIO (here is where their *text* structure comes in super handy for removing and placing units easily)".
A much harder task would be to implement "space travel time skip", but you could just avoid it by inventing "traveling inactivity" to apply on ships (either "while taking off" on start, or "while landing" on finish, or even split that in two; OR add a "traveling in space" MICRO-map that would have a "space" plot that would "host" the "flying" spaceships for a given number of turns before putting them to their destination planet map's Space Port, not dissimilar to how your Heroes-to-Generals get "revived" while being "inactive" for a number of turns, but make it off-main-game-screen for a more realistic effect).
And yes, it DOES sound a bit COMPLEX, sorry.

Hint:
Yup, I *love* Spore, loool!

 

[MattCA]

So a map switch would take about as long as saving + loading a game. With over a dozen mapcategories already made are players gonna want do a dozen save + loads per turn?
Same thing with the regular map switch which will take 1/10th of that time, still lots of wait time if there's gonna be that many maps.

 

[Thunderbrd]

Pretty sure @billw2015 has been planning some better ways to go about this. I've seen some interesting comments on Discord. I won't try to explain it myself.

 

[Somebody613]

Pretty sure @billw2015 has been planning some better ways to go about this. I've seen some interesting comments on Discord. I won't try to explain it myself.

No doubt there.
I did say it was a stupid idea overall, just a solution to not having ANY Multi-Maps *now*, lol.
Could still be a ModMod, ya know.

 

[billw2015]

Yeah this is basically my current best theory of how to achieve it without having significant limitations on the number of maps you could have. Technically multimaps isn't any problem with the current memory limitations if you constrain the size and number of maps. You could split the current uber space map into a separate map for each planet, but the same size they are now, and your memory usage will go *down* (same reason viewports works well to save memory). The problem I assume we want to solve is essentially unlimited maps, each potentially the size of our largest current single maps.

This *will* require a radical approach, somewhat like what you suggest:

Basically we do what many desktop applications do these days and go multi-process. E.g. the browser you are reading this in probably does this, each tab you have open is bring processed by a different, er, process, but they are all rendered into the same window. Browsers do this for stability and security, "sandboxing" all script processing into a separate exe so any bugs or malicious code cannot effect your browser or other tabs.

In our case we add a new exe (like your save game auto editor) that is our simulation engine. This is spawned by our dll, and can communicate with it via some mechanism (interprocess communication, there are various methods). One major benefit of making a new exe is we can switch to a brand new compiler *and* 64 bit memory model. It isn't magic though, we are still limited to the amount of memory you have on your PC (+paging). However these maps will all be "off screen", with their memory usage entirely within our control.

When we want to see another map we will basically be saving out the current map and all units and then loading the other one, but without going to a file. Instead it could start by using the game save systems, and then later we can perhaps optimize for this purpose if that proves too slow.

/edit just on your comment:
"just a solution to not having ANY Multi-Maps *now*"
What you are suggesting is a massive amount of work: the "auto save editor" is very complicated. I simplified above, but actually it isn't just load and save the maps, you also need to be synchronizing a lot of state all the time, like diplo, what resources you have, war states, unit counts, everything. In both your suggestion and mine there is a LOT of work even to implement it in the simplest way possible while still being functional. This isn't even considering MP, which is a whole extra level of difficulty, especially if you want simultaneous turns.

 

[Somebody613]

...

Thanks for your reply.
Yeah, I said it isn't a valid solution (or it would have been DONE long ago, since I'm a total noob at programming, so lots of better programmers would have solved it better).
But at least it's *A* way to *HAVE* multi-maps - even if crude, limited, and underdeveloped.
Or, at least, we could use a similar approach like in some RPGs (I think Warcraft 3 or something):
That is, we CAN synchronize the amount and quality of UNITS between "planets" - for sure, and merely by using the WorldBuilder Saves alone.
Those DO keep track of UNITS *and* their promotions, and probably could do even more simply on-map.
So, while we now (probably) CAN'T synchronize stuff like diplomacy (or anything, sadly) - we CAN successfully "launch spaceships" onto other planet SAVES.
And there's also one important point that I as a *noob* find useful: Promotions and Placeholder Units.
Basically, we can equip our spaceship in ANY way we want with specifically edited "promotions", and let it "carry" units that can then literally turn into *buildings* via scripts.
This way we CAN launch a spaceship that would be quite unique (via promotions and baggage units) based on what we invented and built on Earth.
The only REAL problem would be to synchronize that unit's INFO between the map saves (so you "land" what you "launched") - but that's *text*-based in the first place.
So we CAN already have *A* multi-maps "modmod" at the very least.
But, sure, it would eat up a huge amount of MODDER TIME - and thus would have to be weighed against other projects.
Anyways, if SOMEONE actually "wasted" some of their time and make a "demo" of this - I bet we'd find a ton of TESTERS for it, loool.
Sorry for being so excited about something so taxing, though.

Here's an example of what I mean:
You build a Unit_Spaceship on Earth.
You equip it with Promotion_Engine_3, Unit_Space_Colony_2, and Unit_Space_Tools_Drill.
You then choose the Launch_Spaceship action for that unit (still on Earth).
The script then opens a menu of Available_Planets, and you choose Planet_Moon.
The script then erases that Unit_Spaceship from the Earth map, and copies all of the above data into WBSave_Moon, adding:
Unit_Spaceship (Owner: YOU; Promotion=Promotion_Engine_3)
Unit_Space_Colony_2 (Owner: YOU)
Unit_Space_Tools_Drill (Owner: YOU)
...to the PLOT that has Moon_Base_City (Owner: YOU) on it.
All of that is *text* based and easily searchable with a rather simple script, or at least it looks that way.
And during your next "Moon turn", Unit_Space_Colony_2 acts like a normal Colonist and creates Space_Colony_City (alternatively: Space_Colony_Improvement, it depends on the game style).
Then Unit_Space_Tools_Drill acts like a Worker and creates Moon_Shaft_Improvement.
Oh, and Promotion_Engine_3 means that your spaceship "flies" (aka stays inactive somewhere) for a fixed amount of time (say, twice less then under Promotion_Engine_1).
While the Colony_2 level means you'll get a free Space_Worker when building it.
Here you go - you just launched a Spaceship that was equipped with a Colonist and a Shaft-Builder.
Cool!

 

[Yudishtira]

We already have offworld Settlers, and an upgrade line of 'spaceships' (transports), as well as military 'ships' and offworld infantry etc.

I like your promo idea. Promos on both the settlers and the transports probably would work better than outright upgraded units.

 

[Somebody613]

We already have offworld Settlers, and an upgrade line of 'spaceships' (transports), as well as military 'ships' and offworld infantry etc.

I like your promo idea. Promos on both the settlers and the transports probably would work better than outright upgraded units.

My idea is more about the mechanics of "space travel multi-maps", though.
It's not the unit, it's the "teleportation" that is the focus.
Do you have any other concrete viable ideas on how to "space travel" between maps?

 

[Thunderbrd]

My idea is more about the mechanics of "space travel multi-maps", though.
It's not the unit, it's the "teleportation" that is the focus.
Do you have any other concrete viable ideas on how to "space travel" between maps?

We will create missions that some units can use to transition from one map to another and will define how you target where you arrive or if you get to at all and it's either random or by specific preset parameters as a part of that mission. We'll need to consider if this would mean potentially arriving to an attack and I'm not sure how we're going to make this work if the other map will need to be a save/load procedure because its while you have your unit selected that you'll need to be able to define where it will arrive on the other map in some cases. Perhaps it can be placed on a list of items to address as soon as you load that map? Such are later considerations than how we're going to store and access these things in memory. Further, how we will access map scripting for defining them when they are needed.