Micfild

Hi everyone! This seems to be an old post but i got intrigued by the concept of two-gender gatherers. I haven't found the 2-gender citizen mod that people kept talking about so i went and built a little conceptual mod just to see how laborious it would be. I attached the results. I only did it for the Spartans though (since its conceptual). As a whole, the game already has everything it need to implement this (no new art or animation required, well, maybe for the unit portrait icon). As for the question of visibility (distinguishing soldiers from gatherers), it's already very hard to do it by sight alone, and much easier to just area select and work with the unit icons. Also, alt+area select already selects only soldiers (and i believe there is also one for only gatherers, but i can't remember right now). Have fun everyone! Male_gatherer_concept.zip

Thanks @Stan` and @Freagarach, it was in cost.js, as you said. Line 16 of the script, change the schema from nonNegativeInteger to decimal did the trick (it doesn't accept nonNegativeDecimal - not a valid datatype). Although the decimal values don't show on the cost card of the unit, it does show and work perfectly on the resource panel at the top of the screen. In this image, women costs 1.5 pop. https://i.imgur.com/qORPVcW.jpeg Thanks once more.

Hi! It was creating a mod to test a few things and tried to set the population value of a unit to a decimal number (i.e. 1 --> 1.5). As expected, the game didn't like that one bit XD. I was wondering, can it be done? Would it be trivial or complex (like, in a scale of changing a line or changing several scripts)? I'm just curious. Thanks.

Is that the 1866 mod that you mentioned before or something else?

Hi! If it is of any interest, i've found that if you copy the <melee> attack of a spearman.xml and add it to a javelineer.xml file it will show on the ui, but the javelineer will still only use it's ranged attack. However, if you change the <PreferredClasses datatype="tokens"> of that <melee> attack from "Human" to "Structure", when you order those Javelineers to attack a structure, they will use the melee attack instead of the ranged one. I even changed the damage of the melee attack to something stupid like 250 Hack just to be sure that it wasn't using the damage values of the ranged attack. I might be wrong, but this small experiment leads me to believe that it might be possible to implement the secondary attack mechanic by making use of this preference thing. Also, i found in the component Attack.js a GetBestAttackAgainst function (lines 343 to 378), that draws a distinction between Slaughter, Capture and other forms of attack. I don't know if this function is used or not since i haven't found another reference to it, but it might be possible to add more distinctions to it (maybe even one based on distance between units and stuff). I don't know if this will help but, who knows?

Thank you for the clarification Nagasushi. The smaller range of the javelin cav caught me by surprise, but your reasoning seems perfectly correct so i'll experiment with them a bit more. I've been playing with the Iberians lately and i was used to the cheaper Javelin cav with high mobility, range and damage output. It used to counter spears quite effectively, since 30 meters is quite a long range, given the cav's high mobility. Now that i know their intended purpose i can fit them better in my army. Also i do understand now why they have 150 HP instead of the usual 100. As for the ranged units, i found it interesting that you added a minimum range to them, so they can't fight melee battles and have to constantly retreat in order to fire. I also noted that javelin infantry has higher pierce armor (5) than archers (1), i guess to justify their lower range. As for the Elephants, i'm pretty sure they didn't receive armory upgrades before your mod, but i'll double check just to be sure. I wasn't playing on medium. i put it on hard (if it makes any difference). But its been loads of fun. The AI doesn't slack and keeps sending wave after wave at one point, mixing army compositions, splitting forces and even ignoring my attacks sometimes and going straight for my base (giving me a bit of a headache), but i enjoy the challenge. As for attack+move, its all i do, really. I even altered the hotkeys so that "hold ctrl+ right click" doesn't focus buildings, only units. Nevertheless, this is a great mod. Great job! EDIT 1: You were correct. The Elephants receive armory upgrades in the base game as well.

I would also like to add that elephants seems a bit OP. Usually they can't receive armor upgrades, but it seems that in this mod they can. This means that during a late game conflict with the Mauryas i was facing 1300HP elephants with 11 hack armor and 8-9 pierce armor, so they might need a little bit of tuning down.

Hello Nagasushi. I've tried you mod. So far, it's loads of fun. The new AI is a beast at macro (in comparison to petra). I have been playing it at Balaced + Hard and couldn't beat it yet. The pathing seems nice and i like the movement upgrade for infantry. The ranged units seem a bit weird though. Most have 2.2-2.7 attack interval and high damage, but the javelin cavalry has only 7 range. Was that intentional? Javelin infantry has 30 range and bow cav has 50 range so why javeling cav only has 7 range? Nevertheless, it is a fun mod!

Well, units will take time to produce and then move to the opponents base so the counterattack will have to start with only the surviving units. Also, since those units will also have to move there first, it gives time to the opponent to rebuild some units. it is as you say. It's hard to consider all situations and of course there will be some that makes attacking be less risky. Having banked resources, being near the opponent, only trying to harass instead of a full on clash, etc will have an impact on the results. That is also why i don't think looting (as it is currently implemented) is such an snowballing mechanic. It's effects are so meagre that it's hardly felt (as was also pointed out). Agreed, but that also means that your opponent will have an easier time repelling it. (Just to be clear, I'm not advocating in favor of all-ins, i just want to point out the issues the attacking force will have to deal with). Agreed, but at that time, the loot bonus kind of becomes inconsequential (since you'll probably already have enough resources or infrastructure to comfortably rebuild such). I was trying to focus on specific moments where the loot bonus can make a difference (even if its a small one). 0AD is indeed a nuanced game and as you point out, your mere presence near the enemy base might inflict some economical damage without the need to fight. But then again, in those cases, loot doesn't factor in so it kind of detours from the point of this discussion.

I always thought that loot was a fair mechanic (if not a bit underwhelming). The situation I'm considering is this. If you are the agressor, that means that you have to move your army from your base to the enemy base and that takes time. Time that you're not collecting resources with said army and time your enemy is collecting resources with his. So to attack, you're basically accepting the risk that you'll fall behind in economy. Secondly, you'll probably meet the enemy in their own territory, where they could have static defense (like turrets) and base layouts that will benefit the defender, giving him a greater advantage while fighting your army. Also, he is in reinforcement range, which means he can continuously boost his forces while the fight is going on, while your reinforcements (if any) will have to come all the way from your base. There is an argument that using horses or mercenaries to attack, instead of citizen-infantry, could lessen the economic loss of having your workforce go to war. The problem is that horses are more expensive than infantry and can only gather food (so they are less useful to have in comparison to infantry in an economic sense), while mercenaries can't gather resources and cost large amounts of metal (which might slow down your technological advancement). In case the agressor loses the fight, then the loot he gathered can actually help him rebuild, offsetting a small amount of the costs of going to war (which can be considered a feature to limit the potential snowball the defender will have). If the agressor manages to stalemate or even win the fight then his advantage will be great (well, depending on how convincingly he won) and that is to his merit. After all, attack is already a huge risk with no guarantees. ============================ As for loot being a sort of hidden feature, i do agree that it could use a bit more visibility. To that end i have a suggestion. Since loot is small per unit we could have some sort of artificial (hidden) bank that starts collecting loot when the fight starts. After X seconds of no combat, the bank will dump all the respective looted resources on the players, probably with a satisfying sound like a "ting". If you want to make it more visual, you could always have the number of resources looted appear as a notification to the player.

A Quick Introduction Hello Everyone! Since this is my first post on the 0AD forums, i would like to start with a quick introduction. I've come to know about 0AD quite recently and been playing it since May 2021 (single-player). I have played quite a few RTSs already (namely Age of Empires II, Age of Mythology, Warcraft 3 and StarCraft), but this was the first game that i ever saw a Batch Training mechanic and i love it! Fun aside though, i also started doing some tests to try and use this mechanic to it's fullest potential. In this regard, 0AD sets itself apart from those other games i mentioned because it is an Open Source Project so I could go through the code more easily to unearth the formulas, modifiers, etc in order to make my analyses. So without further ado, let's do some math! The Mechanic Unveiled First things first: How is Batch Training implemented? As far as resource costs and population growth is concerned, there are no changes, but training time (for each individual unit) is greatly reduced using the following formula: BatchTime = BaseTime * (#Units ^ Mod) Where: BaseTime = The time it takes to train a single unit #Units = The size of the group Mod = Modifier, a value that is intrinsic to the Building Type and determines the reduction in Training Time. List of Modifiers: Houses: 1.0 (meaning, Batch training in houses does not reduce training times) Corral, Market, Siege Workshop, Elephant Stable, Special Buildings: 0.7 Barrack, Stable, Fortress, Civic Centre, Carthage Embassies: 0.8 Let's illustrate this with an example: Unit: Spartan Hoplite – From Civic Center (Mod: 0.8) BaseTime = 10 secs #Units 1 by 1 - Time (s) Batched Time (s) 2 20 17.41 3 30 24.08 4 40 30.31 5 50 36.24 So, as seen in the exemple above, Batch Training reduces the training time of units considerably and, on the surface, it appears to be always better to Batch train instead of training 1by1. However there is a tradeoff. You'll only have said units at the end of the entire Training period (which is longer than the time to train a single unit). What this means is that 1by1 will give you readily available units sooner, but in smaller quantities, while Batching will give you readily available units later, but in larger quantities. This is a point to consider, specially in the early game, where we want to gather resources as fast as possible to build up our economy and our army. If we call the amount of time a unit is out on the map ActiveTime (as in it can perform actions such as move, gather, fight, etc), we can say that the method that gives us more ActiveTime overall will be better. Analysis Let's use our Spartan Hoplite to understand this problem. Spartan Hoplite – From Civic Center (Mod: 0.8) BaseTime = 10 secs Let's say we train 2 units using both methods: From our table we gather that 1by1 will produce a unit after 10 secs and another after 10 more seconds, while batching will produce 2 units after 17.41 secs. This means that both methods don't generate any ActiveTime in the first 10 seconds (since no units are out yet) and will start generating the same amount after 20 secs (when the second unit of 1by1 gets done). So what we can compare is the amount of ActiveTime generated after 10 secs but before 20, for both methods. Do note that each unit out on the map generates 1 sec of ActiveTime for each in-game second. This means that 2 units will generate 2 secs for each in-game second and so on. With that in mind we can do the calculations and reach the following table: #Units = 2 Time Elapsed (s) 1 by 1 Batching #Units Produced ActiveTime(s) #Units Produced ActiveTime(s) 0 0 0 0 0 10 1 0 0 0 17.41 1 7.41 2 0 20 2 10 2 5.18 #Units = 3 Time Elapsed (s) 1 by 1 Batching #Units Produced ActiveTime(s) #Units Produced ActiveTime(s) 0 0 0 0 0 10 1 0 0 0 20 2 10 0 0 24.08 2 18.16 3 0 30 3 30 3 17.76 #Units = 4 Time Elapsed (s) 1 by 1 Batching #Units Produced Total ActiveTime (s) #Units Produced Total ActiveTime(s) 0 0 0 0 0 10 1 0 0 0 20 2 10 0 0 30 3 30 0 0 30.31 3 30.93 4 0 40 4 60 4 38.76 As we can see, although batching reached the total amount of units faster than 1by1, that amount of Active time generated in the same period heavily favors 1by1. Now let's see if this trend continues and calculate the percentages to see by how much 1 by 1 is beating Batching. # Units 1 by 1 Batching Percentage (%) Total ActiveTime (s) Total ActiveTime(s) 2 10 5.18 51.8 3 30 17.75 59.17 4 60 38.74 64.57 5 100 68.81 68.81 6 150 108.42 72.28 7 210 157.97 75.22 8 280 217.76 77.77 9 360 288.04 80.01 10 450 369.04 82.01 27 3510 3519.02 100.26 Interesting! As we increase the amount of units trained, Batching slowly catches up to 1 by1 and by the time we reach 27 units, Batching will match 1by1 in Total ActiveTime generated. We can also see that any number of units above 27, Batching will start becoming more and more efficient. Naturally, 27 units costs an unfeasible amount of resources and time (specially in the early game) so we can conclude that by our metric of ActiveTime 1by1 is by far more productive than any amount of batching we can get in the early game. Conscription In the City Phase (last phase) we get access to the Conscription technology (in the barracks and the Stable). This technology lowers the Batch Training modifiers by 10% (Mod = 0.8 to Mod: 0.7) and that is a huge change. Lets do the same calculation, but now with Mod = 0.7. # Units 1 by 1 Batching Percentage (%) Total ActiveTime (s) Total ActiveTime(s) 2 10 7.51 75.10 3 30 25.27 84.23 4 60 54.44 90.73 5 100 95.74 95.74 6 150 149.69 99.79 7 210 216.68 103.18 This means that in the late game (after researching Conscription), given enough resources, any Batch amount > 6 will be more efficient than training 1by1. That is also valid for all the buildings that naturally have Mod = 0.7. Discussion So, the main question that arises from this analysis is: Is the Batch mechanic useless in the early game? My answer is NO and here is my reasoning. THE GOOD: - Batching is great for early game rushes and timing attacks: since we'll be able to pump units much faster that by building 1by1 and we can't afford to build multiple barracks or stables in the early game. - Batching is great for dumping excess resources: Stockpiling resources isn't advisable, since resources don't produce anything while sitting in the bank. Unfortunately it happens sometimes, so if we find yourselves with excess Food, we can just build a Stable and Batch train some horses to explore the map and harass our opponent. - Batching gives options instead on limiting them: If Batching was universally better than 1by1 then there would be no point in having having a choice. By having it's drawbacks, Batching gives more variety to the game by enabling certain strategies. THE BAD: - Batching is less flexible than 1by1: By Batching, we sink a lot of resources and have to wait a considerable amount of time for them to bear fruits. This means that if we need to cancel some of our productions in other to gather resources to build an upgrade or advance phases, the amount of time lost training that group can be great. - Batching eats a lot of population: Population is also a resource. So if we want to Batch train a large group we need to have space available. Also, we'll need to quickly build houses to open more space to not get capped and keep producing out of our other buildings. THE UGLY: - Batching is eclipsed by 1by1 for economy: Since much of our goals in the early game is to boost our economy as fast as possible (and we do that by maximizing ActiveTime), batching does the exact opposite of what it's expected of it. And now in A25, the introduction of the Autoqueue mechanic basically kills batching even more for early game economy. Closing Remarks Well, that's basically all i had to say about the subject. I hope this post wasn't too boring and you were able to enjoy it. I would also like to read your opinions and comments on the matter. If you agreed or disagree with this analysis and why? Any concerns or constructive criticisms are always welcome. See you on the forums and have fun! ===================================//================================== TL;DR (just in case) Which is more efficient in the early game: training in batches or training units 1by1? Well, 1by1 will give you readily available units sooner, but in smaller quantities, while Batching will give you readily available units later, but in larger quantities. By comparing the Total ActiveTime (the amount of time a unit is on the map, ready to move, gather, fight, etc) in both approaches, we get: - From the Barracks, Stable or Civic Center: 1by1 is more efficient if the batch size is smaller than 27. Since batches of 27 are basically impossible in the early game, for economy purposes, 1by1 if far better than any amount of batching. -Batching is better than 1by1 in strategies involving rushes or timing attacks. ==================================================================== EDIT 1: So, considering what @Jofursloft and @Freagarach have said in the their posts, i redid the calculations for batching and 1by1 considering more productions cycles and the ProgressTimeout delay that autoqueue gives. To avoid making this post bigger than it already is, i placed the the calculations and the result tables in the attached pdf. In general, smaller batches (2 to 3 units) break even with 1by1 by the 3rd production cycle, while bigger batches (5 and upwards) break even by the second production cycle. Things are a bit less efficient if you use autoqueue, but not by much. So, as long as you can batch units constantly, batching will always be better than 1by1. Also, the bigger the batch size, the better. Batching Revisited.pdf