TUV for Units That Have consumesUnits Property

Cernel

@redrum While this would appear as the most obvious solution, and surely some better than current, it is not that good, instead, for all a series of reasons I'll see to get around detailing. So, you should really go the way @CrazyG suggests, instead:

@CrazyG said in TUV for Units That Have consumesUnits Property:

I'll put an idea out there, make a "TUV" unit attachment.

This would let players set the TUV of a unit consumer higher, while having other uses as well.

Also, if this gets done, please have the AI not upgrading units having such a TUV set lower than the consumed unit, as currently the AI just blindly upgrades anything it can, when you give it the units to do so (I'm making a map in which you get some upgrade stuff, but you are meant not using most; so the AI always upgrading all is much worse there than if it never would).

But, yes, in TWW battleships should be worth 22 PUs, and it is annoying / silly you lower your TUV by 2 if you upgrade a hull to a battleship, plus the battlecalculator / AI related issues. So my suggestion is to go with something like that, but also with what @CrazyG is saying (default to the above if the tuv is not specified).

Frostion

@Cernel Can the AI purchase and place units that consumes other units when placed? I thought the AI could not handle this?

Cernel

@Frostion No. But the AI places every upgrades it can, if it has them (like if you give it them with triggers).
This implies that if you make a map in which you receive upgrades and have to decide if you want to use them, the AI can't play that map, especially if you are supposed to not use most.
So, what I was saying, since I don't believe that he AI will be ever able to decide if he wants to swap (upgrade) one unit for another for free, by comparing the units before and after the upgrade, and decide what it prefers to have, I was giving the suggestion that, if an option for specifying the TUV gets made, the AI should just blindly upgrade everything that has TUV higher than the consumed units and not upgrade what has TUV equal or lower than the consumed unit (better than the current behaviour of upgrading all).
That was really just a side note.

redrum

@Frostion I believe the AI won't purchase units that consumes others but if given them by trigger will still try to place them if possible.

@Cernel So I do hope to eventually support logic to determine when the AI should and shouldn't purchase/place units the consume others. Not sure I necessary agree that never placing them is better than always trying to place them if possible. But we are starting to get off topic here.

Overall, I tend to agree with the suggestion on a unit attachment parameter as well. Most likely I'll look to fix the default first though then add a parameter that could be used to override default TUV of a unit.

Cernel

@redrum Definitely always placing is better than never placing. What I was saying is that if there is a TUV parameter, then the fixed behaviour may be improved to always placing if the new unit has higher assigned TUV than the consumed one and never placing if it is not. Again, this was a related side note.

redrum

@Cernel Ah ok. I see what you mean now and that makes sense. I would essentially let map makers mark the TUV of certain units that consumes others lower in order to avoid having the AI place them.

CrazyG

@redrum
That is another reason I wanted to be able to set TUV per unit. Its let map maker manipulate the AI into making better decisions

Cernel

Ok, I said I would have done it, so here it is:

Having the TUV being the sum of the cost of the unit plus the cost of other units that unit consumed is an improvement but has some limits, that make preferable allowing the mapmaker to tell what is the TUV, exactly, namely:

We cannot assume that the upgrade process is necessarily a straight and mandatory production process, in which we intend to reach the final unit since the start. It may be used as a way to convert a unit into something else, not even necessarily something absolutely better or superior, or you may have units that are exactly the same, in term of what they do (thus their actual value), but differ in that are produced in different steps, and the final TUV would differ.
The normal example is WWII Global, in which you have "factory_upgrade" and "factory_major". They are the same (I don't know and I've never even played Global, please anyone correct me if I'm wrong) but factory_upgrade costs 20 and upgrades factory_minor, that costs 12. Thus the TUV would be 32, but it should rather be 30; the same as what a factory_major would cost, if simply placed.
On the other hand, you may have a custom map in which you can decide to produce a factory fast at a higher price or do it in two steps at a lower total price; you would have two factory units that are worth the same, but having different TUV. Rather better both being set to the TUV of the one-step one (especially from the point of view of another player capturing any of them, if they are worth the same).
You may have a map that allows you to produce a carrier or convert a battleship into a carrier_upgrade, while both the carrier and the carrier_upgrade being just the same, thus better having the same TUV (likely, in this case, the "carrier_upgrade" should have a set TUV equal to the "carrier"). Of course, they both might be upgrades, as you might be required to get a hull or something, for the normal "carrier". Maybe the "carrier_upgrade" should even have a lower TUV than the "battleship" it consumes (surely realistic). Or maybe you want to be able to produce "auxiliary_carrier" directly or upgrading a "transport"; probably better them having the same TUV, if these units are different for no other thing but whence they came from.
You may have units that have the upgrade being absolutely worse than the consumed unit.
Aside from madness, this can be used as representing a deliberate scorched heart policy, in which you can "upgrade" "Factory" to "Factory_demolished", if you think it is going to fall into enemy hands. Maybe this process might imply a small "demolition" cost, thus the "Factory_demolished" would end up being valued more than the "Factory". Of course, this would imply that we intend "Factory_demolished" being definitively so, because, if we want to be able to upgrade back to "Factory_something", we would end up in an infinite loop of infinite units needed to infinitely upgrade and downgrade them back an forth (probably we would just do something with triggers, about that, or use user actions).
Probably here the AI should just avoid ever doing it (thus a TUV setting and the AI never upgrading units to other ones that have a lower TUV set).
You can buy resources, not only units. Buying resources using other resources is kind of the same concept as placing a unit consuming another unit.
A TUV setting would allow to cover that case too; otherwise it would need to be accounted too, for completeness.
You may have units that upgrade in multiple steps. This is just a notice in case you intended to look only at the direct upgrades. Either this should be extended to sum up the all the consumed units of the consumed units, or letting the mapmaker making the math and telling the TUV.
An example may be having "keel" to "hull" to "battleship". And maybe during each of those steps we also consume other things, like units "steel" or whatever. And maybe any of those units required some other resources than PUs. And maybe these other resources than PUs were bought by spending PUs. I guess all this can be somehow supported, but probably letting the mapmaker do the math would be feasible the most.
But if we count the consumed units of the consumed units, with potentially no end (as per the above point), you may have units that upgrade units they are the upgrade of, thus being able to keep switching between one and the other, depending on what you need; in this case, if you count all, as per the above point, you will end up having infinite TUV.
For example, you may have a map that automatically gives you "infantry", like with a trigger chance roll that adds infantry units depending on whatever, or maybe with user actions, but you are also able to deliberately upgrade "infantry" to "cavalry" (cavalry consumes infantry when placed) and upgrade "cavalry" back to "infantry" (infantry consumes cavalry when placed), thus managing your armed forces (maybe cavalry is better but has an higher upkeep cost).
I've never actually tried to do something like that, and I guess it is nothing envisioned; this is mostly just a warning, in case. It would be just needed that the TUV stops to be summed up as soon as you get to a unit that you already accounted.
There are a number of other cases in which the TUV is not representative, beside the case of consumed units, and it would probably be not that feasible to go after them all. So it might be argued going after none of them at all, comprising the consumed units one, and just have a setting and let the mapmaker sort any of them out.
I believe the most important case, for the basic maps, is the "Shipyard" tech, that makes the TUV of your ships to sink, just because they are now cheaper, but it may be argued that both the old and the new ships you have should refer to their normal TUV, not the one just lowered by the "Shipyard" tech.
You may have different players buying a same unit at different costs, and a mapmaker may prefer rather using the same TUV for all, or maybe not (a setting would allow to choose).

With this said, I agree that having units in which all the upgrades till the last one is representing a normal production process, like the one for producing a "battleship" in Total World War, is the best referring situation (even tho this is not what WWII Global does, where the upgrade is an alternative less efficient way to get the same thing as a factory_major), thus what you suggest would be surely an improvement (not really an improvement for WWII Global, beside lowering the spread, from a -10 to a +2).
I would really like seeing this getting done, as well, actually, if summing up the consumed units is an easy fix, as if you have a "castle" unit that consumes a "building_castle" unit, it would be really better the TUV being the sum of those, and it is annoying it is not (it kind of defeat almost totally the purpose of the TUV in Stats).
I think the main item that should be assured is that, if this is done, it applies for all consumed units of consumed units as well, as in the case of "keel" to "hull" to "battleship" made above (counting "keel" + "hull" + "battleship"; not just "hull" + "battleship").

Definitely, having the TUV sinking by 2 when you upgrade a hull to a battleship, at cost +10, is not an acceptable behaviour. I'm sure everyone can only agree, here. It really kills the point of seeing the TUV in stats at all, and it is annoying.

Actually, as a related note, I think that the case of "Global" of having different units for the "factory_major" and "factory_upgrade" is just wrong and sort of not the right way to go, especially considering that they look exactly the same and we would be prompted to place both if we click on a territory having a "factory_minor" and allowing for placing either. If they are just the same unit produced in two different ways, they should rather be one and the same unit, really.
If a Global player can confirm that I'm not misunderstanding anything (I've never played global and barely know it), I would rather suggest having a property that instantly turns "factory_upgrade" into "factory_major" right upon placement (thus you would have only a same "factory_major" unit placed in two different ways, as it seems it is the case (please, correct me if I'm wrong)).
Such property would also cover the need for a specified TUV because, say, then a mapmaker could make a "battleship" unit costing 22 PUs that is never actually bought or present in any frontiers, but it is automatically created when you place the 10 PUs "battleship_upgrade", consuming the "hull". I'm not actually sure if this would be the preferable way to go, so to support both current main cases the same way (the Global factory_upgrade and the TWW battleship)? This would allow for managing any upgrades the same way and would remove both the need of having to count all the consumed units of upgrades and having the ability to set a TUV for the unit, plus it would allow to support same units that are produced in different ways, beside only the upgrade versus one-step case of the major factory of Global (say, being able to place a same unit at different costs, depending where you place it, and many other cases).

redrum

@Cernel said in TUV for Units That Have consumesUnits Property:

But if we count the consumed units of the consumed units, with potentially no end (as per the above point), you may have units that upgrade units they are the upgrade of, thus being able to keep switching between one and the other, depending on what you need; in this case, if you count all, as per the above point, you will end up having infinite TUV.

Are there any example maps that do this? I'm tackling this feature right now and wanted to see if we have any test maps.

Cernel

@redrum said in TUV for Units That Have consumesUnits Property:

@Cernel said in TUV for Units That Have consumesUnits Property:

But if we count the consumed units of the consumed units, with potentially no end (as per the above point), you may have units that upgrade units they are the upgrade of, thus being able to keep switching between one and the other, depending on what you need; in this case, if you count all, as per the above point, you will end up having infinite TUV.

Are there any example maps that do this? I'm tackling this feature right now and wanted to see if we have any test maps.

I don't know. I guess not.

Do you want me (or someone) to make a simple mod of something having that behaviour, to test it out?

redrum

@Cernel That would be very helpful. Making sure to include some edge case scenarios such as 2 units switching back and forth by consuming each other and even a larger cycle of 3-4 units that consume each other (swordsman -> knight -> archer -> swordsman*) . The other scenario I thought of is that you can have multiple consumeUnits lines so end up with a large tree like structure if you have multiple levels instead of just "keel" to "hull" to "battleship" think "battleship" requires "hull" and "gun" which then each require multiple things.

Cernel

@redrum Well, that doesn't sound like simple, and also considering that you are doing the stuff now I will see to do something still simple but partially covering what you are saying.

Cernel

@redrum said in TUV for Units That Have consumesUnits Property:

The other scenario I thought of is that you can have multiple consumeUnits lines so end up with a large tree like structure if you have multiple levels instead of just "keel" to "hull" to "battleship" think "battleship" requires "hull" and "gun" which then each require multiple things.

Since currently you can only consume stuff in the same territory, that would require the "gun" to be a sea or air unit. If the engine would be expanded to consume units on land to place on sea, that would become more of a case, so I guess it makes sense to take it into consideration.

Frostion

I hope that the final solution to this improvement of the AI will enable/motivate it to upgrades factory units, besides combat units. Like for example village to town (Dragon War map), Factory to Advanced Factory and does the Roman period maps not also have upgradeable factories? My point: Don't forget to give production ability a value.

redrum

Initial changes added to pre-release to address #1: https://github.com/triplea-game/triplea/pull/2268. Please test and let me know if you find any issues. Seems to work fine on both Global 40 and TWW.

prastle

@redrum could you have a look at the gitter q/a and see if any of those errors are worth taking to github?

https://gitter.im/triplea-game/QA

redrum

The change to add the tuv option for UnitAttachment is now in the pre-release as well: https://github.com/triplea-game/triplea/pull/2276

Example:
<attachment name="unitAttachment" attachTo="germanBattleship" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="movement" value="2"/>
<option name="attack" value="7"/>
<option name="defense" value="8"/>
<option name="isSea" value="true"/>
<option name="tuv" value="25"/>
</attachment>

Cernel

@redrum I believe (or at least I've a strong feeling) the "tuv" option should not belong to the unitAttachments, but rather to the productionRules.

Example:
<productionRule name="buyFusiliers">
<cost resource="PUs" quantity="8"/>
<value resourceOrUnit="Fusiliers" quantity="8"/>
<result resourceOrUnit="Fusiliers" quantity="1"/>
</productionRule>

(the value would refer to a single "Fusiliers", no matter the number in the "result")

Also, it can be taken into account the possible need of assigning different values for different players for the same unit. This would not be possible if this is a unit option.

It is important to be considered that you can have different values for different players for the same unit (think about Shipyard tech or different frontiers, like in the case of Napoleonic Empires, with UnitedKingdom having cheaper costs for Encampment and General).

This may matter also for the necessity of valuing units that cannot be bought. For example, in "Napoleonic Empires" there is the "Capital" unit. The "Capital" unit is exactly the same thing as the "Encampment" unit, thus it would be reasonable the most to assign the "Capital" (you can't buy) a value equal to 10 (same as the Encampment), which is already possible (the "Capital" has currently value 15, that I believe should be changed to 10). However, the Encampment costs 8 for the UnitedKingdom; so it would be advisable that, either, for consistency:

The "Capital" is valued 8 for UnitedKingdom only.
The "Encampment" is valued 10 for UnitedKingdom too, despite costing only 8, for it.

This depends if we intend the TUV to represent what we believe it is a value of the unit or to represent the actual costs.

I tend to believe that 1 is more consistent. In the moment in which if we get JetPower, the TUV doesn't increase, despite now the unit having more value for that player than the others, then it makes sense that, in the moment in which we get Shipyard, the TUV decreases by the costs, despite the unit having still the same value for everyone.

For point 1, I think this would be better achieved by assigning, in the "productionFrontier", a productionRule that is meant to assign the value only, and it doesn't show up at all in the production window. I'm thinking of something like:

That you then assign in:

<productionFrontier name="productionUnitedKingdom">
<frontierRules name="buyCapitalUnitedKingdom"/>
...

Since having no "result" it won't be displayed, but will serve just to tell the game to value the "Capital" unit owned by the UnitedKingdom at 8.

Cernel

In particular, if we would go with the "TUV" being a unit option (but I feel strongly it is not the right place for it), thus forcing the same value for any players, then it would be almost a necessity to allow for relating it to the technology, and maybe even support, because, in the moment you say that a same unit must absolutely have the same "statistic" value for everyone, then if a tech makes it better for a player only, it would make the only sense that the value for that player increases.

The matter is still deciding if, with the "TUV", we mean to capture the supposed value of the unit or we merely intend to report the sum of their current costs.

We may also consider having separate "TUV" and "TUC", so that, for example, in the moment in which a player gets "Shipyard", the "TUC" decreases but the "TUV" remains the same, while, in the moment in which a player gets "SuperSubs", the "TUC" remains the same but the "TUV" increases (of course, in this case, we would need to define a separate value for a submarine benefitting from the SuperSub tech, higher than the normal value assigned to the same unit).

Cernel

The matter if the TUV should represent strictly the sum of the current costs or should be used to picture a total estimated value has been discussed already in this Feature Request ticket:

https://sourceforge.net/p/triplea/feature-requests/216/

I believe, in the moment in which you put a "TUV" option inside the unitAttachments, thus forcing it to be the same for any players having that unit, you are going in the direction of the "TUV" being meant to represent the value, which would be a change of direction from the past, that may be good or bad, but has to be pondered, and preferably made consistent amongst games and dynamics.