proGUI, the day after

[alre]

3 hours ago, Atrik said:

With the advantage that the player itself (and not an artificial intelligent trainer) chooses the type of units to train by clicking on icons (or associated hotkeys)

well progui is a bit like that (but not too intelligent) because it works on a logic that makes it choose which unit to train based on army composition specifications. I would actually like mentula's solution better because I would enjoy retaining control on which barracks trains which unit.

at that point a gui mod that makes you keep track on production (exactly like boongui always did) would be a nice option for those who want to improve their game without any automation.

[alre]

or maybe we should drop batch training completely but I don't quite dare proposing that.

[Atrik]

1 hour ago, alre said:

would actually like mentula's solution better because I would enjoy retaining control on which barracks trains which unit.

You can already do that in progui by enabling vanilla auto-queue in a barrack. It will still resize the batch if the trainer is on, and remember to train that unit while it can. If you do this in 2 barracks and have 5, the 3 without auto-queue enable will probably be enough balance to your compo.

Also misquoted, I didn't say anything sounding with "an artificial intelligent trainer", I was going to express that at the contrary progui solve this:

Quote

that building produces the meaningful maximum amount of units that available resources allow. I'm not doing the math here to define what meaningful means. This is an attempt to formulate the concept, and details can be adjusted later.

by being not intelligent and use user inputs on the panel. How would you solve this otherwise anyway? This is why I repeated a few times that, in my experience, it's harder then one can think to do a resizable auto-queue in vanilla version, because if you don't control it, it's a unplayable nightmare.

The experiment with the mod I did to resize auto-queue proves the point, where barracks that consume all wood or even too much of your stone can be frustrating. You want to be able to put on hold everything or define the amount of resource not to consume, hence progui panel.
This is what I mean by limitations that Mentula's proposal would bring. You could always do an algorithm to define batch size accounting for what the player will need for other means but then it's actually "more auto" then progui.

Edited June 19, 2023 by Atrik

[BreakfastBurrito_007]

I'm against all macros, so the "solution" I am most in favor of is no solution at all.

[Atrik]

1 hour ago, BreakfastBurrito_007 said:

I'm against all macros, so the "solution" I am most in favor of is no solution at all.

I think we were discussing gui features, for example I don't think you consider formations macros, but it's running much more code then something that will resize batch size. My guess is that you'd want the gui to features to be alike the "Age Of" and stay as is. This would be a very reasonable opinion tbh. Still the gui could have some better feature for managing production.

I used to play with just a modified boongui overlay. I had nothing auto, but I could see and select idle buildings very fast, and set the batches manually, it was also already solving my issue with having to find the building for which auto-queue broke. I'm sure for example implementing in vanilla idle building icon like the idle units could still look useful for players with your UI preferences.

Edited June 20, 2023 by Atrik

[Mentula]

Some numbers from experimental data

I made an experiment to quantify the advantage provided by the proGUI trainer to economy. Technical details below. It turns out that -within the context of the settings below- I could reach the population cap 24 seconds earlier with proGUI (on average). On top of that, I could gather additional 1.14K resources with proGUI (on average).

Experiment details (conditions, fairness, biases)

Spoiler

1. Dataset

Dataset consists of 10 games, 5 with proGUI (with QuickStart enabled), 5 without proGUI (with QuickStart mod enabled). Replays are attached to this post.

2. Conditions

In all games, settings are: population cap: 200, initial resources: 300, map: mainland with temperate biome, opponent: Petra sandbox (so that no military action ever occurs), civilization: Gauls.

3. Bias reduction/removal

• Games are played in alternating order (proGUI, no proGUI, etc..) -> to reduce the impact of habits and muscle memory.
• Games are played in sequence: no other game has been played between one game and the successive -> to reduce the impact of short-term memory arising from different play styles.
• Focus on economy only -> to remove fight, rushes and other military actions that can alter economy.
• No economy/other technology researched -> to reduce the variance arising from late or early research.
• No extra food gathered (berries, hunt) -> to reduce the impact of random map generation.
• Equal number of production buildings -> to impose same conditions on production capacity.
• Equal number of fields and food gatherers -> for comparable conditions.
• Equal population composition: only one type of military unit is trained after reaching ~65 female citizens -> for comparable conditions.
• Equal equipment (computer, mouse, screen, etc...) and equal user.cfg/local.cfg configuration files -> for comparable conditions.
• No cherry-picking: all games played for this experiment contribute to final result. Find them attached -> to remove arbitrary selection.

4. Possible existing biases

• I have not played any competitive game with boonGUI or proGUI. Adaptation to the new interface and the new training system could in principle have had a negative impact on games with proGUI, in favor of games without proGUI, which is the setting I am more familiar with. It is possible that a higher familiarity with proGUI affects the edge in favor of proGUI.
• I used my mod bundle (all mods here) in the non-proGUI games. Although QuickStart is the only mod whose functionalities have an impact on the games, a more familiar setting could in principle have boosted the economy in favor of games without proGUI. It is possible that the absence of the mod bundle affects the edge in favor of proGUI.
• After having observed other players whose economy was boosted by proGUI, I could have been influenced by previous knowledge. Besides my assurance that I tried to act as fair as possible, this bias cannot be removed and can in principle affect the economy of one setting in favor of the other, although it's not evidently clear which of the two.

Conclusion

Results from experiments under comparable conditions show that -in my case- the economy of games with the proGUI trainer enabled is boosted by a non-negligible factor. The fact that both the population and the amount of collected resources are better with proGUI can be decisive in a game.

I foresee objections of having forgot this and that. Please remember that 1. this is just data, anybody can produce more data to fit different settings 2. 0 A.D. is a game based on public information: other measurements -even on other players- can be taken and shared. Whether we use a particular mod or not, the information we share as a community, via replays, is public and visible. In other words, a player who does not use proGUI have the same means to evaluate the impact of proGUI on other players [with a rough comparison: one does not have to be alcoholic to measure the effect of alcohol on others]. So any data or thought from any user is welcome and shall not be minimized, regardless of the mods they use.

I will put a link to this post in the first post of this thread for future reference.

10_replays_Mentula_20_06_2023.zip

[alre]

48 minutes ago, Mentula said:

I foresee objections of having forgot this and that.

this made me laugh, your analysis is perfect. If you added a chart, I'd have you published.

[Atrik]

Interesting.
And you had only 2 productions buildings to manage. The edge it probably provides is expected to noticeably grows with the number of buildings.

Your sample looks serious enough for this kind of experiment but very surprised from the results.

Since you don't have much edge cases in your boom in these experiments (and that you train only 1 type of unit and you don't actively manage production variables),  you could have exactly the same performances if you used the resize queue mod I cited earlier. (Will do the exact same thing: training batch using same forumla and at the same moment).

[BreakfastBurrito_007]

@Mentula Very interesting results. I would expect the auto-batching to be quite powerful economically, because the only reason not to use autoqueue as it is in a26 is that when you have 1-by-1 training you can start to float resources, which causes the economic return rate advantage of smaller batches (ie 1 by 1) to be offset by the negative economic effect of having unspent resources. With automatically scaling batch sizes, you can ensure that you are using up your resources while ensuring 0 idle time, all while not paying attention to the barracks.

Earlier we were discussing the unfair advantage purely from the standpoint of focusing more on military, but considering that it causes a faster boom even in non-combat situations is really concerning. Obviously for testing purposes you have to isolate the economic effect, but it is important to keep in mind the compounding effect that increased military focus would have on the advantage of proGUI.