Skip to main content

Rei - Captsone Blog Post 3

Over the past couple of weeks, progress on this project has been slow but meaningful. Matthew and I have decided to do a temporary re-scoping of the project. Instead of focusing on a 3-D game, we are going to move to a simpler 2-D game. The game is the only real change we have made though, as we still want it to infer a game state from the visual buffer.


The game we have chosen is the 2-D pixel fighter Rivals of Aether.


 We chose this game primarily because of how it outputs replay data. Rivals of Aether stores its replay data as plain-text. More specifically it stores input data as 'tuples' of (InputFrame, Input) for example '5134y' is saying press the 'Y' button on frame 5134. Using this we can gather more data for our RivalsAgent to learn from.


Currently, the plan Matthew and I have agreed upon is to work primarily with Rivals of Aether. If our implementation works well and we feel as if we can safely scope-up, we will move from Rivals to Quake.


As I promised in Post 2, I have also began looking into data flow in Neural Networks. From what research I have done and considering the scope of our project, I have found and begun research on two classes of neural networks. The neural networks are Feedforward Neural Networks and Recurrent Neural Networks.

Feedforward Neural Networks are the first and simplest type of neural network. Connections between units do not form a cycle. Information in A feed forward network moves in one direction. This leads to this type of network to be used for the "supervised learning of binary classifiers" meaning that an input either belongs to some class or does not. For example, a network that tries to find correlations between two related data sets could use feed-forward.

Recurrent Neural Networks on the other hand do have cycles. These cycles allow the network to use previously learned data to learn more about both the same data and similar data. Many recognition algorithims use these types of networks. For example, a Handwriting Recognition tool would need to learn about how the user writes letters, and then can use that data to learn how the user writes words and so on.

Combining feed forward and recurrent networks in modular systems has been done many times before, regardless our project will most likely combine these networks to reach our end goal.
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

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