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

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

Matthew - Capstone Blog Post 1

First I would like to discuss our goals and long-term plans. We want to create an artificial intelligence that learns how to play first-person shooters without access to any game state data other than what can be gained through the audio and visual buffers. In other words, the AI will only have access to the information that a human player would. If we are successful with these constraints, then I could see our work leading to AI that can play any game, or even AI-driven robots that can play games using mechanical hands and eyes to operate normal peripherals and interfaces. We are currently in the research and planning phase of the project. This means that our job right now is to decide exactly what tools and technologies we will use and how they will interact with one another. By the end of the semester, which will arrive sometime this December, we will need to be ready for phase two, which is the development, training, and testing phase. Yes, that is all three at once. However, if...
1 comment
Read more

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