Skip to main content

Matthew - Capstone Blog Post 6


First, let's briefly cover what happened over the break. I spent most of my time working at my job, but managed to read most of Michael Nielsen's textbook, Neural Networks and Deep Learning. I also read much of the documentation for both Keras and SerpentAI and studied some of the latter's source code. Overall, I feel as though I have a much better understanding of A) neural networks, and B) our frameworks. Additionally, I have started participating on the Discord servers for SerpentAI and Rivals of Aether. Both communities have proven to be of great help in their respective domains of expertise.

Next, I must report some unfortunate news. Some 222 replay files out of our set are unusable because they are from early versions of the game that do not support replay playback. Still, this leaves us with 798 perfectly fine replays; I believe we have more than enough.

Since the beginning of the semester, I have taken steps towards organizing and structuring our project. I wrote an ROA version sorter which looks inside of your replays folder (usually found in AppData/local/RivalsofAether/replays), reads each replay, creates a folder for each game version that has a replay, and then moves all of the replays into the correct folder. The resulting file structure is supposed to look something like this:

Incidentally, all of the folders that start with "00" represent versions of the game with which we are unable to use replays.

The project now uses a configuration file called roa.ini to store the path to the replays folder, because this path can vary depending on your username (e.g. in my case it's a subdirectoy of C:\Users\matth). This allows our scripts and plugins to access the replays folder without any annoying handholding like launch arguments or hardcoded constants.

Well, I should say that it does so mostly without that sort of annoying handholding. There is one symbolic directory link that is absolutely essential:



The symbolic link is located inside of the SerpentAI installation location and it goes to the plugins folder found in the repository. This allows us to run the plugins with SerpentAI without having to copy the plugins from the repository to the SerpentAI installation location. You could try manually copying the plugins if you don't want to set up a symlink, but I would recommend against doing so because the plugins will try to step back through the symlink to find the configuration file. This step back will crash if a symlink is not found at the expected location.

Otherwise, I have started writing a helper module called replay_management. This contains a replay manager class which keeps track of all of the replay files. The goal of this replay manager is to be able to organize different batches and also ask for individual replays. Right now the manager's set up so that it is able to read all of the replay folders (seen above) and all of the replay files located therein. The module also contains some useful enums for stages and characters. Each stage and character is now associated (via enumeration) with the number that represents it in a replay file. For example, Ranno is character 11 and Blazing Hideout is stage 07.

The problem I am currently working on is how to split the replay files into different sets for training, testing, and validating the neural network; the manager must be able to do this through random sampling according to some specified distribution (e.g. 0.6, 0.2, 0.2). Furthermore, I have to come up with a better class hierarchy for managing batches because the current one is kind of a mess.

Lastly, I would like to draw attention to one problem that is given me conniptions. Do we have the neural network train by watching replays in real time? This could be slow and inconsistent. Alternatively, should we try to use a library like mss or perhaps a secondary game agent with SerpentAI (which uses mss) to capture the specific frames we want for each replay file? If we go with the latter route, training will be much faster. This wasn't our original plan, however, so we will need to discuss this internally as a team.

I would say that our greatest obstacle right now is matching frames from the game with input data from the replay files. I think we will be out of the woods once we can solve this.
 

https://pa1.narvii.com/5692/db17de5e5db99188681fa3a73f07c833cfb9e29d_hq.gif

Comments

Popular posts from this blog

Rei - Blog Post 10

So,  I missed blog post 9. This is me acknowledging that for consistency. Anyway, the past couple of weeks have been incredibly productive for ContentsMayBeHot. Matthew has finished collecting all the replay data, we have refactored our project to reduce complexity, we have improved the runtime of our code, and finally we have started seriously training our model. The Changes Matthew implemented multi-threading for the model loading. Which reduced our load time between files from about 3-5 Seconds to 1 Second or less. Which allows us to fully train a model in much less time! While Matthew did this I reduced the code duplication in our project. This way, if we needed to change how we loaded our training data, we didn't have to change it in multiple places. This just allows us to make hot-fixes much more efficiently. We also started working on some unittests for our project using pytest. These tests were written because of a requirement for another class, but we thought it...

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: model.fit_generator(sequence) model.evaluate_generator(sequence) 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 clas...

Rei - Blog Post 4 & 5

Due to external factors, I accidentally missed the last Blog Post, however I shall make up for it by writing two posts in one! The last couple of weeks have been at least a little productive. Blog Post 4 Over these weeks, Matthew and I were both working on solidifying and exploring the context portion of our project. Of course, we have been exploring the context since nearly the beginning of the year, but because of both capstone classes have asked us to write something about the context of our paper. The context of our project can be found throughout our previous blog post, but a short and summarized version of out context section boils down to a couple main points.  Neural Networks are not too present in video games. When neural nets are present, they are used for research or marketing. As for the rest of our Design Document, unfortunately we rushed it a bit. We got caught up in some upsetting events these weeks and allowed our work to suffer instead of staying on t...