Some requests requiring SDK(?)

I'm not too sure what you mean by random techs but the others seem to be self explainatory.

I'll have to say that I think the only way to get either of those things working would be with the SDK. I could be wrong... maybe python could do it. IDK but I do like the idea of having more than one map during a game. It's something that would be great for an advanced level of the game after launching the spaceship. :D
 
I'm trying. Having problems. I've lost extensive tracts twice. Half the time I try to post I am told I am signed on as a guest.

Analytical AI: . Humans like mods because they do better since they get a human advantage from being able to analyze, whereas AIs tend to try to use the vanilla strategy even where it is out of place, unless reprogrammed for the mod. Just as the AI can be programmed to build a settler when it has a surplus gold cashflow, or to take militarily aggressive actions more often than not, it could be programmed to analyze the current mod rules, ie backwards plan from a victory strategy and flowchart a course to it from the current situation, ie do I have bronze or horses.

Multiple Map Capability:
Having more than one map per mod, with limited movement and trade between the maps possible.
The simplest form of this would be the planet map. If a certain unique unit is in a tile, then any unit in that tile can move to a different map, created by the mod maker and included in the mod folder. Similarly, units on that map can move to whatever tile on the first map that the map-associated-unit was associated with. Call these branch maps "planets."
To make this more advanced, you could have Planet types, which have certain selected map types (cold/wet/lakes, continents etc...) possible to them, a limited set of terrain types, a limited set of resource types, etc...
Resources and terrain tiles could be associated with planet types, rather than just unique units. Or cities. You could have certain standard prepainted maps, which are nevertheless map types, since they are used over and over and each iteration is unique, with different special features and units. When a player unit first goes to a given map it is generated.
Finally, there is the layer map. Each tile on a layer map corresponds to an associated tile on another map. Layers could include underground/undersea, surface, for air, even low and high orbit.
Of course all this adds a lot to processor demands.

Random Techs: Various possibilities
a. Tech costs are randomly generated at the start of each game within modder defined ranges
b. Tech cost and prerequisites are randomly generated at the start of each game within modder defined ranges. You only see the prerequisite structure and costs of immediately researchable techs. For example, we don't know whether Nanotech or Genetic Engineering will lead to Immortality Treatments. It might take both, or may take something completely different and both of those are irrelevant. All we know is that Nanotech and Genetic Engineering are the next things we can look into now. Immortality Treatments is a future goal, not an immediately lab ready research project like genetic engineering and nanotech.
c. Instead of a tech simply costing a certain number of test tubes it costs a given number of test tubes only on average, with actual research success being probabilistic. Every turn the engine randomly determines whether you get a tech you are researching, with the difficulty of the tech decreasing probability and the number of test tubes you are producing increasing it.
(A couple of comments on this: it wouldn't be that demanding, like calculating culture for each tile. It's one operation per civ per turn. And a really simple way to do it would be to simply have test tube generation be multiplied by a random number for each civ each turn, except if the random numbers are distributed exponentially, so there is a ten percent chance of a 10x, a 1 percent chance of a 100x, etc...)
 
This is the second iteration of this post. The first was removed as most of the questions it asked were answered in the post above which was being written at the same time as this one.

1) That breaks my head just thinking about it. The current AI takes each decision as it comes, weighing up all the current pros and cons, and, in some cases, attempts to look into the future to see what the likely pros and cons to come will be. It does prioritise things which will lead it to victory (like spaceship parts), and also prioritises things which will lead to to things which will lead it to victory (techs for spaceship parts).

As far as techs go, at the moment it analyses all the techs within the current era, and the next era (and with a path less or equal to 3, or 1 if it's a free tech) and picks the one it thinks is best. The shotest path in beakers to this tech is then generated. This doesn't seem to me to be quite optimal, as it really should pick the best one inclusive of the path taken. In other words, it would pick a tech with costing 50 beakers and doing nothing over a tech costing 55 beakers and doing all sorts of good things because it would mean it had 5 more beakers to spend on the tech which requires either of them and is better than both of them... but it's pretty good.

I strayed OT a bit there...

How would you suggest somebody go about doing this?

2) Would be good, yes. Might even be possible. Might even only be moderately difficult, if we're lucky.

3) Hmmm - I like a) the best. b) and c) introduce uncertain uncertainty (as opposed to certain uncertainty like combat, or a)), and a stroke of bad fortune could cripple you. Realistic? Yes. Fun? Probably not.
 
Fourth request: Terrain improvements similar to cottages, but for food and shields (except with maximums limited by available resources and terrain type)
 
Tholish said:
Fourth request: Terrain improvements similar to cottages, but for food and shields (except with maximums limited by available resources and terrain type)
You can do the bare bones of the with XML. You'd have to make a python script for the second bit though.
 
I am toying around with the second request but are having very limited results... I think it might take a lot of code to get it to work correctly using the SDK.
 
Reality is very rich. The quest to elegantly simulate it invariably generates stuff that can be put together in fun ways. The random prerequisite structure would make each game a brand new tech tree mod. True, hiding second order future techs would obviate master plans
but it would make it easier to teach the ai to tech pick on something like a par with people.
 
I have worked extensively with Multiple maps with the SDK, however, it seems to me that it is not possible only with the SDK, and we need additional source code (here the executable file), however the source for this isnt released, so it will not be possible.

I am not 100 % sure about this, but I have not been able to determine various things about the map. It is easy to make a second map, but having it generate terrain and having the game switch to the other map is what I were unable to determine, my game kept crahing. I also have an idea that it is not thread safe to have 2 maps, here again we need entire source code, IF it should be possible... :sad:

NOTE:
I am NOT saying we SHOULD crack the non-published source code, I merely state that I think we need it, if it should be possible.
 
NikG said:
I am not 100 % sure about this, but I have not been able to determine various things about the map. It is easy to make a second map, but having it generate terrain and having the game switch to the other map is what I were unable to determine, my game kept crahing. I also have an idea that it is not thread safe to have 2 maps, here again we need entire source code, IF it should be possible... :sad:
How do you know you've created a new map if you can't do anything with it ;)

Sounds promising. Have you checked out CIV4TerrainSettings.xml? I was poking through the terrain files today and stumbled across it. Not sure if it is useful or not as I haven't really had to chance to fiddle with maps.
 
The Great Apple said:
How do you know you've created a new map if you can't do anything with it ;)

:D I know it becuase of the sematics of how I programmed it.

Sounds promising. Have you checked out CIV4TerrainSettings.xml? I was poking through the terrain files today and stumbled across it. Not sure if it is useful or not as I haven't really had to chance to fiddle with maps.

I am not sure it is so promising, if it were I didnt stop working with it. It took me very long to just make sure I didnt miss something. The CIV4TerrainSettings.xml is not useful, :sad:

What the problem is that I not able to determine were the call to the terrain generation is placed, and without it, no terrain is generated...
 
Hmmm. Right. IIRC all the map generation is handled in python, however what you need is a call to make it. Surely this is all held in CvMap::init(...) - that's what that function looks like it does anyway...

Any chance you could post your code so people can take a look at how you've got this far. I know several will be interested.
 
It might be possible to do a workaround by creating a map script to generate a map then split that map in two, cut off the wrap functions, then create entry points from map to map. Similar to how master of magic worked but more advanced.
 
I guess you could conceivably create a "null" terrain type, slap a whole big block of them between two "maps" in one map file; with one above, and the other far enough below, you could then continue to keep the x-axis wrapping. Since there would be no graphics, and practically no data, to load for the null terrain, I imagine there'd be no real issues with game performance and requirements, either. The most obvious significant obstacle with the approach would have to be the global view, and another would be achieving "semi-global" effects that only impact one of the individual playing fields.
 
A Silly Goose said:
I guess you could conceivably create a "null" terrain type, slap a whole big block of them between two "maps" in one map file; with one above, and the other far enough below, you could then continue to keep the x-axis wrapping. Since there would be no graphics, and practically no data, to load for the null terrain, I imagine there'd be no real issues with game performance and requirements, either. The most obvious significant obstacle with the approach would have to be the global view, and another would be achieving "semi-global" effects that only impact one of the individual playing fields.

Yeah that would be the bugger. That would probaly have to be worked in the SDK. But as a start in the Right Direction there would have to be a knew terrain or building to allow travel between two maps.
 
I really like the idea of the random techs, but more particularly, the hidden techs that are not immediately available.

For example: Let's say bronze working opens up both metal casting and construction, and you are able to research bronze working. Well, in that case it would be displayed on the tech screen, but the other two would not be.

Is this what you had in mind?

Although I personally have no idea how to make this work, I have a feeling that python could accomplish this part at least. :D
 
Among other possibilities, exactly what I had in mind. In MOO 3 terms, only near future techs are "visible," and only immediate future prerequisite structure is visible. When you have Mining, you know you could research bronze working or masonry, and you see that somewhere in the future is iron working, but you don't know whether bronze or masonry leads to it this particular game. And feudalism isn't even visible yet, you have no concept. Concealment has to go with random prerequisite structures too. Otherwise you learn the tree and concealing future techs is meaningless, like concealing the map if you can always restart from 4000 bc remember how you previously explored the whole thing. In randomly determining prerequisite stuctures, each tech has an "era," meaning a limited number of possible prerequisites.

In fact, it would make for a fun time exploring, while eliminating some strategy. Maybe you could add a futurism techs that allow greater knowledge of tech tree possibilities, just as you have scouts and map trading.

Now, about the map.

If you could put in some kind of routine that relocates units you could do wonders with it.

If a unit is located with a spaceport (improvement), planet (unit), or submap edge (resource) at the end of its turn it is relocated in some particular way.

For example, you could divide the 150 by 150 "overmap" up into nine 50 by 50 "submaps." The resource "right edge" subtracts 50 from the x coordinate of any unit located with it at turn end, while the resource "left edge" adds 50 to the x coordinate of any unit located with it at turn end. Home made wrap.

There is a neutral civ that allows everybody right of passage. Its units have names like Mars, Venus, etc...which are on sentry patrols on the space terrain submap. If a unit ends the turn located with the Mars unit, its coordinates are changed to a random location on the Mars submap.

Now, about the map.

If you could put in some kind of routine that relocates units you could do wonders with it.

If a unit is located with a spaceport (improvement), planet (unit), or submap edge (resource) at the end of its turn it is relocated in some particular way.

For example, you could divide the 150 by 150 "overmap" up into nine 50 by 50 "submaps." The resource "right edge" subtracts 50 from the x coordinate of any unit located with it at turn end, while the resource "left edge" adds 50 to the x coordinate of any unit located with it at turn end. Home made wrap.

There is a neutral civ that allows everybody right of passage. Its units have names like Mars, Venus, etc...which are on sentry patrols on the space terrain submap. If a unit ends the turn located with the Mars unit, its coordinates are changed to a random location on the Mars submap.

If a spacecraft unit ends the turn located on a plot with a "Mars Spaceport" improvement (which can only be built on Mars) its coordinates are changed to those of the Mars unit.

This sort of thing, however, would make the AI haywire, I think, unless it knew how to look around and try things, or consider possibilities and make some kind of backward plans some kind of way.
 
Back
Top Bottom