multimaps and other questions

So when do you think sea cities will be ready with sea mines, ect... before multimaps?

First we need the AI to learn how to play with them. I am personally excited too for it as it was one of my favorite features in Call to Power.
 
If the Mapscripts is what's pushing back multimaps I'd be more than happy to make a scenario for it at first. There aren't so many features/ terrains / ressources for moon or martian maps anyway, so I think they all would look quite similar.
There are map scripts for the various terrains but we would need C2C versions. They would have to store their information in the proper z-value as well.

Suggestion:
z=1 is Earth
z=2 is near Earth (Earth, Moon, Lagrange points, Earth Orbit (Low, Geostationary...)
z=3 is Moon
z=4 is Solar System (Sun, Planets, Asteroid belts and special Lagrange points)
z=5 is Mars​

Having the functions of CyMap, CyPlot and CyMapGenerator have room for the z value will be needed.

Bonuses and Features will need to have their base terrains defined. Maps will need their base terrains defined or the base terrains will need the maps they can appear on defined.
 
There are map scripts for the various terrains but we would need C2C versions. They would have to store their information in the proper z-value as well.

Suggestion:
z=1 is Earth
z=2 is near Earth (Earth, Moon, Lagrange points, Earth Orbit (Low, Geostationary...)
z=3 is Moon
z=4 is Solar System (Sun, Planets, Asteroid belts and special Lagrange points)
z=5 is Mars​

Having the functions of CyMap, CyPlot and CyMapGenerator have room for the z value will be needed.

Bonuses and Features will need to have their base terrains defined. Maps will need their base terrains defined or the base terrains will need the maps they can appear on defined.

We won't use a Z value (as such anyway - not like a regular discrete coordinate). Maps have ids like buildings and so on. We just need a way to associate MAP_EARTH with an earth map script, MAP_MOON with a moon one etc. Lytnings XML for maps does most of it, but it needs broadening and tying into the map generation system.
 
I think we may need CyPlot(x,y,z) functionality in the UI but I am not sure I need to find my old plastic templates, a coffee shop and spend a couple of hours turning the code into diagrams. I haven't found an affordable drawing tool that I can install use on one of my not ever connecting to the internet PCs :(

As to Map Scripts yes a map script needs to be associated with MAP_MON or what ever. As do the base terrains but I don't think anything else does. Terrain Features and Resources are linked to base terrain and Improvements are either linked to base terrain or features or resources.
 
There are map scripts for the various terrains but we would need C2C versions. They would have to store their information in the proper z-value as well.

Suggestion:
z=1 is Earth
z=2 is near Earth (Earth, Moon, Lagrange points, Earth Orbit (Low, Geostationary...)
z=3 is Moon
z=4 is Solar System (Sun, Planets, Asteroid belts and special Lagrange points)
z=5 is Mars​

Having the functions of CyMap, CyPlot and CyMapGenerator have room for the z value will be needed.

Bonuses and Features will need to have their base terrains defined. Maps will need their base terrains defined or the base terrains will need the maps they can appear on defined.

Wait so there would be 2 different maps #2 Orbit and #4 Solar System? Or is the Orbital Map on the Z axis of Earth, meaning Z up is Orbital and Z down is Underground/Underwater? Which would mean if you went "UP" you would still be on the same latitude and longitude as where you took off from on the surface of Earth.

So we would have like ...

- Earth (Surface)
- Earth (Underground/Underwater)
- Earth (Orbital)

But then what about on the other terrain maps?

- Moon (Surface)
- Moon (Underground)
- Moon (Orbital)

- Mars (Surface)
- Mars (Underground)
- Mars (Orbital)

- Solar System
- Galactic

That makes 11 maps rather than the 5 proposed maps. Or should we have only Earth get Orbital and Underground maps?
 
I think we may need CyPlot(x,y,z) functionality in the UI but I am not sure I need to find my old plastic templates, a coffee shop and spend a couple of hours turning the code into diagrams. I haven't found an affordable drawing tool that I can install use on one of my not ever connecting to the internet PCs :(

As to Map Scripts yes a map script needs to be associated with MAP_MON or what ever. As do the base terrains but I don't think anything else does. Terrain Features and Resources are linked to base terrain and Improvements are either linked to base terrain or features or resources.

Maybe. You can also retrieve plots from CvMap I think, but you could b right that a variant of CyPlot that takes a map Id will be needed. This will be an id though not just an int (so like building ids and so on)
 
Wait so there would be 2 different maps #2 Orbit and #4 Solar System? Or is the Orbital Map on the Z axis of Earth, meaning Z up is Orbital and Z down is Underground/Underwater? Which would mean if you went "UP" you would still be on the same latitude and longitude as where you took off from on the surface of Earth.

So we would have like ...

- Earth (Surface)
- Earth (Underground/Underwater)
- Earth (Orbital)

But then what about on the other terrain maps?

- Moon (Surface)
- Moon (Underground)
- Moon (Orbital)

- Mars (Surface)
- Mars (Underground)
- Mars (Orbital)

- Solar System
- Galactic

That makes 11 maps rather than the 5 proposed maps. Or should we have only Earth get Orbital and Underground maps?

Wow that is amazing? Question is it possible with the current system?
 
Wait so there would be 2 different maps #2 Orbit and #4 Solar System? Or is the Orbital Map on the Z axis of Earth, meaning Z up is Orbital and Z down is Underground/Underwater? Which would mean if you went "UP" you would still be on the same latitude and longitude as where you took off from on the surface of Earth.

So we would have like ...

- Earth (Surface)
- Earth (Underground/Underwater)
- Earth (Orbital)

But then what about on the other terrain maps?

- Moon (Surface)
- Moon (Underground)
- Moon (Orbital)

- Mars (Surface)
- Mars (Underground)
- Mars (Orbital)

- Solar System
- Galactic

That makes 11 maps rather than the 5 proposed maps. Or should we have only Earth get Orbital and Underground maps?

If we have that many maps we WILL run into memory problems as the game will just have to store so much data. I propose that we get the 5 we have in mind done (along with the Galactic Era) first, that in and of itself will be a big enough challenge.
 
DH
Uhm, would you please explain HOW Civ stores info on:
Terrain plots (type, upgrades, units, cities, anything else);
Cities (place on map, detailed info, present units, build queue, etc);
Units (place on map, info, active orders, etc)...
Cause you confused me with your answer.
I was HOPING for, say, units to have their placement info in a (x, y) way, which can be DLL'd into (x, y, z), where z would relate to the MAP the unit is on.

Heroes of Might&Magic (3 and above, I think) uses a two-level map, which is how I see Civ utilizing the same idea - not script wise, of course (totally different programs), but game play wise.
I thought MAYBE this could give you some unexpected ideas as to how to make it work.
Probably not, sorry...
 
There are 3-4 bits that we are talking about, all are different so it may well be confusing.

- XML how and what do we need in the XML
- Map scripts how do they link to base terrains and how do they store the information for the program
- the program as it is running and saving
- the UI for displaying the map.

One solution is not always the best for all.
 
OK, so which of those is the easiest to affect into having a NEW variable that would reflect the object's MAP number?

1. XML is probably the easiest to change, yet it's kinda irrelevant to real-time handling which we need for my idea.
2. Probably THIS is what I was asking about - how the object KNOWS where it is and what it's supposed to do next (or able to do).
3. Or THIS. Though saving is the easiest - you just introduce the new variable into both saving and reading. The problem is HANDLING...
4. Could be used to either have multiple maps, while showing only one at a time (eats memory with big maps or many maps) OR could be used by separately switching between showing and hiding each separate object reflecting its current placement and status. The latter should eat less memory in chunks, but will eat more constantly used memory - which might end up in different quantities both ways. Explanation: Either build a map and then redraw it each time it gets called OR check through all on-screen objects each time any of them is called (unit selected or commanded, map moved, city opened/closed, etc).

Can't say anything beyond this - which is exactly my question: what would be easiest to AFFECT?
 
one thing is sure with multi maps my pc will not like anything above Medium size :P but i'm quite intrigued by the idea and concept and i've always loved that kind of gameplay at the various games that has it

the lighter the load the better it is gameplay wise though getting it working in the first place should be prioritized above being nice to any pc
 
Tbird recommended I come and help you guys out. Personally, I have not looked into swapping out one map for another but I do have some practical suggestions for some of the things being discussed here. I am going to start grounded and work my way up.

Sea Colonies and Multi maps
First, this could be implemented at any time on the regular map as long as people don't mind the slight "huh?" factor of having sea cities appearing to stick above the water. Major (the other developer for the Genetic Era Mod) took care of nearly all AI issues regarding sea cities and so this is not a big problem. I could port his sea city code at any time.

Second, I don't really like the idea of having to switch between maps for undersea cities. The only advantage I can see coming of this (other than making cities look like they are under water) is that it would be easier to do ocean floor features. Practically speaking though I think it would make movement between cities a major hassle, especially since that would mean a whole new set of AI routines.

Moving between maps
I think the Z axis method is not only impractical, but could be confusing as well. I also don't like the "Move to cites..." list idea. Here is my suggestion regarding the multi-map system and settting it up so that it doesn't get too complicated and user-unfriendly.

  • Since most vehicles would be constrained to a single domain, it doesn't make sense to have vehicles that can just jump to any city on an alternate map (unless we develop some inter-dimensional portal system or something).
  • In most cases, this allows us to keep movement on a single map simple.
  • For moving off world (to another map) we would use missions as has been suggested.
  • Movement between specific maps would be facilitated by a "city" building such as a space port. Being in a "city" with a map portal (such as the space port) would enable the mission that would carry it to the next map (such as from Earth to the Solar system map).
  • For off-world transitions, (or out of solar system transitions), people would also need at least one space craft / interstellar craft in their arsenal in order for the map transition mission to be enabled (a special variable would keep track of the number of these types of craft on a global scale). These could be projects rather than units.
  • There would be a basic set of MAP TYPES that would determine what a "City" represents and what kind of building must be built to allow switching to another map type.
  • Buildings would need a new "Maptype" tag similar to the "Domain" tag for units.
  • Each "Portal" building between maps would either lead to a specific map (and at least half of the time, a specific "city" on the map).
  • In cases where there are multiple possibilities as destinations, (such as landing on earth from space), the options would be limited to friendly cities with space ports (or whatever type of portal is appropriate for the type of map).
  • These portals could be horrendously expensive, have strict limitations, or a national building (like a national unit...) to limit how many cities could have them.


Multi-Maps and Map Scripts
Honestly, I have never liked map scripts. Part of that may be because I just don't like dealing with script languages and so I have never bothered to try and understand them. The GeoRealism engine is not an alternative to the map scripts. Instead, it takes a map generated by the map script and extrapolates information that is used by the engine and converted into information that is then run through a simulation. That simulation has its own version of plot data that is moveable (not tied down to a specific plot) since plates move. That data is then re-converted back into the final map.

Personally, If it is possible to define the important information in a map script into XML data, I think it might be a good idea to port the map script from python to the SDK converting the map scripts into XML and possible even an XML based script (only if necessary).

I may be able to figure out a way to do this myself but the only part I am not sure about is the fractal generator. Where is that done? If this can be done, then multiple maps and map scripts will not be a problem.

The Mini Map
I colored this red because I wanted to catch someone's attention. Someone said that there is a mod out there that adds/changes buttons on the mini-map. If this mod exists please post a link because I am needing to do this myself for the Geo Realism mod and I would like some pointers on how to go about doing this.

One last note
I can post my ideas (specifics) on map types and "portal" building types if you guys think this approach might work.
 
Sea Colonies and Multi maps
First, this could be implemented at any time on the regular map as long as people don't mind the slight "huh?" factor of having sea cities appearing to stick above the water. Major (the other developer for the Genetic Era Mod) took care of nearly all AI issues regarding sea cities and so this is not a big problem. I could port his sea city code at any time.

Second, I don't really like the idea of having to switch between maps for undersea cities. The only advantage I can see coming of this (other than making cities look like they are under water) is that it would be easier to do ocean floor features. Practically speaking though I think it would make movement between cities a major hassle, especially since that would mean a whole new set of AI routines.

Really? That sounds quite interesting. The AI in C2C is very much structurally different from vanilla BtS though, so I don't know how well a straight copy-paste job would work for us. There are also some other issues with undersea cities

  1. Domain Interactions are messed up. If you have a unit underwater it will be considered attackable by ships. Even ones that don't have ASW capabilities, nevermind the ability to hit the ocean floor. This is also a bug with the Sea Tunnels.
  2. The game really does not like regions becoming connected. It forces the game to recalculate ALL trade routes, which can take a very long time by the time you are in the Transhuman Era. The AI is also freaked out by this, which is why Sea Tunnels are disabled by default in C2C.
  3. The graphics for sea cities render on top of the water. I'm not certain if this is fixable or not given engine limitations, but it is disconcerting.

So those would also have to be addressed before adding Underwater Cities. However I'd fully be in favor of making that a goal for V29 if we are willing to focus on it along with multimap stuff and AXXXXE (possibly).

Moving between maps
I think the Z axis method is not only impractical, but could be confusing as well. I also don't like the "Move to cites..." list idea. Here is my suggestion regarding the multi-map system and settting it up so that it doesn't get too complicated and user-unfriendly.

  • Since most vehicles would be constrained to a single domain, it doesn't make sense to have vehicles that can just jump to any city on an alternate map (unless we develop some inter-dimensional portal system or something).
  • In most cases, this allows us to keep movement on a single map simple.
  • For moving off world (to another map) we would use missions as has been suggested.
  • Movement between specific maps would be facilitated by a "city" building such as a space port. Being in a "city" with a map portal (such as the space port) would enable the mission that would carry it to the next map (such as from Earth to the Solar system map).
  • For off-world transitions, (or out of solar system transitions), people would also need at least one space craft / interstellar craft in their arsenal in order for the map transition mission to be enabled (a special variable would keep track of the number of these types of craft on a global scale). These could be projects rather than units.
  • There would be a basic set of MAP TYPES that would determine what a "City" represents and what kind of building must be built to allow switching to another map type.
  • Buildings would need a new "Maptype" tag similar to the "Domain" tag for units.
  • Each "Portal" building between maps would either lead to a specific map (and at least half of the time, a specific "city" on the map).
  • In cases where there are multiple possibilities as destinations, (such as landing on earth from space), the options would be limited to friendly cities with space ports (or whatever type of portal is appropriate for the type of map).
  • These portals could be horrendously expensive, have strict limitations, or a national building (like a national unit...) to limit how many cities could have them.

That is approximately what I was thinking too. The only real obstacle to Multi-Maps now is UI and AI, as well as some code issues (most of the iterators need to be changed to only go through stuff on a single map, and a new set of iterators has to be added for new maps). If you want to work on that after GeoRealism I'm sure Koshling would be quite happy (multi-maps aren't his favorite thing to mess with).

Multi-Maps and Map Scripts
Honestly, I have never liked map scripts. Part of that may be because I just don't like dealing with script languages and so I have never bothered to try and understand them. The GeoRealism engine is not an alternative to the map scripts. Instead, it takes a map generated by the map script and extrapolates information that is used by the engine and converted into information that is then run through a simulation. That simulation has its own version of plot data that is moveable (not tied down to a specific plot) since plates move. That data is then re-converted back into the final map.

Personally, If it is possible to define the important information in a map script into XML data, I think it might be a good idea to port the map script from python to the SDK converting the map scripts into XML and possible even an XML based script (only if necessary).

I may be able to figure out a way to do this myself but the only part I am not sure about is the fractal generator. Where is that done? If this can be done, then multiple maps and map scripts will not be a problem.

We have a thread named exactly that and talking about these issues. I agree, using the GeoRealism engine (not all of it of course, specifically there won't be much climate to speak of on the moon or in the Galaxy) to start would be a very good idea, but we still would need to implement a mechanism to invoke a mapscript during gameplay to make a map once you acquire the ability to go to that map.
 
Personally, If it is possible to define the important information in a map script into XML data, I think it might be a good idea to port the map script from python to the SDK converting the map scripts into XML and possible even an XML based script (only if necessary).

I may be able to figure out a way to do this myself but the only part I am not sure about is the fractal generator. Where is that done? If this can be done, then multiple maps and map scripts will not be a problem.
This is exactly what I was hoping we might be able to do. Define all the scripting variables via xml, particularly since we have so many differing types of maps to run through. And run a map generator via the SDK thereafter, abandoning any reliance on python to cover this matter so we can enhance our map generation speeds (since we'll need the highest optimal processing speeds for those events.)

Shouldn't be necessary to reinvent the wheel where the earth map is concerned (beyond the brilliant project you're working on now) but for the additional ones, something extremely streamlined for speed would be optimal.

Koshling understands the current multi-map methods and how it interacts with viewports like nobody else. AIAndy understands the map scripting as we currently have it like nobody else. primemOver understands the methods that can be employed to program additional mapping processes and final touches like nobody else. DH and Hydro have been working on terrain details and features for the additional maps. ls612 is doing a great job comprehending and interpolating all the comments made by all of the above and along with Vokarya and Hydro is doing a great job on sorting out the futuristic tech paths. And if needbe, I can help a lot with mission designs and now, popup selection lists.

Surely this team, with all its specialties in place, can get this multi-map project to completion!

I think from here, AIAndy needs to help Prime and Koshling understand the map scripting and how to tie it in (or convert it) to an ingame map generation mechanism and Koshling needs to help us understand how new maps are to be stored, accessed in game and in code.


RE: the portal issue. I see something like that being developed by buildings in cities, yes, to function like airports. But I also see units themselves having missions to switch maps (like units that launch into space travel.) We have air units that would crossover into space units and when so doing would, depending on the map, act quite differently (somewhat like going between an AIR Domain status to a SPACE domain status and operating more like a ground unit when flying about in space and more like an air unit when stationed out of a city.) Or units that operate like missiles but when launched to another planetary map, like say, the moon, they work more like ground units and rove around (possibly even destroying themselves in the launch and leaving a new roving unit at the target of the launch attack site.)

Portals, so to speak, would be a very lategame development I think. But something akin to airport missions would be a big leadup throughout these eras.
 
Wait so there would be 2 different maps #2 Orbit and #4 Solar System? Or is the Orbital Map on the Z axis of Earth, meaning Z up is Orbital and Z down is Underground/Underwater? Which would mean if you went "UP" you would still be on the same latitude and longitude as where you took off from on the surface of Earth.

So we would have like ...

- Earth (Surface)
- Earth (Underground/Underwater)
- Earth (Orbital)

But then what about on the other terrain maps?

- Moon (Surface)
- Moon (Underground)
- Moon (Orbital)

- Mars (Surface)
- Mars (Underground)
- Mars (Orbital)

- Solar System
- Galactic

That makes 11 maps rather than the 5 proposed maps. Or should we have only Earth get Orbital and Underground maps?

Idea!

1. We have 5 maps (Earth, Moon, Mars, Solar System, Galaxy)

2. Each tile has a random 'Z' property ranging from rock, mud, dirt, cave, lava, water.

3. Each unit has a 'Z' tag.

4. When a unit is created, it will be assigned a 'Z' variable ranging from 0 to 2. (0 if underground, 1 if on the surface, 2 if orbital)

5. Make a 'Z' variable invisibility system that units cannot see nor interact with units of other 'Z' variables than that of itself.

6. Make three GUI buttons to toggle which 'Z' plane is viewable (Underground, Surface, Orbit) and turn on/off unit visibility dependent on viewed 'Z' plane.

7. When GUI button for Underground is pressed, tile 'Z' property is turned on and normal property is turned off, thusly making underground tiles viewable.


This system would be similar to the Civ V tactical view in that it's the same map, but it's being viewed differently.
 
  • Since most vehicles would be constrained to a single domain, it doesn't make sense to have vehicles that can just jump to any city on an alternate map (unless we develop some inter-dimensional portal system or something).

This was never a suggestion. It was a "Go to..." function similar to what we already have except you could select the target city rather than scroll the map and click on the target; or switch maps and scroll and click; or switch view ports scroll and click; or a combination of both map and view port and scroll and click. It satisfies the majority of the functions Hydro asked for. It does not satisfy the request for exploratory missions to land close to a target location though.
 
Idea!

1. We have 5 maps (Earth, Moon, Mars, Solar System, Galaxy)

2. Each tile has a random 'Z' property ranging from rock, mud, dirt, cave, lava, water.

3. Each unit has a 'Z' tag.

4. When a unit is created, it will be assigned a 'Z' variable ranging from 0 to 2. (0 if underground, 1 if on the surface, 2 if orbital)

5. Make a 'Z' variable invisibility system that units cannot see nor interact with units of other 'Z' variables than that of itself.

6. Make three GUI buttons to toggle which 'Z' plane is viewable (Underground, Surface, Orbit) and turn on/off unit visibility dependent on viewed 'Z' plane.

7. When GUI button for Underground is pressed, tile 'Z' property is turned on and normal property is turned off, thusly making underground tiles viewable.


This system would be similar to the Civ V tactical view in that it's the same map, but it's being viewed differently.

Um how do you do that? If it could be done it would be great. I just did not know one could toggle things off like that.
 
RE: the portal issue. I see something like that being developed by buildings in cities, yes, to function like airports. But I also see units themselves having missions to switch maps (like units that launch into space travel.) We have air units that would crossover into space units and when so doing would, depending on the map, act quite differently (somewhat like going between an AIR Domain status to a SPACE domain status and operating more like a ground unit when flying about in space and more like an air unit when stationed out of a city.) Or units that operate like missiles but when launched to another planetary map, like say, the moon, they work more like ground units and rove around (possibly even destroying themselves in the launch and leaving a new roving unit at the target of the launch attack site.)

Portals, so to speak, would be a very lategame development I think. But something akin to airport missions would be a big leadup throughout these eras.

Don't take the word "portal" literally. Although such a technology may exist in the future, I am only meaning this in figurative sense; meaning a way to access a different map. I am posting the table I mentioned earlier to show what I mean.
 
Back
Top Bottom