Unit efficiency and availability analysis by unit category and civilization [udpated for A25]

[hyiltiz]

Here it is:
https://hyiltiz.github.io/0ad-unit-analysis/

It shows 3 tables:
- a table for all template units that shows the specs of a generic unit, e.g. a Cav Archer;
- a table for Civ specific changes from the generic template unit;
- a table for unit availability for all generic template units for each of the Civs

Let me know if you have any specific ideas for improvements, preferably at #0ad-dev but I might check back here too. PRs are very welcome too!

Story

I wanted to work on something like this, and @Stan pointed out to me in #0ad that there is already a script in the repo at ./source/tools/templatesanalyzer/unitTables.py. Unfortunately, the script hasn't been updated substantly since 2014 and the script simply threw an error when I tried to run on the latest version of the game (A26, more specifically, the trunk r26182). I forked the directory so I can keep my commits small and with a specific theme to facilitate merge and auditing, as well as to publish it in Github so anyone can view it online without having to deal with SVN, HTML, JS, Python etc. As such, note that the majority of the program logic, design and program is NOT my own; it is based on previous work of fatherbush, Itms, scythetwir, wraitii and others(?). I will be trying to getting this merged into 0ad main repo soon.

The idea of Mixins (like unit tags, e.g. hoplites who can use Phalanx formation) were introduced since this script was originally written, and currently I have not found a good way to represent them as part of the table, except just listing these Mixin tags as a list in a separate column. But that would be barely useful, so Mixin types are omitted at the moment.

Edited January 9, 2022 by hyiltiz

[wowgetoffyourcellphone]

7 hours ago, hyiltiz said:

https://hyiltiz.github.io/0ad-unit-analysis/

 

Funny how the /only/ attack bonus in the game is against Cavalry, held by no less than 9 parent templates.

[Player of 0AD]

2 hours ago, wowgetoffyourcellphone said:

Funny how the /only/ attack bonus in the game is against Cavalry, held by no less than 9 parent templates.

Wrong. Alexander the great has an attack bonus against heroes.

The game doesn't lack additional forms of attack boni, it's fine

Edited January 9, 2022 by Player of 0AD

[wowgetoffyourcellphone]

9 minutes ago, Player of 0AD said:

Wrong. Alexander the great has an attack bonus against heroes.

The game doesn't lack traditional forms of attack boni, it's fine

9 parent templates have an attack bonus vs. 1 class, while 1 specific template has a bonus against heroes. There. Still notable and probably worth discussing why this is so and why it should remain so. It may indicate a problem with the class that has 9 hard counters to it.

Edited January 9, 2022 by wowgetoffyourcellphone

[Silier]

Yeah, but they all use spear or pike

[Yekaterina]

This table needs to be revised:

1. Change the colour code pls

2. Re-count the number of each units in A25. There are some wrong numbers e.g number of Roman sword infs. Sometimes the template file for an unit exists but that unit is not trainable in actual games for balancing reasons, so be sure to check the structure tree instead of the templates folder.

3. Athenian column is empty and there is a gaia column for whatever reason

 

Otherwise well done!
 

Edited January 10, 2022 by Yekaterina

[Yekaterina]

 

Please note that gladiators cannot be trained!

Spartan Skiritai are actually a child of template_infantry_melee_swordsman and not a champion unit, even though its name is 'champion'.

 

[hyiltiz]

Thank you all for all the feedback and criticism! Keep it coming!

Yes, the final table is incorrect: Gaia and Athens is swap due to a slightly complicated code logic (mixins based on multiple inheritance), which is easy to fix for now (just swap them) but to be an actual future-proof fix, there needs to be some substantial rework on the parser. That might come later.

@Yekaterina I used different shades of green to be color blind friendly; the previously used red/green/black coloring made it not obvious that they were all label availability of unit to different degree. I welcome any graphics design suggestions and CSS. BTW, loved your guide and love watching your replays. Really happy to see you commenting on my stuff

I had no idea some units were not trainable; I can look into that and fix it for now. A real future proof solution is in the discussions in #ad-0dev as well (come hang out :D); namely, let the pyro do the parsing then export valid units and the traits. Right now, this analysis script is playing mouse and cat with the engine and easily turns into code rot.

On a more detailed and future-proof design

Currently, all the parsing is done based on file names and what the parent property claims in the XML files. However, apparently the real thing is much more complicated at several levels:
- some units are not trainable
- civs may stop being separate XML folders but just mixin categories interpreted via multiple inheritance
- some unit types are misrepresented in file names (like Spartan Skiritai and some Merc units)

As you can see from the git commits, there were some serious overhauls needed for this script to be maintainable, and some non-trivial parsing fixups for it to work. It doesn't even accurately represent how the units actually work in the game right now.

1. - One way to fix that (I am just a noob; I didn't even know the game 2 months ago) is to ask the community (YOU) to tell me what's wrong so I can fix them;
2. - A better future-proof way to fix them is to base the analysis on the results of the pyro engine parsing so I do not have to re-implement parsing the same way the game engine does. Even if I can do that now, that won't stay that way in the future as the engine evolves. To do so, I need to throw away all the parsing work I've done so far and replace it with the game engine parser library result, for which I see three possibilities:
   1. write a thin wrapper around the game engine parser library so it can do all the parsing just like it would do for the game, then export it for me to do the analysis,
   2. add a feature to the pyro engine executable so it can export the game unit stats (e.g. as a JSON) for me to do the analysis. This has an additional benefit of being able to be used by other tools as well since JSON is very accessible; also poses a challenge since pyro needs to be cross-platform compatible and someone who knows enough about C++ cross-platform syscalls and CLI arg parsing has to do the implementation;
   3. re-implement the unit analysis in JavaScript, so these analysis could be available in-game just like the Civ tree as part of the manual.

I think:

• method 1 is relatively easy (only requires work on my part)
• method 2.3 must be most desirable because it will be available in-game, but requires substantial work to port the analysis into JavaScript and some more.
• method 2.1 is non-trivial and not worth the effort
• method 2.2 might be a good middle-ground for now, as well as being a good foundation for 2.3 in the future.

Ideas? Comments? Volunteers?

[hyiltiz]

Fixed the last table so Gaia no longer shows up as stealing Athen's units (due to previously ignored mixin unit categories). This is more of a temporary fix; if a "prototype" unit, like jav cav, shows up in the future as a single unit that belongs to multiple Civs through mixin types each of which define their own skin etc., then this will not hold anymore. But until then...

I need help in figuring out which units show up even though un-trainable; does anyone know if the unit trainability is included inside the unit .xml files?

[wowgetoffyourcellphone]

41 minutes ago, hyiltiz said:

I need help in figuring out which units show up even though un-trainable; does anyone know if the unit trainability is included inside the unit .xml files?

That's the building files, actually.