Skip to main content

Matthew - Capstone Blog Post 5



Soliciting data from the community

It's official. We shilly-shallied about it for months, but now we have finally settled on Rivals of Aether as our training platform. On November 25th, I made a thread on r/RivalsOfAether titled Looking for replay files to use in machine learning research. I honestly was not sure what kind of response to expect. I had only learned about RoA's existence, I would estimate, sometime around mid-October. Rei pitched it to me several times as a viable alternative to Doom and Quake for machine learning, citing its ability to record input data from matches in plaintext. They even bought me a copy towards the end of October, which featured in my blog post about setting up SerpentAI.

The plaintext replay files are certainly an attractive prospect when compared to the binary demo files found in id shooters. Furthermore, the game itself is stylish and fun. I mean, just look at Orcane!

Source
Nonetheless, I was wary of the idea of using it as our training platform due to a lack of readily-available data. Quake has online repositories like Speed Demo Archives and Quake Terminus. Clearly it is the only choice we have? Besides, wasn't the original pitch to use an FPS, and the original dream to make a UT4 bot?

Well, in less than 24 hours after I posted on the RoA subreddit, the community gave us 893 replay files featuring matches from a variety of settings, including tournaments, exhibitions, and ranked matches. This dataset makes a world of difference, not just to the practicality of our project but also to my outlook. In retrospect, I have come to realize that I simply like Rivals more than Quake/Doom; I just needed to know that it could be a viable platform before I could let myself get attached to it.

As of today (11/27), we have 1,032 replays. I honestly couldn't be happier. I just want to do a good job so that we can make the Rivals community proud.

Regarding feedback on the design document

We received feedback on our design document draft. Apart from fixing our citations and, you know, actually compiling our LaTeX into PDF, we mainly need to improve our literature and methodology write-ups. I already have a two-birds-one-stone styled plan for this.

We will do another pass over all of our academic sources, filling out templates I designed to guide us for both of the aforementioned sections. The templates are meant to serve as an organized repository of information—kind of like a document database, except not elegant or efficient, but rather all crammed inside of a single WYSIWYG doc. I guess I will share that template here, but please be kind when you tear it to shreds:

Article title
Researcher names
Problem:
What they are using machine learning to do.
Application/Tests:
What game or environment they are placing their AI into and what concrete tasks they give it.
Software:
List of libraries, software, and other tools used by the researchers.
Data Structures & Algorithms:
List of data structures and algorithms they use, and a brief description for each.
Data flow:
Quick explanation of how the aforementioned data structures and algorithms work together to produce the desired result, i.e. a textual data flow summary.
Outcome:
Whether or not the tests were successful.
References:
Any research or experiments that are frequently mentioned. Note the title, research and context as follows: Title. Names. Context.

We should have approached our research in this neat and organized manner from the start. Oh well. We will just have to find time to reread everything. We will also have to find time to research the same problems we have already researched but for 2D. Also, we will need to properly assess Keras and fix our introduction section. Of course, it's easy to just list the things we have to do...
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

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