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.