Earlier quoted context omitted.
Tensorflow (or PyTorch, or any other framework) aren't the problem, though. It's choosing a suitable net architecture, loss function, and training methodology all of which require in-depth knowledge and lots of experimentation. Even after that you're only half way there, because now the fun and exploration is over and the pain begins: finding (and worse even - annotating!) and validating training data. Once this herc…
> It's choosing a suitable net architecture, loss function, and training methodology all of which require in-depth knowledge and lots of experimentation. Yes, things have progressed since my time in undergrad studying NNs and such. Presumably the work done on MtG transfers. > Even after that you're only half way there, because now the fun and exploration is over and the pain begins: finding (and worse even - annotati…
A few years ago there was a community project training RNNs to generate M:tG cards [1], that if I'm not mistaken became Roborosewater [2]. M:tG already had around 12-15k cards by the time and still the majority of generated cards did not make sense. In the mtgsalvation thread in [1], most of the time people crack out with the nonsense that's generated by the RNNs people train [3]. There are also plenty of cards that make sense and are interesting and even usable, but they had to be hand-picked out of buckets of nonsense. A lot of curation and probably editing generated cards by hand would be needed, which somewhat defeats the purpose of the whole endeavour.
To generate new cards it would make much more sense to use good old procedural generation starting with a hand-crafted grammar of the rules text. This is certainly doable for a game of the size of M:tG, let alone Netrunner. For instance, M:tG Arena, the online p2p version of the game, runs on a game engine with a hand-crafted parser, the Game Rules Parser, that essentially resolves spells like an interpreter executing a script [4][5].
I mean to say, sometimes jumping feet-first into learning how to use a new set of complex tools is not necessary. Simpler tools that should already be in every programmer's toolbox can do the job fine, sometimes, even when it seems easier to just get a bunch of data and put it through a machine learning meat grinder. "Easier" might turn out to mean you need to do a lot more work before and after you can use the "easier" method (e.g. labelling, training, curation, etc) and not even get very good results in the end.
___________
[1] https://www.mtgsalvation.com/forums/magic-fundamentals/custo...
[2] https://twitter.com/RoboRosewater
[3] The project was started by the user Talcos, then more people started training their own nets using Talcos' code.
[4] https://www.reddit.com/r/magicTCG/comments/74hw1z/magic_aren...
[5] To tout my own horn a bit, I did the same thing in my degree as a final year project, but I didn't have enough time to get full coverage of the entire card corpus at the time - still, I was just one undergrad student and I did manage to get a big chunk of the game working with a rules parser. The parser was written in Prolog meaning I could "run it backwards" as a generator so the project had an M:tG ability text generator that spat out grammatically correct, if not always particularly useful, text. I'm not linking to the project because it was 9 years ago and it's painfully embarrassing looking at it now.