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.

SerpentAI

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:

https://cdn.discordapp.com/attachments/363058124351078401/372956887077093376/unknown.png

Tensorflow

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.
Labels:

Comments

Post a Comment

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
Post a Comment
Read more

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 whol
Post a Comment
Read more

Matthew - Blog Post 8

replaymanager.py 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 slee
Post a Comment
Read more