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

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

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

Matthew - Blog Post 8

replaymanager.py is only 339 lines long but it feels at least three times that when I'm working on it. The module is definitely due for a refactor. For one, the term subdataset should be renamed to version_set and extracted into a class. version_set more accurately and describes what it is, and the class extraction would clean up the namespace in ReplayManager. There is probably some kind of class extraction possible for replays, so that their names, paths, file streams, and Twitter profiles can all be neatly encapsulated, thereby cleaning up the namespace even more. However, I do not want to worry about having two kinds of replays: the one used by ReplayManager and the one used by ReplayParser. Even though ReplayManager does not use ReplayParser, the prospect of making things more muddier deters me. There's probably a right way to refactor this code, but, to put it simply, now is not the time. Speaking of time, I came up with a great way to get work done, even when I am slee
Post a Comment
Read more