Reward for Killing Units
I've noticed that the game already tracks "destroyedTUV"; it is available as an option for triggers or national objectives. Its a cool feature that currently has the options for both current round only and all rounds to date.
I'm looking to add a resource which you receive as a reward for fighting, and I was thinking that this would be a useful place to start. I can already do something like this:
<attachment name="conditionAttachmentVeteranIncome" attachTo="Germany" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
<option name="destroyedTUV" value="currentRound" count="100"/>
And then a trigger that gives you a resource, named Military Experience. You can use this resource to buy special units. I'm seeing a couple challenges (basically I don't want to write 100 million triggers just for this one feature) and want to ask if others have ideas how to address them.
If I use "allRounds", I have to write an enormous amount of triggers to make sure I have enough to last all game.
If I use "currentRound", I get rounding problems. If you kill 99 TUV, you get nothing. I could lower to amount to reduce the rounding problems (I think its okay if there are small rounding losses) but then the number of conditions starts to get really long again.
So my question for the community, are there existing maps that use this idea? Have you ever experimented with it? Any ideas how to achieve this effect with fewer triggers?
@crazyg You probably want to look at Civil War as it uses destroyedTUV for 'leadership' resource.
I took a look, its exactly what I was going to create. I was just hoping there was a way to do it with fewer lines. The thing is, Civil War only has 2 players and a round limit. I'm looking to make this for an eight player map that in theory could go forever. It would be good design to have the triggers that last a long time.
Basically the problem is that I want to be lazy and not write that many
@alkexr The game starts to sensibly suffer when having around 50,000 triggers in the xml or more; especially starting an online game becomes really slow, particularly multiplayer: you can have to wait several minutes.
Just saying that even if you can spam unlimited quantity of triggers that doesn't mean you are really unbounded.
EDIT: Actually, instead of 50,000 triggers, read 50,000 conditions. If you have triggers that test for a lot of conditions, directly or indirectly, that is as slow as having a lot of mono-condition triggers.
@cernel The solution to this problem is obvious, but of course it's not going to happen.
When TripleA started out as a computer version of Axies and Allies, there were only minor variations allowed between different versions, and you only needed to specify a few values. So an xml format was chosen for the game data, and this was perfectly reasonable. But I hope I don't have to elaborate that TripleA has grown a lot since then. We have new and ambitious maps, testing the limits of what is possible, coming up with more and more interesting and novel ideas. If someone were to choose a format for game data without having a knowledge of TripleA's past, they would never choose xml. Some sort of script language would be needed.
So the problem in short is that we have reached the limits of the flexibility of the xml format. I'm not saying it is useless... but it doesn't serve our needs. I also won't comment on just how much work would be needed to switch from xml to something else. So you have to adapt... and not create rules you would like, but create rules that are possible. Constrained creativity has its beauty, too.
Yea I'm looking at like 1,000 conditions and triggers per nation to do this. I normally would procedurally generate this with excel, with having that many conditions really slows things down and makes the XML really lengthy (this alone will be longer than the rest of my XML combined)
Just wanted to see what ideas people had
@alkexr Yeah, generally that would be the solution. I don't think XML is necessary the limitation even though it probably isn't the best format as you could have script like abilities within it. I think for the most part, we just need to look to expand the XML parsing capabilities of TripleA to be able to handle some basic scripting concepts like variables/formulas and loops.
For this particular case, the ability to define something like "every 100 TUV" gives "1 experience" is what is needed.
So taking something like CW as an example:
<attachment name="objectiveAttachmentConfederateLeadership100" attachTo="Confederate" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <option name="destroyedTUV" value="allRounds" count="100"/> </attachment> <attachment name="objectiveAttachmentConfederateLeadership200" attachTo="Confederate" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <option name="destroyedTUV" value="allRounds" count="200"/> </attachment> ...
Would become something like:
<attachment name="objectiveAttachmentConfederateLeadership100" attachTo="Confederate" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <option name="destroyedTUV" value="allRounds" count="100*X"/> </attachment>
<attachment name="objectiveAttachmentConfederateLeadership100" attachTo="Confederate" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <option name="destroyedTUV" value="allRounds" count="[100...100...2000]"/> </attachment>
I have recently thought about something similar.
In my next map I would really like to have single units be able to somehow advance in veterancy, like if a single unit could go from normal to veteran and veteran to elite. It would be very cool if this would happen if the unit survived a battle where the starting TUV was in the enemy’s favor. Or if the single unit just killed off many enemies
But I can’t see how the above could be done, and I always fall back to an “XP” or “Veterans” resource that could be used to buy unit upgrades to place on old units, or be used to buy totally new veteran units.
@frostion Looks like there is a group of us contemplating the same thing.
@redrum If we are adding variables and formulas, let's do it in a way that won't result in a constant need for patching and worrying about breaking compatibility for the rest of history.
I'd like if you can test the TUV swing, instead of only the destroyed TUV of the defender. My main problem with this bonus for enemy TUV destruction is that it works only for the attacker, so it traduces itself into an hardly acceptable increase in complexity. Normally, you can simply guess if a battle is good to take by looking at the TUV swing, while, with something like "you get 1 PUs per every 4 enemy TUV you destroy", or such, you would need to look at the TUV swing, look at the defender TUV or units left, calculate the defender TUV destruction (in case the battle is not 100% or you don't intend to finish the defender off or there are significantly limited combat rounds), calculate how much you are getting out of it (even more complex if you are getting something else but PUs), and then adding it up to your TUV swing and see if a negative TUV swing would be actually positive, all considered. Really too much stuff, unless resources gain for enemy TUV destruction is directly supported by the program and calculated by the battlecalculator, as well, giving you the final stats.
The solution to this would be being able to test the TUV swing, instead of the defender destroyed TUV, since the other solution of having the defender too gaining from the attacker TUV destruction is not feasible, as you can have multi players defence.
The main problem is when you are the defender, and need calculating if your stacks are safe (normally you just need to take care the TUV swing for the attacker is negative). Adding a cumulative TUV destruction reward rule is a huge increase in complexity, especially for FFA.
I thought destroyedTUV included units killed while defending (this should be made clear in the PoS2 XML). It really should include this if possible
@crazyg That was added (by Veqryn) to encourage people to attack at all in FFA. It was just meant as a substitute to diplomacy related bonuses, because people would just fake wars, while never actually attacking. Practically a check that you are actively at war, not just formally.
So, if TUV destruction bonuses would count the same way for attacker and defender, the increase in complexity would be fairly bearable, as it would be a not distortive amplifier, and I would most likely use such a feature, as well, especially for FFA. The problem with that, as I said, is who is getting the bonus, or how to share it, in defence, when you have multiplayer defenders (and remember that with FFA you can have multiplayer defenders that are at war with each other).
I do recall reading that thread. I had an idea to use this for free for all. I was going to make a science heavy game (like age of tribes) and your main source of science would be killing enemies. This is an actually powerful incentive to fight (Veq's idea encouraged fake wars)
Whoever is the casualty selector is the one who would get credit for the kills when defending. Occasionally you do get weird results when a territory is French owned but defended by British units, but the mechanic is easily understood. Its not perfect but it does the job.
I don't think it being so weird in a fringe free for all scenario with multiple defenders is a reason not to use it.
I do recall reading that thread.
We might be the only 2 superstites.
Whoever is the casualty selector is the one who would get credit for the kills when defending.
This is probably the cleanest solution for territories, if anyone will code it. As long as you have a territory, the selector is the owner. However, sea zones usually aren't territories and, in that case, you would not even know who is going to defend, and it would be very unfair for it to get the bonus, based on substantially nothing.
I'd rather go with the territory owner getting the bonus, and nobody getting any if no owner or null.
@cernel I want, however, to point out that the selector being the owner (even in case not having units in the battle) is a TripleA invention, that can be even considered a bug. By rules, all the players defending with combat units must agree on casualty selection, and the attacker selects if they don't manage to. Also, I don't know how TripleA decides the selector when the zone has no owner, if a developer can tell.
You can give sea zones owners.
Command goes to whoever has more units, which would be much better than just skipping all yields.