Reward for Killing Units
-
@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>or
<attachment name="objectiveAttachmentConfederateLeadership100" attachTo="Confederate" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <option name="destroyedTUV" value="allRounds" count="[100...100...2000]"/> </attachment> -
@CrazyG
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.
-
@Cernel
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).
-
@cernel
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.
-
@crazyg said in Reward for Killing Units:
@cernel
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.
-
@cernel
You can give sea zones owners.Command goes to whoever has more units, which would be much better than just skipping all yields.
-
@crazyg said in Reward for Killing Units:
Command goes to whoever has more units
Whoever has more TUV.
-
@alkexr
Thank for clarifying
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login