Skip to main content

Matthew - Blog Post 7

Since January, we've been working hard to not only finish writing the Replay Parser and Frame Collector but also totally synchronize them. I'm pleased to report our success. This is an amazing milestone for us because it means that we've surmounted one of our most troubling obstacles.

I have also made sure to keep our documentation up to date. So, if you like, you can follow along with this blog post by replicating its results.

The Frame Collector uses timed input sequences to start each replay associated with the currently running game version. Then, after waiting a set amount of time for playback to begin, it starts grabbing 1/4-scale frames at a rate of 10 frames per second. The Frame Collector takes these down-scaled frames, which are NumPy arrays, and rapidly pickles and dumps them into the file system. Here's a screenshot of the Frame Collector in action:

If you look at the image above, you'll see that each pickle (the .np files) is simply assigned a number as its file name. This number corresponds with an estimate on how many frames passed since playback started, so "" is the 1st frame and "" is the 349th frame. The frame index values are only estimates because we do not have access to the game's internal state. However, frame 0 appears to be more or less consistently synchronized with the moment when "GO!" is fading out, which is close enough for our purposes. Recall that we are not trying to classify which character animation is associated with each movement type; rather, we are trying to predict the best movement type for any given situation.

We chose 1/4 scale because full scale results in about 1 GB per minute of playback, which is not only taxing on our collective storage capabilities, but is also excessive for machine learning. After all, each individual pixel will need to be represented by its own input node in our neural network. Otherwise, we are running the Frame Collector at about 10 FPS because, after some experimentation, we found that it provides a good balance in terms of the number of frame buffer captures generated per minute and the number of missing frames between each capture.

Our next step will be to run the Frame Collector for additional replays in order to confirm that the frames index values for all of the pickles continue to synchronize with the replay files. This can only be achieved via manual review of random samples. Hopefully we do not encounter too many discrepancies. The biggest risk I am aware of is the possibility that different replay files may take slightly different amounts of time to load in the game. I think that this is unlikely to have a significant effect, though, because replay files are never especially large.

Once we've finished those tests, we will need to collect a larger portion of the dataset. Unfortunately the collection phase can only happen in real time because the Frame Collector has to watch each replay file from start to finish. The upside of this is that the Frame Collector can run independently, fetching and watching replay files one after the other until there are none left for the installed version of the game. After we have collected all of our dataset, we will then need to finish writing the Replay Loader, implement our neural network with Keras, and begin training.


Popular posts from this blog

Matthew - Blog Post 9

After our last meeting, Professor Auerbach asked us to shift our focus towards building and training our model. So that's what we've been working on lately. The results so far have been interesting and problematic.

The first step was to define a minimal working model and a loading system to feed it our labelled data-set. I wrote a Sequence subclass, which is essentially a kind of generator designed for use with the fit_generator method. With fit_generator and a sequence, we're able to train and test the model with just a couple of one-liners:


The sequence subclass also has a few other tricks up its proverbial sleeve. For one, it reduces the dimensionality of the frame buffer data from 135×240×3 to 135×240×1 by converting it to gray-scale. This reduces the number of features from 97,200 to 32,400. For two, it does the same with the labels, combining and dropping 26 action types into just 9 atomic classes. This a…

Matthew - Blog Post 8 is only 339 lines long but it feels at least three times that when I'm working on it. The module is definitely due for a refactor. For one, the term subdataset should be renamed to version_set and extracted into a class. version_set more accurately and describes what it is, and the class extraction would clean up the namespace in ReplayManager. There is probably some kind of class extraction possible for replays, so that their names, paths, file streams, and Twitter profiles can all be neatly encapsulated, thereby cleaning up the namespace even more. However, I do not want to worry about having two kinds of replays: the one used by ReplayManager and the one used by ReplayParser. Even though ReplayManager does not use ReplayParser, the prospect of making things more muddier deters me.

There's probably a right way to refactor this code, but, to put it simply, now is not the time. Speaking of time, I came up with a great way to get work done, even when I am sleep…

Matthew - Blog Post 10

At the time of my last blog post, we were managing quite a few problems. Our model was essentially vaporware, our training and testing was hindered by slow, blocking function calls from our loader, and our VRAM was continually getting exhausted during training sessions. But there is nothing to worry about. We have made major strides since then. Major strides.
Model improvements First, we have completely overhauled our model's architecture. We are now using a model composed of special layers that combine the functionality of a 2D convolutional neural network with that of an LSTM. Here is a summary of  our model as printed by Keras: