Skip to main content

Matthew - Capstone Blog Post 3

This week I set up my development environment for the project. I started by resetting Windows 10, in order to ensure that I would be working with a blank slate. Then I installed the Anaconda distribution for Python 3 and created a project environment. From there, the process was just a matter of following the Windows installation guides for SerpentAI and Tensorflow-GPU. I chose Windows for my platform because I have a GTX 980 and wanted to be able to get the most out of it with NVIDIA's proprietary drivers and toolkits. This is possible on Linux, but in my personal experience it can be much more difficult and also less stable, depending on your Linux distribution.


With SerpentAI set up I decided I should go ahead and test it out. Rei told me that we should start by using a game called Rivals of Aether as our training platform. Their justification is that 1) a 2D fighting game will be much simpler, and 2) RoA stores replay data in simple plaintext rather than in video, or worse, binary formats. Thus, I installed RoA and ran through the SerpentAI "Hello World" tutorial. It's not much, but I made Orcane waddle to the right:


I ran into a number of problems and pitfalls while setting up Tensorflow. For one, the latest version of CUDA supported by Tensorflow-GPU is 8.0 whereas the latest available version is 9.0. Also, if you are using CUDA 8.0, you will need  CUDNN 6.0. Fortunately, the latest version of Python, version 3.6, is supported by both SerpentAI and Tensorflow, so I don't need to worry about maintaining two different Anaconda environments and somehow making them talk to each other. Furthermore, both SerpentAI and Tensorflow/Tensorflow-GPU are available on Pip, which streamlines requisition and dependency management. Nonetheless, I found myself plagued by a recurring traceback when trying to import Tensorflow: "No module named '_pywrap_tensorflow_internal". After much searching and troubleshooting I finally found a command that magically fixes the error: "conda install -c conda-forge tensorflow-gpu". This appeared to use conda-forge to sort out some kind of dependency issue. It installs packages called "cudnn", "cudatoolkit", and "tensorflow-gpu", which I should have already had installed. It works, though, so I won't question it.

Running through the "Getting Started" guide reveals that my CPU supports SSE, SSE2, SSE3, SSE4.1, SSE4.2, AVX, AVX2, and FMA. Sadly, AVX512 is not included on that list because my computer is not from the future and I don't own an oil rig. In any case, I can take advantage of the streaming SIMD extensions that are available to me if I compile Tensorflow manually. That's not likely to happen this week, since the only benefits will be increased CPU computation speeds. Below is a screenshot of my early adventures in the aforementioned Tensorflow tutorial, for fun and science:

Other thoughts

I am sad that we might not get to work with a first-person-shooter. However, I completely agree with Rei's reasoning on this. If we can get an agent working well with RoA, then we might reconsider restoring the original project scope. Otherwise, I would rather we play it safe and not get too ambitious, especially given that we are only just getting started in this field.

That said, I did learn a thing or two about Quake replays, or "demos" as the community (and source code) refer to them. There is an immense repository of demos available for download on Speed Demos Archive. If we could create a passive learning agent that could read .dem files, then this site provide an amazing data set. However, that is where we start to encounter problems. First, the demos are stored inside of dz archives which require a somewhat obscure file compression application called Dzip. Okay, this is not such a problem; sure, the program may have been last updated in 2003, but it installs on Windows 10 just fine. Second, the .dem files that we can extract from the .dz archives are in binary format rather than plaintext. This means that we will need to figure out how to decode them in order to make any sense of them. Our best bet for this will be the Quake 1 source code, which is available on GitHub under the GPL. I have so far found one promising file but it does not give me a complete picture. It seems to read the file one byte at a time in integer format, but beyond that I am not sure what it does. Below is an excerpt from cl_demo.c, containing (I think) the read loop:

Perhaps I should consider myself lucky that we are using RoA. Or perhaps I shouldn't; after all, I have no idea of RoA has anything like the Quake demos repository on Speed Demos Archive. If not, we will have to record our own replays or ask others to share theirs.


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…