Skip to main content

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 whole training or testing set on a replay-by-replay basis, just as we did before. However, we now split each replay into multiple clips, where each clip contains exactly 100 labeled frames. We then run train_on_batch for each clip. When we run out of clips, we reset the state of the LSTM. As it turns out, all of our problems with resource exhaustion were caused by our replays having too many frames. Splitting them into clips fixes this. 100 frames is not as scarce as it might sound because our framerate during collection is 10 frames per second rather than 60. As a result, 100 frames represents 10 whole seconds of gameplay.

The model shown above successfully runs through its training and testing loops. It also saves itself to an H5 file, and metrics from its training and testing runs are recorded via Pandas and then saved in CSV format. Mean performance seems to increase over time by a modest amount. Our next step will be to try using the model to make predictions during live gameplay.

Loader improvements

The replay loader now uses multiprocessing in order to continually load and unpack replays in the background while the model trains and tests. It achieves this using two multiprocessing queues assigned to two different subprocesses. One queue and subprocess is for the training set and the other is for the testing set. In short, each subprocess loads and unpacks replays one-at-a-time until the queue has reached its maximum capacity. Once the queue is full, the subprocess waits for its handler (i.e. the loader) to dequeue an element. After this happens, the subprocess loads, unpacks, and queues another replay. When there are no more replays to load, the subprocess enqueues a null pointer and then closes its handle for the queue before terminating itself.

The first replay is always slow to load because the subprocesses don't have enough time at the start. However, as training and testing continue, the subprocesses quickly show their benefits. Our biggest time bottleneck has pretty much been completely done away with.

Other notes

Otherwise, Rei and I have been working on unit tests. Our project structure for Rivals of Aether Supervised Learning received a major overhaul. It's starting to look like a Real Project. It has subfolders for source code, tests, metrics, sample data, and more.

I am running into an import issue with some of my unit tests. In short test T imports module A, and module A imports module B from the same directory. When I run A, B is imported by A successfully. When I run T, however, A fails to import B. It's a little bizarre. I'll probably figure it out later, though. We have tests, which means we technically are meeting the requirements. Probably.

Oh right, and before I forget: I finished collecting all of the frame data for all of the replays in our dataset. The final size is 99.3 GB. In other words, it's official: the largest single-purpose use of storage on my computer is no longer Final Fantasy XV (83.2 GB); it's now low-res pixel art of furries. What a time to be alive.


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 …

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…

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 …