Batch Training (The Good, The Bad and The Ugly)

[Micfild]

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

Edited September 19, 2021 by Micfild
New information to be added

[wowgetoffyourcellphone]

wfgbot, nominate this post for post of the week

[Jofursloft]

I think that when talking about mathematics related to a game like 0ad there are 2 things needed: a good knowledge of math and a good experience in the gameplay. Fortunately I have both. Here you make 1 mistake for each:

• You are considering the case in which we train in batches but you analyze with charts only the first batch. Let's consider the first example in the chart you did (the one with 2 units). What you have to consider is that after 20 seconds 1 by 1 training method seems the to be the most efficient. But you have to consider that the player will continue to train units in batches, which resolves to the following conclusion: 

Time Elapsed (s)	1 by 1		Batching
	#Units Produced	ActiveTime(s)	#Units Produced	ActiveTime(s)
20 40 160 (2 mins 40 secs)	2 4 16	10 30+20+10=60 ...	2 4 18	5.18 25.18*2 + 5.18*2=60,72 ...

As you can see, after another 20 seconds the batch training method does way better than 1by1 for what concerns Active time. After 2 mins and 40 secs it's 2 units ahead. Obviously the gap of speed between 1by1 and batch training method becomes more evident when you apply the same logic I did with higher batch training numbers. 

• You need to have more experience in the game. 1) Even if there is not a definite rule about it, for early game is not intended only the first minute of playing (wouldn't make sense) but something like the first 12 mins of playing. In these 12 minutes, the gap of speed in terms of economic development between 1by1 training and batch training methods becomes huge. 2) A good player never uses the same batch dimensions but variates it (when I train women in the beginning of the game I like to train them 6+3+2+4+4). 3) You can build houses while training in batches without being slowed down (just manage the correct number of wood you are collecting).

In any case, I would suggest you to spectate a pro level match. You will notice that by using the batch training method it's possible to get easily 100 population within 7 minutes, and reach 150 within 10 minutes. 

Edited August 24, 2021 by Jofursloft

[Freagarach]

On 24/08/2021 at 7:53 AM, Micfild said:

And now in A25, the introduction of the Autoqueue mechanic basically kills batching even more for early game economy.

(Bear in mind that the AutoQueue is artificially made less efficient and one loses 0.2 seconds (i.e. one turn) after each entity/batch has been produced while the AutoQueue is on.)

See corrected post below.

Edited August 31, 2021 by Freagarach
Strike wrong info.

[chrstgtr]

25 minutes ago, Freagarach said:

(Bear in mind that the AutoQueue is artificially made less efficient and one loses 0.2 seconds (i.e. one turn) after each entity/batch has been produced while the AutoQueue is on.)

I'm not sure I understand. Does this mean that each unit/batch effectively take .2 seconds longer when made with auto queue compared to when it is manually done? 

[LetswaveaBook]

1 hour ago, Micfild said:

BatchTime = BaseTime * (#Units ^ Mod)

I knew batch training made it more efficiently, but never knew the formula. Whenever I tried to do some analysis on batch training, I just looked in game for what it would look like. So great that you have found the formula.

@Jofursloft Batch training is more efficient if you have the resources for it, but you are conveniently ignoring the costs. For a civilization with barracks of 200 wood and 100 stone and a build time of 150 seconds, I use in my following calculations a cost a 300 resources. Now that means if you look 1 barrack training units 1 by 1, you need are faced with the costs of the barracks and the units that are in the queue (100 resources per unit), which I represent here by a total cost of 400 resources. If we look at 1 barrack batch training 2 units, then we are faced with a cost of 300+2*100.

So a more fair comparison would be comparing 3 barracks with training 1 by 1 (cost=1200) vs. 2 barracks with a batch size of 3 (cost=1200). In this case the 3 barracks training 1 by 1 perform better. If you want 2 barracks to produce as many as 3, you need to have queued in each barrack 7 units. So I think having more barracks has some merit for booming.

[hyperion]

3 minutes ago, chrstgtr said:

I'm not sure I understand. Does this mean that each unit/batch effectively take .2 seconds longer when made with auto queue compared to when it is manually done? 

No, batches take the same time to train but there is a pause of one turn before autotrain adds a new batch to the effective queue. If you manually add batches they go directly to the effective queue and so the 0.2s gap doesn't happen.

[chrstgtr]

24 minutes ago, hyperion said:

No, batches take the same time to train but there is a pause of one turn before autotrain adds a new batch to the effective queue. If you manually add batches they go directly to the effective queue and so the 0.2s gap doesn't happen.

But that's effectively the same thing, right? 

[hyperion]

Just now, chrstgtr said:

But that's effectively the same thing, right? 

0.2s is indeed so little that you could say it's effectively the same thing. Still it's a penalty nonetheless, and if needed, could be adjusted.

[seeh]

i batch in a25 working exactly like in a24 ? my test in a24 https://wildfiregames.com/forum/topic/23562-batch-training/?tab=comments#comment-422069

Edited August 24, 2021 by seeh

[Freagarach]

1 hour ago, Freagarach said:

one loses 0.2 seconds (i.e. one turn)

Sorry, I have to correct myself here. After adding a new batch to the queue, the structure waits one progress_timeout, which is 1 second before starting the next item, be it manually added or by the AutoQueue.

[alre]

I made some test and training 6 spearmen takes 1 minute, either with manual queuing and with autoqueue. that time is effectively 6 times the individual training time.

maybe some very slight difference may have slipped from my attention, but I'm quite convinced that autoqueue is not inefficient compared to manual queuing.

[Stan`]

One could add a debug in production queue to see how often it gets called in practise

[Freagarach]

8 minutes ago, alre said:

I made some test and training 6 spearmen takes 1 minute, either with manual queuing and with autoqueue. that time is effectively 6 times the individual training time.

maybe some very slight difference may have slipped from my attention, but I'm quite convinced that autoqueue is not inefficient compared to manual queuing.

Try with a batch of two entities instead of one (the difference is that with the batch there is not an integer amounts of seconds training time).

Easy way:

1. Make two production structures and give them control groups 1 and 2.
2. Pause the match.
3. Select 1: enable AQ, Make one batch of two entities.
4. Select 2: Make e.g. ten batches of two entities.
5. Unpause the match.
6. Select both structures and watch them go out of sync.

 

[alre]

ok ok. I did test that, and the results once again confuse me: after 5 batches (of 2 men) manual queuing had gained 2/3 seconds over autoqueing already, after 10 batches, there was more than 6 seconds of a distance.

if it was just due to autoqueue waiting to the end of the 0.2s turn, it should have been less than 2 seconds after 10 batches.

Edited August 24, 2021 by alre

[Freagarach]

https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/ProductionQueue.js#L775
So what happens is that on a progresstimeout (called once every 1000 ms) that time (1000 ms) is allocated to the queue. The time needed for an item is then subtracted from that allocated time until there is no more time left, then it will be repeated on the next timeout. When an entity finishes being produced and there is still allocated time left, that is taken from the next item in the queue. However, when AQ is on, it will just ditch the remaining time and wait for the next timeout.

Example: An entity costs 5.6 time to produce. After five timeouts, both queues (with and without AQ) have 0.6 seconds left. The first entity in the row is finished on both queues on the next timeout. The rest 0.4 seconds (1 second allocated time minus the 0.6 it costs to finish the entity) will be discarded by the AQ queue, but will be used by the other queue to start on the next item. That means that after 6 timeouts (== seconds game time), the AQ queue will have 5.6 seconds left for its second entity whilst the normal queue has only 5.2 seconds left.

I hope this clarifies it a bit. Else, feel free to keep asking!

26 minutes ago, alre said:

of the 0.2s turn

I was wrong there, as I noted earlier, the PQ isn't updated on each turn, but on progress_timeout (which is 1 second).

[Player of 0AD]

I just tested and saw no autoqueu penalty whatsoever. Good, because such a thing would be bad

[Player of 0AD]

Missed opportunity: Writing in the title "The good, the batch and the ugly" ;-)

[Stan`]

Might be more visible when game is laggy?

[alre]

1 hour ago, Freagarach said:

https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/ProductionQueue.js#L775
So what happens is that on a progresstimeout (called once every 1000 ms) that time (1000 ms) is allocated to the queue. The time needed for an item is then subtracted from that allocated time until there is no more time left, then it will be repeated on the next timeout. When an entity finishes being produced and there is still allocated time left, that is taken from the next item in the queue. However, when AQ is on, it will just ditch the remaining time and wait for the next timeout.

Example: An entity costs 5.6 time to produce. After five timeouts, both queues (with and without AQ) have 0.6 seconds left. The first entity in the row is finished on both queues on the next timeout. The rest 0.4 seconds (1 second allocated time minus the 0.6 it costs to finish the entity) will be discarded by the AQ queue, but will be used by the other queue to start on the next item. That means that after 6 timeouts (== seconds game time), the AQ queue will have 5.6 seconds left for its second entity whilst the normal queue has only 5.2 seconds left.

I hope this clarifies it a bit. Else, feel free to keep asking!

I was wrong there, as I noted earlier, the PQ isn't updated on each turn, but on progress_timeout (which is 1 second).

ok, thanks, now it's clearer. this means in practice that with autoqueue training times are rounded up to the nearest second, right?

[Marbod]

Since unit batch training was introduced i followed one simple rule.

1. Single training for eco

2. Batch training for military usage (champs, healers and citizens whose only purpose was to train up exp for war)

Done.

[alre]

On 25/08/2021 at 3:37 AM, Marbod said:

Since unit batch training was introduced i followed one simple rule.

1. Single training for eco

2. Batch training for military usage (champs, healers and citizens whose only purpose was to train up exp for war)

Done.

that's more or less the opposite of what I do: 

- biggest possible batches for eco, split among all production buildings I got.

- also batch production for military, unless destined to a fight that's already ongoing, in that case single unit spam.

[BreakfastBurrito_007]

15 minutes ago, alre said:

also batch production for military, unless destined to a fight that's already ongoing, in that case single unit spam

Be careful when doing this, because sometimes if you are losing the fight and your troops are still trickling in, then you run the risk of throwing away units.

[Ceres]

On 24/08/2021 at 9:14 AM, hyperion said:

No, batches take the same time to train but there is a pause of one turn before autotrain adds a new batch to the effective queue. If you manually add batches they go directly to the effective queue and so the 0.2s gap doesn't happen.

Does this mean that you can explore something while auto-queuing is enabled? I never tested this and cannot do so right now, hence my question.

[Marbod]

On 24/08/2021 at 8:28 AM, Jofursloft said:

I think that when talking about mathematics related to a game like 0ad there are 2 things needed: a good knowledge of math and a good experience in the gameplay. Fortunately I have both. Here you make 1 mistake for each:

• You are considering the case in which we train in batches but you analyze with charts only the first batch. Let's consider the first example in the chart you did (the one with 2 units). What you have to consider is that after 20 seconds 1 by 1 training method seems the to be the most efficient. But you have to consider that the player will continue to train units in batches, which resolves to the following conclusion: 

Time Elapsed (s)	1 by 1		Batching
	#Units Produced	ActiveTime(s)	#Units Produced	ActiveTime(s)
20 40 160 (2 mins 40 secs)	2 4 16	10 30+20+10=60 ...	2 4 18	5.18 25.18*2 + 5.18*2=60,72 ...

As you can see, after another 20 seconds the batch training method does way better than 1by1 for what concerns Active time. After 2 mins and 40 secs it's 2 units ahead. Obviously the gap of speed between 1by1 and batch training method becomes more evident when you apply the same logic I did with higher batch training numbers. 

• You need to have more experience in the game. 1) Even if there is not a definite rule about it, for early game is not intended only the first minute of playing (wouldn't make sense) but something like the first 12 mins of playing. In these 12 minutes, the gap of speed in terms of economic development between 1by1 training and batch training methods becomes huge. 2) A good player never uses the same batch dimensions but variates it (when I train women in the beginning of the game I like to train them 6+3+2+4+4). 3) You can build houses while training in batches without being slowed down (just manage the correct number of wood you are collecting).

In any case, I would suggest you to spectate a pro level match. You will notice that by using the batch training method it's possible to get easily 100 population within 7 minutes, and reach 150 within 10 minutes. 

Somehow i did not read this part of the postings. That means i was sure that 1by1 is good for eco but batches only for military training if not only at high 25+ numbers like the first post. Now i see why this is wrong. Although i only play vs AI and i have no a player vs player expertise, i am happy because to handle batches (i do mostly steps by 5 now, 5 early, and 10 or 15 later if bank is huge and i am at the end game) is also much more convinient to control.

Thank you for doing the math.

Time for batching