SMACX Thinker Mod

[Induktio]

I don't know where your .exe is at with late game AI terraforming.  For a stock .exe it's a non-issue.  The AI is never going to beat a competent player on Transcend.  The human player will get ahead, the AI is always going to be somewhat behind.  Caveat: the interim periods when I didn't know how to play my own mod yet.  But that passes.  Anyways, I terraform every single square by hand.  Gravships would never be useful to me.  Too late game, I've already done everything needed by then.

Stock AI's put up such a bad performance it's not really even a point of discussion. For a long time players used to do things like build-every-secret-project to find some challenge. I used to do that myself sometimes but now it's probably a little bit more challenging (read: have to conquer most of the early game ones).

In the original game they added lots of complex mechanics which the AI was not designed to handle very well. Also, I don't think I would go on increasing prototype costs by such a large margin or even at all. It's probably going to make the game harder for the AIs because it's not well equipped to strategize around those limitations unlike a human player.

The main problem with gravship formers automation is that the AI thinks they can only alter land when in fact they can alter both land and sea squares.  I’ve been surprised at how poorly they are automated versus other key units I have added such as needlejet colony pods.  Still, there aren’t many games that even see gravships so it’s not much of a priority.

Yeah, gravship formers would need some moderate restructuring of the movement code because they can modify both types of squares. So I have to consider that.

It's important to note here that the player's formers still use the default code when they are automated. They could be adjusted pretty easily to use Thinker's code instead, but the problem is that then they should obey the "automation preferences" selected by the user. Do you think we should have them use the new former code instead if the preferences are just followed? Probably it would be a good change.

[bvanevery]

In the original game they added lots of complex mechanics which the AI was not designed to handle very well.

True.  I run into things all the time that the AI doesn't know how to do.  Nowadays I think of them as "human cheats".  I push some of the HCs later in my tech tree, so that by the time they become available, the human will have probably already figured out some way to win anyways.  It's a soft way of taking things out of the game, without strictly removing content from the game.

Also, I don't think I would go on increasing prototype costs by such a large margin or even at all. It's probably going to make the game harder for the AIs because it's not well equipped to strategize around those limitations unlike a human player.

I have not observed the stock AI having any problem coming up with the more expensive prototypes.  Probably because the AI on Transcend is "cheating" like a mad dog, being given these huge INDUSTRY equivalent bonuses.  Also possibly because I have sufficiently delayed contact between hostile factions, by (expected) map size, extra land mass, and more defense for cities.

I don't know if it's been addressed, but I'd severely like to see the AI actually cash Artifacts to get techs.  And I'd like to see the number of pods that appear on the map be controllable by user input somehow.  They can so easily turn the game into just candy.

[BFG]

Yeah, gravship formers would need some moderate restructuring of the movement code because they can modify both types of squares. So I have to consider that.

It's important to note here that the player's formers still use the default code when they are automated. They could be adjusted pretty easily to use Thinker's code instead, but the problem is that then they should obey the "automation preferences" selected by the user. Do you think we should have them use the new former code instead if the preferences are just followed? Probably it would be a good change.

That’s a great question.  So long as user preferences are followed, yes, I would agree that any units automated by the user (not just formers) should use the same code as the AI.  I know that that means the player automated units will now be stronger, which flies in the face of what Thinker is about, but not having player AI be the same as other factions’ AI seems a bit unfair.

On a related note: you may also want to look at sea and gravship crawlers.  So far, whenever I automate sea crawlers they want to explore rather than harvest. I presume gravships would do the same but haven’t tried them yet.

[bvanevery]

I know that that means the player automated units will now be stronger, which flies in the face of what Thinker is about,

Not really.  Even if Induktio has come up with "better" terraforming AI, it will never, ever be as good as a human terraforming every tile manually.  If you automate them, it's suboptimal.  That's your choice as a player.  Induktio could make it less suboptimal, but he wouldn't be giving an advantage to the human.  The human already has the ultimate advantage of being able to do it all manually.

[BFG]

True, but I was talking relatively.  Now, automated player formers are inferior to AI ones.  Changing to the improved code would put them on par with each other.  Of course, direct control is superior to either.

Moving player automated formers to the new code will make the player stronger, if the player was going to automate in either case.

[Induktio]

As for the optimal strategy, good luck with that. Humans weren't able to calculate optimal strategy for Go either despite thinking for a couple of millenia.

Anyway, sea crawlers are not currently implemented. So whether behaviour they were doing is the result of the standard movement code which probably means the AI doesn't understand how to use them. Have to keep that in mind too.

I think, overall, having player's formers use the same code than the AI ones would make the game feel more consistent, since then the two types of formers wouldn't operate in a vastly different way.

[bvanevery]

As for the optimal strategy, good luck with that. Humans weren't able to calculate optimal strategy for Go either despite thinking for a couple of millenia.

I think near optimal strategy for terraforming is quite a bit less complicated than that.  It is mostly a minigame about leveling up squares.  Better vs. worse sequences of square improvements for a single city over a short period of time are fairly easily to determine.  That's how we all manage to do it manually.  Long term?  Well, war is hell.  Not really important to crystal ball too far into the future.

Optimal sequences of connecting roads and rails is more involved.

Anyway, sea crawlers are not currently implemented. So whether behaviour they were doing is the result of the standard movement code which probably means the AI doesn't understand how to use them.

AI sea terraforming is not incompetent.  It just overemphasizes minerals instead of energy.  It will even raise the ocean floor if you have the tech to do so and allow it to happen.

I think, overall, having player's formers use the same code than the AI ones would make the game feel more consistent, since then the two types of formers wouldn't operate in a vastly different way.

In principle it's a perfectly reasonable and obvious thing to do.  In practice, you may have a transitional period where you invent new bugs and misbehaviors.  Then someone might wish for that "dumb" original code.  Especially irritating in other games, is anything that gets a Former gratuitously killed.  Like moving the units right into the path of oncoming enemies, or failing to stop work and retreat.

[BFG]

AI sea terraforming is not incompetent.  It just overemphasizes minerals instead of energy.  It will even raise the ocean floor if you have the tech to do so and allow it to happen.

We were talking about crawlers there, not formers.  Sea crawlers are not implemented at all, and gravship crawlers poorly.

In principle it's a perfectly reasonable and obvious thing to do.  In practice, you may have a transitional period where you invent new bugs and misbehaviors.  Then someone might wish for that "dumb" original code.  Especially irritating in other games, is anything that gets a Former gratuitously killed.  Like moving the units right into the path of oncoming enemies, or failing to stop work and retreat.

True, though there are rare situations where you don’t want the formers to retreat...to buy you that last turn on a new defensive unit for an exposed colony, for example.

[bvanevery]

Oddly enough, Needlejet Supply works.  Although, it seems only for the AI.  I got rid of Copters in my mod.  I replaced the Unity Chopper with a Supply Needlejet, so that it can't attack anything.  I wanted to use a Transport module but it was too slow.  The Supply module doesn't have that problem.  So, the AI can gain one of these from the Unity crash site, or occasionally from popping a pod.  I was quite surprised to see the AI put them over a square somewhere and convoy resources indefinitely.  When the AI uses them, they stay aloft indefinitely, never leaving the square they're convoying from.  When I use them, they crash and burn in short order!

I don't think they go for optimal squares.  Like seeking out a Nutrient or some such.  They just seem to pick something and stick to it.

I can't remember if I've tried adding a sea crawler to the predefined units.  Guess I can try it now.

[Induktio]

Had an interesting idea recently. I guess most players remember how later Civ games introduced the rule that units cannot use the roads in the enemy/non-allied territory?

It seems the same rule could be implemented quite easily in SMAC by changing the movement cost function. In the gameplay it could be a pretty big change, but I think it would make more sense especially after the introduction of mag tubes. It would also have to be decided how this rule would apply on native units on fungus or any faction with the Xenoempathy dome project. Native units could become relatively more valuable if they were able to use fungus as roads even in enemy territory.

This rule could make land-based probe actions a little harder but I'm not sure if that's a negative thing at all. Basically any kind of new rule could be implemented if the movement cost function is rewritten.

[BFG]

That is indeed an interesting idea, but I have to admit, I'm generally not in favor of adding new gameplay rules / tweaks that are outside the bounds of what could happen within the vanilla game.  I'd rather focus on improving the AI / behavior of what's already there.

I could certainly see that becoming an option in Yitzi's patch, however.

[Induktio]

Yeah, there is indeed an argument against changing game mechanics in a significant extent due to the way players are used to playing this game. There's a bunch of ideas that could be implemented, but at this point of development it's kinda unlikely I would add many drastic changes to the game mechanics. At least if stuff like this gets added it should have a configuration option. AI improvement is still the main goal here anyway.

[PvtHudson]

+1 for road movement rule experiment. Fungus movement unchanged.

[bvanevery]

-1.  You will split the rather small player base into different groups.  Whatever is the default will get testing coverage.  Whatever is not the default, won't get the coverage.  In the less tested group, in the real world there will be bugs aplenty.  I say this having played Freeciv for many years.

What you're proposing is known as "mission creep" in industry.  It may be a sign that you're getting bored of the project you're working on and really want to do something else.  With your programming skills, I would strongly encourage you to work on a new 4X TBS game, that you personally can make money from.  Rather than trying to turn SMAC into something other than what it is, as though messing with a  binary is an easy thing to keep bug free.

There are wild bugs in the pathfinding already.  Units that just go in nonsensical directions because borders and enemy units are in the way.  Particularly in the case of non-combat units.  When someone proposes to really tear up the behavior of the pathfinding code, I say gee, what can possibly go wrong?

[dino]

Magtubes allow to snowball through enemy picking with overwhelming force severeal bases one by one in a single turn, so at least a rule to treat magtubes as roads on enemy territory should help AI with defense.
Not being able to use enemy magtubes also makes sense from simulationist pow.
With roads, I'd consider making them cost 1/2 movement points on enemy territory, not being able to use them at all would be too much of gimp for assault forces.

Depends, how much it'd take to do and how much you like this feature, you can be the only judge. I'd certainly try it if it was made.
The mod is singleplayer focused, as long as it's optional no consensus among the players is necessary imo.
If we were concerned about "fracturing community", than by this logic no one should make any txt rules editing either.


The other modding feature, that could be really useful in improving game balance, would an option to change [1,2,3,4] reactor constants in unit hit points and cost formulas.
Both are already identified in the code, so unless it's impossible to use floats as these exponent values, should be doable.

I'd suggest just implementing two separate tables of four values for cost and HP, configurable in thinker.ini
There is no way you would reach consensus about these formulas and yet most experienced players would like them adjusted, so making it completely configurable is the only way.
I personally, if given such a feature, as first experiment would make reactor reduce unit cost, but by a smaller factor and remove HP increase completely.