Skip to main content

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.

  1.  Neural Networks are not too present in video games.
  2. 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 task. However, we did eventually get ourselves together and write something. We realize that something may have not been our best work, but it was work none the less.

Matthew was kind enough to setup a repository for our project, this is where all of our public facing code and documentation will live on the internet. This will not include any of our training data, except for the training data that me and Matthew Supply. That repository can be found here.

Blog Post 5

Over these weeks, we were reeling from the busyness of Thanksgiving and Black Friday, but we did get some important work done. Matthew made a reddit post soliciting replay data from the Rivals of Aether Community. We very quickly got many user submissions from the community, these replays are considered private data so we will not be sharing them with the public.

Now that we have data though, we need to label it! Luckily the first few lines of the replay file contain how we want to label it. The labels we want will most likely be:

  1. The character we are playing as.
  2. The map we are playing on.
  3. If the game is vs Human or vs CPU
  4. Who provided the data. (If we want to train it off of one person.)
All of this is, again, incredibly easy to extract from the replay file. After we label this data, we should also figure out how to parse the data into data we can use, there are community tools in the works that we can use as reference data, but creating our own will most likely be the course we need to take.

During this blog posts frame, we also received feedback for our design document. We did make some dumb mistakes, like not compiling out LaTeX files into a pdf, which we will be sure not to do again. We also know that our literature review itself was not as good as it should have been. The goal for our final few weeks of this semester is to reevaluate our literature review and move on to creating a better problem statement. The reevaluation will mostly consist of really solidifying where our sources fit into our project. In all honesty, most of our research was just us building a body of knowledge for A.I., but we should have stated this more clearly.

As for the problem statement, Matthew and I will need to really work on nailing down a better wording. We understand what we wish our project to be, we just failed to explain it properly.


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…