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 - 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 - Capstone Blog Post 1

Over the past couple of weeks, Matthew and I have been trying to narrow down our idea for capstone. We have settled on a "Modular" AI that can play First Person Shooters or other similar video games. However, we decided to put a slight twist on the idea of an AI playing games. Most of the AIs that are currently out have more information than they should possibly have at that time, like the location of players. We decided that our AI would only have information that would be accessible to a human player. We also noticed that many of the "PlayerAIs" out there are reactionary, not planning. While reacting is a key part to many of these games, so is strategy. We want to create an AI that thinks, at least a little bit, about that actions it is making or should make.

Since narrowing down our topic we have split off and started looking at different existing technologies and research that could help us understand and create this project. I decided to look at some computer…
Post a Comment
Read more

Matthew - Capstone Blog Post 4

Finally, our CSI-480 (Advanced Topics: AI) course material is catching up to where we need to be. We are covering perceptrons and sigmoid neurons in the lectures, and we are also using TensorFlow to solve some very simple introductory problems (via tutorials). To supplement this I have been reading Neural Networks and Deep Learning by Michael Nielsen, a textbook available for free on the internet, which dives into neural networks right from the first chapter. Additionally, I have been finding 3Blue1Brown's multi-part video series about deep learning to be extremely helpful for visualizing some of the more advanced concepts. Even if I do not fully understand the calculus and linear algebra involved, at the very least I have a better idea of what goes on inside of neural networks. For example: I know what loss and gradient descentalgorithmsdo, essentially, and I also understand how the latter helps find a local minimum for the former, but I do not necessarily feel confident in my …
Post a Comment
Read more