Machine Learning for 9th age

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Machine Learning for 9th age

    @JustAGuy @DanT

    Hi everyone!
    Let's move our conversation here from DE thread.

    To perform ML for calculation unit prices the data in table like format (.csv, json...) is required.
    1) stats, special rules and prices of all units
    2) army lists and their results at least for current iteration of rules

    Would you please tell me what data do you have?

    Do you have army books in text format? (I don't really think that parsing pdf files is good idea to grab data from them)

    In which form and format do you gather data for annual price updates?
  • (not commenting in staff role)

    @Just_Flo I think the above tag is intended for you



    @Gerfaks I've been thinking some more about this.
    I think the place where this would be most useful is setting initial prices for the LABs while they are in development.
    This is a big chunk of staff time, and is largely unavoidable, but is a high-scatter process.

    If a ML approach could do this even approximately correctly with low scatter (even if there is a small but non-zero bias), I think (bear in mind I am not a decision maker for this just to be super-clear) this would be a great place to use a ML type product.
    List repository and links HERE
    Basic beginners tactics HERE
    Empire of Dannstahl HERE
  • Not so familiar with machine learning. Is that some kind of: "Put stats and prices of established books here, put stats of new books with unknown point costs here and the machine automatically estimates the price of those new units?"

    The problem I see arising here, is that new books often haven new awsrs, for which the "machine", has no reference for. Such awsrs can heavily interact with the other stats, influencing the price in unpredictable way.
  • If we talk about 1) data (unit stats & rules) as far as I see main problem (apart from gathering data in table format) is coding special rules.

    Obviously we can use one hot encoding for them but it would be cumbersome. Alternatively we could try decompose some of their effects on stats modifiers: Swiftstride change average charge range, Artistry of Death change chances to wound if they are not 83.3%, etc..

    Also to calculate unit effectiveness we probably need extra columns: chances to hit against WS1...WS10, chances to wound against Res1...Res10, chances to pierce armor against Arm1...Arm10, chances to pass Fortitude/Aegis, etc..
  • arwaker wrote:

    Not so familiar with machine learning. Is that some kind of: "Put stats and prices of established books here, put stats of new books with unknown point costs here and the machine automatically estimates the price of those new units?"

    The problem I see arising here, is that new books often haven new awsrs, for which the "machine", has no reference for. Such awsrs can heavily interact with the other stats, influencing the price in unpredictable way.
    Yeap, more or less ML model could be seen as black box: put unit - get price.

    Any rule could be translated to some game effect.
    I agree that some of them is hard to estimate, like for example DE Blades of Darag - it increases chances to wound, but in quite unpredictable manner.
  • I believe that @flammy` can provide directions on how to get stats in a usable format, he uses them for his combat simulator.

    Otherwise the stats are in .Tex files (one per unit), i think you can parse them without great difficulty since every stat is on a line that start with the name of the stat, they are not positional though, once at home i can provide an example.
  • Just_Flo wrote:

    What Kind of data are you looking for?

    Ussage data, performance data, other data?
    If we are talking about army lists and results than: player list, battle results and probably opponent's list.

    Perhaps we can use some analogy with collectible card games and look at win rate of lists subject to inclusion of chosen unit (like win rate of card decks with chosen card).
  • (not commenting in staff role)

    Heads up: I'm not gonna be able to contribute in detail here.

    However, my suggestion to start would be to assume current prices are right, and try to train something like a CNN to match them.

    Focussing too much on tournament data will muddy the waters, and is less relevant for pricing things during the initial LAB process, which is where I think there is more gain to be had from this type of approach.

    It is also a smaller and more well-defined task I think, which is always a better thing to start with :)
    List repository and links HERE
    Basic beginners tactics HERE
    Empire of Dannstahl HERE
  • Maybe starting with a subset of elements might be better for "teaching" the machine and learning how to approach such a task. Maybe start with magic weapons only. Put all rules and prices of established magic weapons in the Blackbox, and try to predict prices for new hypothetical magic weapons. Those new weapons don't need to even exist at all. Just come up with a simple weapon providing +2S and +2A for example. Let the machine do it's trick, predicting the price of this test-weapon.

    When something works on a small scale, it might be worth putting more effort into expanding it to a larger set of components. But I would definitively not start with the 'whole' thing, just to figure out many hours of work later that there is some problem impossible to solve.
  • I'm still wondering what data the algoritm would rely on. Pricing of other LABs and slim books ? That can't really work. Too little data, and how would the algorithm learn how to price a unique rule, or most rule combination, or synergies between units, that are not present in other books?
    Stats are on thing, but how do you plan to feed unique rules to the algorithm for example ?

    I see it more working for iterative pricing, using tournament data, when pricing can rely mostly on usage stats (and simple facts like categories) rather than on the full knowledge of rules.

    HR Team

    ID LAB Coordinator


  • I think I have most/all the data you need in json format in New Recruit for the combat simulator as @Chack mentioned.

    For the effect of weapons it looks like that

    Source Code

    1. "burning_portent": {
    2. "type": "weapon_enchant",
    3. "mod": [
    4. {
    5. "affects": [0],
    6. "rules": [
    7. {
    8. "id": "flaming_attacks"
    9. },
    10. {
    11. "id": "magical_attacks"
    12. },
    13. {
    14. "id": "multiple_wounds",
    15. "params": ["D3"]
    16. }
    17. ],
    18. "stats": {
    19. "AP": "=10"
    20. }
    21. }
    22. ]
    23. },
    24. "symbol_of_slaughter": {
    25. "type": "weapon_enchant",
    26. "mod": [
    27. {
    28. "affects": [0],
    29. "rules": [
    30. {
    31. "id": "magical_attacks"
    32. }
    33. ],
    34. "stats": {
    35. "At": "+2",
    36. "Ag": "+2"
    37. },
    38. "rollmodifiers": {
    39. "to_hit": "+1"
    40. }
    41. }
    42. ]
    43. },
    44. "thriceforged": {
    45. "type": "armour_enchant",
    46. "mod": [
    47. {
    48. "affects": ["defense"],
    49. "stats": {
    50. "Arm": "+3"
    51. }
    52. },
    53. {
    54. "affects": ["defense"],
    55. "stats": {
    56. "Arm": "<5"
    57. },
    58. "conditions": [
    59. {
    60. "hasrule": {
    61. "id": "towering_presence",
    62. "value": true
    63. }
    64. }
    65. ]
    66. }
    67. ]
    68. },
    Display All
    Try out my builder for the 9th age! New Recruit
  • Serwyn wrote:

    I'm still wondering what data the algoritm would rely on. Pricing of other LABs and slim books ? That can't really work. Too little data, and how would the algorithm learn how to price a unique rule, or most rule combination, or synergies between units, that are not present in other books?
    Stats are on thing, but how do you plan to feed unique rules to the algorithm for example ?

    I see it more working for iterative pricing, using tournament data, when pricing can rely mostly on usage stats (and simple facts like categories) rather than on the full knowledge of rules.
    As far as I see there are two possible solutions:
    1) Just use one hot encoding (easy to implement, but cumbersome and wouldn't work for new rules)
    2) Try to decompose special rules in game mechanics: like swift stride increase charge range, lethal strikes increase chances to pass armour, etc (hard to implement and some special rules near impossible to decompose)

    I agree with you that pricing based on tournament data also could work. Perhaps some models based on decision trees or just neural network. We will see.
  • The combat simulator is a tool in New Recruit that allows you to simulate fights between two units from army lists in your roster. You can select the army and the units you want, set up a few settings like the formation of the unit (size of the front rank), who is charging, is there any rear/flank, is it the first round of combat...

    Then you click on the Fight button and New Recruit will simulate a fight between the two units using RNG for the dice rolls. You can choose how many simulations you want to run, typically 500 is good enough for good results in a few seconds. Then New Recruit will display stats about the results: probability of each unit to win the round of combat, average number of losses on each side, average score. The combat simulator aims at taking EVERYTHING into account, be it stat modifiers, special rules, special attacks, weapons, enchants...

    It's still work in progress, a there are a few limitations:
    - The new VS book is not 100% supported yet, some specific special rules have not been implemented.
    - Only 1 round of combat is simulated
    - It is only possible to do 1 vs 1 fights and it's not possible yet to include characters inside a unit (I am still working on this).
    - It is not possible yet to add spell effects though I already added the possibility to add "aura" effects like the freezing aura of a mammoth.

    I sent you a link to download the file in private message (I'd rather not put a link to it on a public forum potentially readable by bots).
    Try out my builder for the 9th age! New Recruit
  • Interesting topic. In my mind it could be a great start to have ‘master’ datasets first:

    all current armybooks stats
    all gathered result information on games (the data team must have this?)

    Id like to make the form as easy as possible and tool agnostic. An example online database would with this info would serve many needs, ranging from maintaining master data (eg a rule or unit stat), to create simple vizual insights in results to performing statistical analysis.
  • Regarding the stats, weapons and rules for each unit:
    I'd recommend parsing the LaTeX files that are used for the slim ABs. No additional step of transferring the rules into the proper format is needed then. And everything is there, includíng unit and base sizes, unit type and height.
    The actual effects of rules and weapons would have to be defined elsewhere, though. But that's probably has to be hard coded for any approach.

    The format is as follows:

    TeX Source Code

    1. \unitentry{%
    2. name=\mongrelherd{},
    3. logo=core,
    4. optionallogo=ambush,
    5. categorynote=\ambushcategorynote{},
    6. cost=140,
    7. unitsize=20,
    8. maxunitsize=50,
    9. costpermodel=8,
    10. scoring=yes,
    11. type=\infantry{},
    12. size=\sizestandard{},
    13. basesize=20\timess{}20,
    14. global@Ad=5,
    15. global@Ma=10,
    16. global@Di=6,
    17. globalrules={\packtactics{},\scoring{},\strider{\forest}},
    18. defense@HP=1,
    19. defense@Df=3,
    20. defense@Re=3,
    21. defense@Arm=0,
    22. defensearmour={\shield{}},
    23. offensename=\mongrel{},
    24. offense@At=1,
    25. offense@Of=3,
    26. offense@St=3,
    27. offense@AP=0,
    28. offense@Ag=3,
    29. offenserules={\primalinstinct{}},
    30. commandgroup={%
    31. \champion{}=20,
    32. \musician{}=20,
    33. \standardbearer{}=20,
    34. \alphaorderstickto{\standardbearer{}=20}\suboptionindent{}\bannerallowance{}=\nolimit{},
    35. },
    36. options={%
    37. \ambush{} {(\zerotoXmodelsperunit{30}, \zerotoXunitsperarmy{2})}=20,
    38. \spear{}=\free{},
    39. },
    40. } % END UNIT ENTRY
    Display All