This week was a little bit of a doozy. I split my attention between two main things: attempts at parsing replay data and attending Wolfram U classes.

Parsing replay data progress

String manipulation in Mathematica is definitely not as easy as I had thought when I initially conceived of the project. A string is really just a non-numeric, text-based piece of data, specified to the program by using quotation marks. "This is a string in the eyes of Mathematica and most other coding languages." When I import a replay, I get a giant messy string, basically the untranslated instructions to the display- so not exactly the most comprehensible. It’s at least written in English-adjacent blocks, so not too hard to wrap your head around what it means.

Each “line” in the actual replay begins with a |, and then some word to signify what’s going on in that line. For example, a text line would look like |t:|, followed by the message that would be displayed. Or, alternatively, if a Pokémon was using an attack on that line, it would look like |move|, then it would say the user (stored as p1a, p1b, p2a, or p2b in shorthand), the attack that was used, the target (again following the shorthand naming rules), and then all effects of the action (e.g. damage, stat drops).

This data is exactly what I need for the project, so now I have to split it into usable parts. Ideally, the structure that I extract would look something like this:

, where each thing in green is a value that I determine from the big lump of replay data, and a {...} means that the data inside the curly brackets follows the same structure as the previous one. The process of getting all this data for every turn seems simple on paper, but actually becomes very daunting very fast.

Parsing concerns

My major concerns at the moment are about storing data inside the parser as it goes through the lines of text, because a lot of the variables that remain constant aren’t actually said out loud in the text. So, if a Pokémon switched into the p1a slot last turn and hasn’t switched out, the text doesn’t specify that p1a is that Pokémon — it just says p1a. p1a is only said to be the Pokémon when its value changes. Likewise, I need to somehow store the p1a value until it’s updated, and do the same for every single other potential static unannounced variable. 

At the moment, this is not something I know how to do! Once I figure out this issue of holding onto data across writing down the parts of the battle that I need, I also have to arrange some string manipulator functions in a way that can get the basic values I need from a line of code. For example, such manipulators would input something like :

"|move|p2b: Hawlucha|Drain Punch|p1a: Ambipom", \
"|-supereffective|p1a: Ambipom", "|-damage|p1a: Ambipom|0 fnt", \
"|-heal|p2b: Hawlucha|100/100|[from] drain|[of] p1a: Ambipom", \
"|faint|p1a: Ambipom"

, and output something like

"action"-> {"user"->"p2a"->"Hawlucha","move"->"Drain Punch","target"->"p1a"->"Ambipom"} (I would only need the first line of code since the computer doesn’t need to determine effects of an action to understand what to do)

Here are the links to my scratch notebooks from this week:

Parsing tests and potential type-viability value function.

Usage stats raw data tests.

Wolfram U Class

I’ll talk more about my experiences so far with Wolfram U next week. I’ve signed up for a bunch of courses though with live instructors that I can ask questions to, so I’m optimistic about getting more formal experience with the coding language!

Best,

Alex R.