Skip to main content

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 all happens very quickly in memory; the stored files are left alone in case we ever decide we need 26 classes or 3 color channels. As for our minimal working model: it was just a simple feed-forward neural network with an input layer, one hidden layer, and an output layer. It used RMSProp as its optimizer, categorical cross-entropy as its loss function, and accuracy for its metric. The output layer uses softmax for its activation function, resulting in decimal values between 0 and 1. I trained the model overnight on our currently processed dataset of 301 samples, where the average sample contained between 1000 and 2000 labelled frames.

After training the basic model, I wrote a quick game agent which loads the model and then feeds the it game frames in exchange for predictions. The predictions come as a list of 9 values from the softmax layer. The agent is pretty simple; it just tests each prediction class against an arbitrarily-defined threshold value. If the prediction value exceeds the threshold, then the button for the corresponding action is pressed; otherwise, that button is released. Some classes, such as left and right or up and down, are mutually exclusive. For example, if both left and right pass the threshold test, then the agent will choose the higher of the two.

So, what did the feed-forward neural network make game agent do? Well, it mostly held down and left and occasionally tried to jump. The result was a pacifist bot that appears to cower in the corner before jumping off of the stage to kill itself. I believe that this is a good first step.
Image credit

After confirming that the feed-forward model successfully trains, saves, loads, and predicts, Rei and I set to work on developing bigger and better models. So far we have created and trained an LSTM and a 2D convolutional network. However, neither of these have had great results in the game yet. I was unable to make the LSTM load, and the 2D convolutional network somehow managed to play even more poorly than the feedforward network. Furthermore, we have a serious resource problem. I am only able to train our advanced models on  CPU and RAM, because my 6 GB of VRAM is not nearly enough for me to run them on GPU. The convolutional network in particular utilized nearly all 32 GB of RAM on my computer as well as 100% of the processing power of my I7 6700. It also took around 8 hours to train.

The last major issue is that of creating our perfect dream-model. We are trying to combine the 2D convolutional network architecture with an LSTM. This means that our input shape needs an additional dimension: time. Currently, our input shape is batch size × image u × image v × image color channels, or n×135×240×1. The time dimension, which represents frames, must go between batch size and image u. However, to my knowledge only batch size can be variable, and our replays have all kinds of durations! Keras provides a TimeDistributed wrapper that we can use to encapsulate our Conv2D layers. Also, we will be looking into the ConvLSTM2D layer provided by Keras; it is a specialized type of layer that performs the exact task we are interested in. However, I am not sure how to we can define our input shape. We may have to overhaul our Sequence subclass so that it produces a fixed number of frames. Only additional research and experimentation will lead to an answer, though.


Popular posts from this blog

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…

Rei - Captsone Blog Post 3

Over the past couple of weeks, progress on this project has been slow but meaningful. Matthew and I have decided to do a temporary re-scoping of the project. Instead of focusing on a 3-D game, we are going to move to a simpler 2-D game. The game is the only real change we have made though, as we still want it to infer a game state from the visual buffer.

The game we have chosen is the 2-D pixel fighter Rivals of Aether.

 We chose this game primarily because of how it outputs replay data. Rivals of Aether stores its replay data as plain-text. More specifically it stores input data as 'tuples' of (InputFrame, Input) for example '5134y' is saying press the 'Y' button on frame 5134. Using this we can gather more data for our RivalsAgent to learn from.

Currently, the plan Matthew and I have agreed upon is to work primarily with Rivals of Aether. If our implementation works well and we feel as if we can safely scope-up, we will move from Rivals to Quake.

As I promis…