Skip to main content

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:

This model was made with the help of the wonderful community over on Stack Overflow. I would also like to mention that Professor Auerbach made invaluable contributions. In general, his tutelage made this project possible.

We dropped our Sequence subclass, and replaced it with training and testing loops. In these loops, we iterate over the whole training or testing set on a replay-by-replay basis, just as we did before. However, we now split each replay into multiple clips, where each clip contains exactly 100 labeled frames. We then run train_on_batch for each clip. When we run out of clips, we reset the state of the LSTM. As it turns out, all of our problems with resource exhaustion were caused by our replays having too many frames. Splitting them into clips fixes this. 100 frames is not as scarce as it might sound because our framerate during collection is 10 frames per second rather than 60. As a result, 100 frames represents 10 whole seconds of gameplay.

The model shown above successfully runs through its training and testing loops. It also saves itself to an H5 file, and metrics from its training and testing runs are recorded via Pandas and then saved in CSV format. Mean performance seems to increase over time by a modest amount. Our next step will be to try using the model to make predictions during live gameplay.

Loader improvements

The replay loader now uses multiprocessing in order to continually load and unpack replays in the background while the model trains and tests. It achieves this using two multiprocessing queues assigned to two different subprocesses. One queue and subprocess is for the training set and the other is for the testing set. In short, each subprocess loads and unpacks replays one-at-a-time until the queue has reached its maximum capacity. Once the queue is full, the subprocess waits for its handler (i.e. the loader) to dequeue an element. After this happens, the subprocess loads, unpacks, and queues another replay. When there are no more replays to load, the subprocess enqueues a null pointer and then closes its handle for the queue before terminating itself.

The first replay is always slow to load because the subprocesses don't have enough time at the start. However, as training and testing continue, the subprocesses quickly show their benefits. Our biggest time bottleneck has pretty much been completely done away with.

Other notes

Otherwise, Rei and I have been working on unit tests. Our project structure for Rivals of Aether Supervised Learning received a major overhaul. It's starting to look like a Real Project. It has subfolders for source code, tests, metrics, sample data, and more.

I am running into an import issue with some of my unit tests. In short test T imports module A, and module A imports module B from the same directory. When I run A, B is imported by A successfully. When I run T, however, A fails to import B. It's a little bizarre. I'll probably figure it out later, though. We have tests, which means we technically are meeting the requirements. Probably.

Oh right, and before I forget: I finished collecting all of the frame data for all of the replays in our dataset. The final size is 99.3 GB. In other words, it's official: the largest single-purpose use of storage on my computer is no longer Final Fantasy XV (83.2 GB); it's now low-res pixel art of furries. What a time to be alive.


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 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 …

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…