AI All-terrain transport development

[Deliverator]

Sounds promising...

 

[koma13]

If this is really working, I hope David will never have to touch the sdk again...

 

[davidlallen]

If this is really working, I hope David will never have to touch the sdk again...

The genie is out of the bottle on that one. Now that I have finally done it, I am starting to see possible sdk changes everywhere. For example, a lot of the checking for terrain upgrading/downgrading with terraforming is related to fresh water, and it would be much simpler to make slight changes to fresh water handling in the sdk and then dump about 400 lines of complex python.

 

[cephalo]

Wow, the situation in that screenshot was that harkonnen(orange) declared war on me. In the autoturns my faction bribed two allies, who then completely wiped out harkonnen with huge transport fleets full of troops. I don't think I've ever seen such a decisive war between AI civs.

 

[cephalo]

One minor problem that I've seen is that the drop zones are not so great. In the screen shot I gave, that stack actually went to the west of the target Harkonnen city, and on the way there was exposed to land attack. It was not attacked, possibly because Hark was in defensive mode, but I understand that suspensors are vulnerable to land units is that correct? You don't want to drive circles around the city before landing I assume.

 

[davidlallen]

Vehicles, such as rollers and tanks, have a bonus against suspensors. Vehicles also have move 2 and a home ground promotion so they should be able to move out a couple of squares from a city to attack. Are there vanilla units which are more likely to sally against incoming attackers? Perhaps there is a UNITAI change which would make the AI sally more often.

 

[Deliverator]

Now that I have finally done it, I am starting to see possible sdk changes everywhere.

For a professed SDK bigot this is an amazing turnaround.

 

[cephalo]

Vehicles, such as rollers and tanks, have a bonus against suspensors. Vehicles also have move 2 and a home ground promotion so they should be able to move out a couple of squares from a city to attack. Are there vanilla units which are more likely to sally against incoming attackers? Perhaps there is a UNITAI change which would make the AI sally more often.

Well, in this case Harkonnen was badly outnumbered, and was almost certainly set to AREAAI_DEFENSIVE. They won't move out of their city if there is danger nearby. This would have to be treated as a special circumstance, but even so, Harkonnen really didn't have an option. He had only a few defenders and there were at least two Sus. gunships to deal with before getting to the transports. So maybe he did act properly by not attacking them.

 

[cephalo]

Ok here is the source code. I'm pretty confident that it is working without major problems. All my code is marked with 'cephalo' in the usual manner.

How it works is that I made two new AreaAITypes, AREAAI_ASSAULT_SAME_AREA and AREAAI_ASSAULT_SAME_AREA_MASSING, and because this settings are hybrids of previous ones, I went everywhere the old settings are used and determined the intent of the code and how it should handle these situations.

Basically, if the AI are not touching borders with an enemy, it will use transports. At the unit level, the units will forget about boarding transports when they are standing in enemy territory.

I also published a new version of Arrakis.py that is basically a pangaea in order to test this new AI.

 

[koma13]

I compiled the source files from Cephalo. Now when I try to enter desert I am getting this error again:

Spoiler :

I don't know what's causing it, but it's not the CvUnit.cpp.

EDIT:

I am not sure it is related, but when I compiled the sources I got that 'CvTextMgr.h' error. I handled it by removing CvTextScreens.cpp from the project.

Now here is line 7391, responsible for the python exception:

screen.setHelpTextString( CyInterface().getHelpString() )

getHelpString() <-> CvTextMgr

 

[cephalo]

I compiled the source files from Cephalo. Now when I try to enter desert I am getting this error again:

Spoiler :

I don't know what's causing it, but it's not the CvUnit.cpp.

EDIT:

I am not sure it is related, but when I compiled the sources I got that 'CvTextMgr.h' error. I handled it by removing CvTextScreens.cpp from the project.

Now here is line 7391, responsible for the python exception:

screen.setHelpTextString( CyInterface().getHelpString() )

getHelpString() <-> CvTextMgr

I got this error too with the 1.5 dll I started with. I just ignored it. It's probably due to a helpstring regarding ocean that we removed sue to obvious reasons.

 

[koma13]

Ah ok, I understand.

Here is a CvGameCoreDLL.dll with Cephalo's changes for people who don't want to compile the sources. There is a quick workaround included to bypass the python exception:

http://www.mediafire.com/download.php?itdcjdzmq22

 

[davidlallen]

I pointed cephalo at the sources in the 1.5 distribution, but that was not quite the right thing to do. As you may recall I released 1.5 with a huge bug, regarding right clicking on ocean, and I solved it by dropping back to a slightly earlier dll from koma without some of my latest changes. So the sources in the 1.5 disti do not quite match the dll in the 1.5 disti. The dll works, but recompiling from the sources will still cause this bug. My mistake.

I have subsequently solved the bug for right clicking on ocean, which involved remaking some changes to CvGameTextMgr.cpp. Basically function CvGameTextMgr::setCombatPlotHelp was missing two null checks. Please find attached the file with this bug fixed.

 

[davidlallen]

Basically, if the AI are not touching borders with an enemy, it will use transports. At the unit level, the units will forget about boarding transports when they are standing in enemy territory.

I also published a new version of Arrakis.py that is basically a pangaea in order to test this new AI.

I have not merged the code or tried it out. But if I understand correctly, you are saying that the AI will now use all terrain transports and escorts to attack anywhere, except if the borders are directly touching. That is great!

Let us discuss what the resulting mapscript might look like. (Yes, on this thread, since we are currently using the other map thread to discuss about deliverator's heightmap changes.)

If you think about Dune as a pangaea, then all the spice is on the outside of the map. For a large map, there is a long distance between the center of the map, and the ocean. This means some civs will start very far away from spice, and the resulting commerce income.

A long time back we had discussed that perhaps the center of the map should be polar ice, with water yield. But we got stuck before agreeing whether cities should be buildable on ice. One could think about a radially symmetric map, with a donut of land. Inside it at the center is ice. Outside is spice. If the donut is not very thick, then civs could reach both. After initial expansion, each civ would have a shape like a pie slice, with a bit of ice terrain and a large outer expanse of spice mining operations.

However, I am not sure how this would scale to larger map sizes. I think the donut would have to become very thick, and then civs would not easily be able to reach *either* the spice or the ice.

What do you think about the big picture of this type of mapscript?

 

[Ahriman]

A long time back we had discussed that perhaps the center of the map should be polar ice, with water yield. But we got stuck before agreeing whether cities should be buildable on ice. One could think about a radially symmetric map, with a donut of land. Inside it at the center is ice. Outside is spice. If the donut is not very thick, then civs could reach both. After initial expansion, each civ would have a shape like a pie slice, with a bit of ice terrain and a large outer expanse of spice mining operations.

This is how I imagined the script would be, except that the donut is not a complete chain, it is broken in several places by straits of desert.
I think it is fine for the mapscript to only really work well on a couple of map sizes. We only have ~10 factions, so the game is only likely to work for small-medium-large maps. There is nothing wrong with designing the mod to work on a particular map size and game speed.
Planetfall is designed to be played on a normal sized map, or maybe small.

 

[davidlallen]

This is how I imagined the script would be, except that the donut is not a complete chain, it is broken in several places by straits of desert.

That would be like archipelago, with no/fewer islands at the outside of the map. Another possibility would be pangaea, with a huge number of lakes.

We only have ~10 factions, so the game is only likely to work for small-medium-large maps.

We should try to make duel, tiny, small, standard and large all work, we have enough civs for those. I often play small, since I can finish a game in a couple of hours.

 

[Ahriman]

That would be like archipelago, with no/fewer islands at the outside of the map. A

Yes, this is what I had in mind; this is what the Arrakis maps look like to me. There isn't a completely unbroken wall of mountains surrounding the pole.

another possibility would be pangaea, with a huge number of lakes.

And lakes being desert? Maybe.

Whatever we use, we need to make sure that it isn't just a pure donut of land, because then culture won't be spreading out into the desert to cover very many spice tiles. If its a pure donut of land, then cultural borders will also be a donut, spreading ~3-5 tiles further outside the land donut, which doesn't cover very much desert.

So there need to be lots of gaps in the land where there is desert, so that cities on the land still cover a decent amount of desert.

I think it is likely to be very difficult to ever get the AI to contest or access spice resources that arent' within their cultural borders.

* * *
Also, its ok for the donut to be fairly wide; it could be an interesting strategic choice on whether you try to expand more towards the center, for the good polar terrain, or towards the outside, for more spice resource.

 

[cephalo]

This is how I imagined the script would be, except that the donut is not a complete chain, it is broken in several places by straits of desert.

Yeah, that's what I would like to go for. It looks like the fictional dune map. The polar areas are actually continuous with the dunes from outside the pole, but the frozen water in them keeps out the worms.

 

[cephalo]

Keep an eye out for transport mishandling by the AI. If they risk them needlessly I may have to make some adjustments. Also, make sure I hear about it if the AI gets stuck in a loop. That happened once when I tried to fix what appears to be a very old bug in the Civ AI. I unfixed it just in case, but if that was not the issue, I might like to fix it again along with whatever is really causing the loop.

One thing about this change that is kinda cool, and very different from BtS, is that AI war allies are now extremely potent. On the continental type maps I played, I never worried about my enemy calling in allies in BtS. I don't think I ever saw an invasion by someone other than my principle enemy.

In this game though, two against one is really two against one, and three against one appears to be devestating! It should be interesting to see if that is as desireable as it should be.

 

[davidlallen]

After looking at the AI, I would be surprised if the Fremen could attack another continent without transports. If you take away their transports I don't think they would try to invade without some extra AI logic in place to utilize their ability to cross the desert.

I have done some autoplays with my local version, which is about to become 1.5.4. The Fremen are in serious trouble. In almost every autoplay, they are either dead, or way in last place, by turn 250. That is sad, because the "concept" is that they are supposed to be able to grow very fast in the early game.

The Fremen differ from the other civs because every foot unit is given the "sandrider" promotion by default. This happens in python. The sandrider promotion allows them to enter deep desert from the start of the game, and get a 2x movement bonus. So the starting units, such as worker, scout, settler can all move 4 in desert, and the warrior can move 2 in desert. As a human player, this appears to give me an advantage in development. Other civs have the Scout Thopter to transport two of these foot units, and they appear to be able to found colonies fine. The Fremen have a scout UU, which prevents them from building the scout thopter.

However, the AI appears to be completely unable to recognize the sandrider promotion. Is there another way to accomplish the fast desert move? Or a way for you to tweak the AI so it does not fail so badly?