How does he manage to pull three arrows from his quiver in a single motion, and how does he manage to nock three arrows onto the string at once in a single motion? I'm genuinely curious because it seems to me that it's not that easy for other archers:  

When cutscene mode is enabled, then no, that's kinda the whole point of cutscene mode. When it's not enabled, on other hand, you can, but only to some extent since the HUD (selection panels etc.) is hidden. You can give gather and attack orders, for example, but not train units or research techs. Admittedly, this is a limitation, but it's the best solution I managed come up with, the in-game HUD itself is already pretty cramped in my opinion.   Yeah, as shown in the second half of the demo video, this is possible. Currently, the unit's displayed name (e.g. "Champion Infantry Pikeman") is used in combination with its in-game portrait. Would be possible, though, to extend it to allow customising those too.

On these cuirasses, I think the armor would have gone a little higher over the clavicles. I know the existing ones aren't really consistent on this or are consistently wrong. 

Ah yes, the current body mesh does have some odd distortions. 

Here is my attempt at the question what batch size is optimal for a given maximum time batches are running. I wrote a little script to calculate the total alive time of units, based on the batch time formula in the original post (ignoring the auto-queue rounding at first). Let's start with base training rate 10 and modifier 0.8. Plotting it as a heatmap looks like this This doesn't tell too much yet, as more time means more units have spent more time alive. No surprise here. But you can already see interesting irregularities at the lower end, which hints at that there are optima. So, to make them more visible, I normalize each time step by the 1-by-1 alive time The first 10 time steps are now shown white because it's dividing by 0. The upper right corner is black, because the larger the batch, the longer there is no unit yet to accumulate alive time. Makes sense so far. However, it is still a bit mushy, so to really highlight the optimal batch size for each target time, I apply a softmax. You see the result on the left below (notice these interesting secondary modes). In the right figure, I have included that auto-queue rounds up the batch train time, giving it a more jagged shape.   That jagged behavior is at least nice to determine some optimal batch size values. I'll leave some here for future reference: With auto-queue active, for base rate 10 and modifier 0.8, until about 90s target duration 1-by-1 is optimal (without auto-queue the cross over to batch size 2 is around 59s). Then in short window 90s-102s batch size 2 is optimal, followed by a somewhat longer optimum for batch size 4 at 102s-122s. Interestingly, 3 seems to never be optimal, 5 only very shortly. However, batch size 6 is good 136s-240s, surprisingly versatile! Similarly, batch size 9 is useful 240s-340s. Keep in mind that I used a quite strong inverse temperature for these plots, so if there shows some color means it is already close-to-optimal. Similar to batch size 3, the sizes 7 and 10-12 seem generally useless. For other base rates or modifiers the optima are different. With base rate 8 (laborers), 1-by-1 is optimal up to 46s, batch size 2 for 46-93s, 5 for 94-161s (or even down to 200s), and 7 is useful from 130s down to 260s (though in the shortest and longest times only close-to optimal). Batch sizes 3, 4, 6 and 9 are never good here. For Romans the base rate 9 favors batch sizes 1 up to ~70s, 3 for ~70-140s and 6 for ~125-225. Avoid batch size 4. Longer base rates tend to favor smaller batch sizes (though you don't necessarily wanna maximize alive time with these ones), while a smaller modifier favors larger batch sizes. Here is the plot for base rate 10 and modifier 0.7: The graphs without auto-queue are very similar, but look more smoothly and do not have such batch size preferences. Code is attached to play around yourself  Cheers!   batch.py