Skip to main content

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 descent algorithms do, 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 understanding of the actual math behind them.

Overall, I feel like every step I take demystifies machine learning. Do my steps also deromanticize it? Perhaps a little. Somber piano music is playing on the radio, though, so take everything I say here with a grain of salt.

Before I let myself follow this train of thought any further, I really should think of our advisor, who I know would feel better if he saw some sign that we were working on our design document draft. And so, without any further ado, I hereby present our title page:

Note: Title pending review.

Should it be "the thrill of" or "the rush of"?
Anyway, never fear, for I have worked on more than just the title page!

Irrevocable proof that I installed a LaTeX compiler.
Fancy chart showing essentially the same content as the other screenshot.

And that is enough for one blog post. After all, every character I type here is a character I could be typing in the design document.

Comments

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) is simply assigned …

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 sleep…

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 promis…