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

Labels:

Comments

Post a Comment

Popular posts from this blog

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

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

Rei - Blog Post 8

This most recent work period involved a lot of refactoring and adding some new key functionality. Matthew asked me to create a simplified Action Type in addition to the one that was all in place, basically just the same actions without PRESSED and RELEASED. Since we still wanted the original structure to be there, all I had to do was cast the "complex" actions to "simple actions. Matthew then asked if I could convert that SimpleAction type into a matrix, so we could have a clearly defined Y. This was also incredibly easy. I am actually quite happy with how it works as well. All you have to do to create an array for the action is two steps! matrix = numpy.zeros(26) if action is not SimpleAction.INVALID:     matrix[action] = 1; The 26 is the number of different Simple Actions we have. Then, to make it so we can run the parser separately from the Agent, I made it the replay can output numpy files for each character where each row in the file contains the frame of...
Post a Comment
Read more