Handling of AI players not meant to be played - Github request.

Hepps

@Frostion Makes sense especially given how you have used AI players in some of your games.

redrum

@Frostion Mostly agree and planning to do changes like this with the AI bonus rework so you're in luck

Responses:

Yes. Not sure why this wasn't done a while ago instead of the "AI" prefix name hack.
2/3. I think this is a good idea though I'm tempted to argue that it should just be a single option that does both remove player from selection and economy/stats tabs as I think these go hand and hand.

redrum

@Frostion Also the long term vision is to only have 1 AI (remove both easy and fast). This would require making hard AI much faster on large maps though.

redrum

@Frostion Since I strongly agree with points #1 and #2, here is the PR implementing them: https://github.com/triplea-game/triplea/pull/1824

Add 2 new game.xml player attributes:

isDefaultAI - defaults to false, if true then sets player selection dropdown to Hard AI (replaces "AI" name prefix)
isNonPlayable - defaults to false, if true sets player to Hard AI and doesn't display player on player selection screen as it isn't meant to be played

Example:
<player name="Pro-Axis-Neutral" optional="true" isDefaultAI="true" isNonPlayable="true"/>

Note: if you set isNonPlayable="true" then you technically don't need isDefaultAI="true"

Frostion

Nice! I hope you devs can make a small XML edit to PoS2.xml when this goes live.

Cernel

@redrum
I really don't like the "isNonPlayable" definition, as it is really not clear what it means. If it can be played by AI, then it is playable, as the AI is a player too, just not a human one.
Also, I suggest changing "isDefaultAI" to "isAIDefault". The first one sounds not correct, as it would mean that player is assigned to the Default AI (meaning to the AI that is the default one amongst the various AI, currently Hard AI), and can be played by nothing else but the Default AI, while the second definition would mean, in my mind, more correctly, that the player is assigned to the AI as Default.

Probably better its own property for hiding stuff from stats. Mapmakers might decide to have players that they want to be forcefully assigned to AI, but have some reasons for appearing in stats. Conversely, you might want even purely passive players to display how much to grab they have left. You may also consider allowing for having the stats of the Neutral player, if the mapmaker wants to.

Final note, did you consider what to do for bots, not having AI? If there is a not selectable player with phases, like some minor players Frostion maps style, the game will just not proceed, at that point?

And, yes, I agree with all that Frostion said.

redrum

So I think I'm going to rename the properties to:

isAIDefault
isHidden

This shouldn't affect bots at all (they would still be shown as human players).

Cernel

@redrum
So, so. "isHidden" feels a bit vague to me, and it is not making clear that player would be AI too (one might think it gets just disabled). I didn't give an alternate suggestion, as I couldn't really figure something really telling.
But doesn't it feel a bit weird having the "isHidden" forcing it being "isAIDefault" too? I suggest "isHidden" doing nothing else but to hide it, meaning that "isHidden" would still keep the player assigned to the normal default (the one hosting the game, in a private host), unless the mapmaker also set "isAIDefault" true. It is true that you probably want to almost always have "isAIDefault" true for all players having "isHidden" true, but you should consider that here we are talking of a functionality to be set by mapmakers, not by regular users, so straight coding and simpler functionality should be preferred over bundling stuff just because it makes the only sense (it can be expected the mapmakers to take care not to forget to assign "isAIDefault" as correctly intended; no need to force).
Moreover, I can see some borderline cases in which you might want "isHidden" without "isAIDefault", for example a passive player that is supposed by rules to take casualties in a specific way, not supported by the AI (so, the player hosting the game would make the work of taking out casualties correctly, like you would when playing a boardgame, without a robot doing it), or if you have purely utility players meant just to somewhat setup the game at the start of it, like the "GameSetup" player of "FeudalJapan" (it might make the most sense it not showing, but being assigned to the hoster, just like it is the hoster to define Map Options before firing up).
But I agree that all uses of an "isHidden" player being not "isAIDefault" would be either strange or hackish; so the main reason I would not force is just to keep it clean code-wise, as I trust the map makers can just take care themselves to set both true, when needed (and it can be written in pos2 to take care to set "isAIDefault" true for any players having "isHidden" true, when such players are not supposed to be played by any human). This is just my personal preference of keeping the functionalities straght and simple, even in the case when having one means you almost surely want another too. If you prefer forcing, then I suggest you still keep it simple, and just make the game crash if a player is "isHidden" true but "isAIDefault" false; this is how the code normally works. For example, if you give an air-only ability like "isStrategicBomber", or something, to something that it is not air, it doesn't automatically turn that unit into an air unit, but it just makes the game crash, because not compatible.

Will the "AI" and "Neutral" at the start of the name be kept being supported as a way to set "isAIDefault" true? If yes, deprecated or fully supported?

Cernel

Otherwise I guess maybe calling it "isAIHidden".

redrum

I've decided to go with:

isAIDefault
isHidden

And make it so "isHidden" just controls whether the player is shown not making the AI default as it does make the properties more straightforward.

Prefixing names with "AI" and "Neutral" will no longer be supported as it was really a hack in the first place. We'll need to work to update any popular maps that used these once this is released.

In general, using hacky prefixes or suffixes on strings is something we want to move away from. If there are others please open an issue so we can look to create proper attributes for them.

Frostion

@redrum
Sounds sweet! I don't know how many maps use the AI prefix, but many, if not all, my 7 maps do. So I would really like if it was announced when a new stable TripleA goes live and when the XML should be updated and how to do this. I would just need a 24 hours notice I guess. If I update my XMLs to soon, then they will not work right when folks download, right?

redrum

@Frostion Yeah, we won't want to update any maps til we release the next stable.

redrum

The PR to address the first 2 points is now merged and can be tested in the pre-release.

redrum

@Cernel @Frostion So I thought a little more about this and realized we should probably have the option to set the default player to "Does Nothing AI" as well.

So instead of:
isAIDefault="true"

Something like:
defaultPlayer="AI" or defaultPlayer="DoesNothing"

Thoughts?

Frostion

@redrum I have never used the does nothing AI for anything else then testing, as a way to get through the player list quickly to the point where I can take control of a specific player.

But maybe your idea is good for any future versions of AI players? Like AggressiveAI, AirFocusedAI, MindlessAI? Just a thought

Cernel

@redrum
Beside testing, I only use does nothing in FFA as a quitter substitute. It also automatically accepts anything, and this is a behaviour that was set (by veqryn) after I requested it, for lost FFA players (initially, it used to refuse everything, which is the behaviour for unused players, but not really good when you want to turn some player passive in a FFA).
I don't actually know why Does Nothing does an initial placement, instead of actually doing nothing.
In TripleA, "Player" means the in-game one, not the one playing it, that it is the PlayerType, thus:

playerTypeDefault="Does Nothing"
playerTypeDefault="AI"
playerTypeDefault="Human"

Default to "Human" if not set.

As said, my only problem with "Does Nothing" is that it does an initial placement instead of actually doing nothing, and this is a bit confusing and I don't get it. I'm not sure if maybe this was intended by Veqryn for Risk?

Cernel

@Cernel
Basically, what I was saying, is that the most important gaming use I see for "Does Nothing" is when you play 3+ sides games and one or more of the players quit and they get turned to "Does Nothing" (that also accepts anything). Of course, this is of no relevance in 2 sides games, since they just end when one quits.

redrum

@Cernel So TWW is an example of where "Does Nothing" is used for neutral nations. @Zjelcop Put in a feature request a while back requesting that as well: https://github.com/triplea-game/triplea/issues/457

Hepps

@redrum I was going to say something....

If I remember correctly Do nothing buys... but does not move at all.

Cernel

@Hepps It buys and it places but it also destroys all income, which implies that, normally, it can buy only on the first turn of the game for that player. I don't actually know what this behaviour is for; I suggest asking Veqryn in GitHub (as he doesn't read here).
As said, myself, beside testing, I only ever use Does Nothing for do what it says, assigning it to players of quitters in FFA (if we don't want to turn quitters to an actual AI, which I'm tendentially against to, for FFA meant not to be played with AI, to start with).

@redrum I would take that issue out of "ice box", based on the new directives, as it looks like this topic is on it.