Civ4newbie
Warlord
- Joined
- Aug 8, 2007
- Messages
- 226
No sea cities at the moment the AI does not know how to use them and there are other problems.
So when do you think sea cities will be ready with sea mines, ect... before multimaps?
No sea cities at the moment the AI does not know how to use them and there are other problems.
So when do you think sea cities will be ready with sea mines, ect... before multimaps?
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.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.
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.
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?
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?
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.
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.)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.
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?
- 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).
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.
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.