Week 9: PM (Pattern Matching or Parsing Mayhem?)

Hey guys! This week, I focused mainly on data extraction — the part of my project I’ve been hyping up for all this time.

Iteration

The main reason I steered so clear of this part of the project was I had zero clue how to approach it. In my head, the computer should automatically read through the data the same way I do. So then how do I explicitly define that process? Eventually, I decided to test out procedural part steps: taking each line of the data one at a time and using logic statements to see how to work with them.

This relies pretty heavily on something called a Which[] function. As the name implies, it literally sees which of the conditions it reads through are true. The first argument to evaluate True has its procedure initiated. My Which[] function looked something like this.

Pattern Matching

In order to write the patterns to match with the lines, I needed to look through a bunch of battle logs to just see what are all the potential types of lines of code that I care about in this project. All of these patterns have corresponding outputs to them, so I can use the matching and the replacement parts of patterns from the same ones. Basically, think of it like some program that looks at the sentence “I eat green apples.” The program, starting from the beginning of the string/sentence, looks for a subject. (maybe said to be “I”, “You”, or “*Other pronoun*”), a color (“Green”, “Red”, or “Yellow”), and then the last word “apples”.

This wouldn’t match with the sentence “I drink green beverage” or “I eat orange apples.” But upon seeing the sentence “I eat red apples”, it would see that to match the pattern, and then perform the replacement — in this case, maybe it simply outputs the subject and the apple color. Through some extra syntax, these outputs are assigned to different association values (think "Subject"->"_" or "Apple_color"->"_"), and then appended to a large database containing all of the other relevant information.

Output Extraction

A similar whichList is used with a Which[] function for actions, just with different things to look out for. I decided to have the outputs be in the form of p1a_actions, p1b_actions, p2a_actions, and p2b_actions. So, I have to keep track of the player-intended actions by each Pokémon on the field throughout the resulting turn. This gets a little complicated when you consider not all actions that a Pokémon takes are what the player wanted. For example, the move Encore makes the target use the same move for the next 3 turns. Say you wanted to use a certain move and right before attacking you’re hit with Encore. Here, your choice would be overwritten. This isn’t exactly something I can account for, so I’ll have to just accept that source of error.

Another example is forced switch/dragging. This is when, as the name suggests, your Pokémon is forced to switch unexpectedly due to an enemy attack. Luckily, this is triggered by a different command type than simple switching, so I can just tell the program to ignore lines starting with "|-drag|". One final point is that your Pokémon may be knocked out before it gets a chance to make a move! In these cases, we can never know what the players were intending to do. If I don’t do anything about it, then there just won’t be any value for that Pokémon’s action (Null).

Initialization

To remedy this, and any other potential missing data, I’ll need to introduce an initialization step. Basically, instead of building from ground-up with every new line, initialization tells the program all the parameters it will need to ever look out for, and also assign default value “none” to them. It’s not ideal, but this will at least make sure the network isn’t fussy about missing training data. Hopefully once the neural network spits out results, I can just make sure that all “none” values it gives are removed.

Next week, I plan to finally start on the neural network’s construction! See you then!

-Alex R.