Skip to main content

Rei - Blog Post 7

Since the beginning of the semester, Matthew and I have been woking hard on the Replay Parser and Frame Collector. Both of these parts are crucial to the success of our project. With the first Demo of our project done also comes the completion of this first milestone.



Parsing the replay exposed some interesting information to us about how inputs are recorded, and therefore how the game sees them. Our original understanding of inputs was that multiple inputs would actually be spread out across multiple frames, however this was not true. It turns out that a frame is followed by a list of events which take place on that frame. We also learned that some human actions translate into multiple inputs. For example:

If you are using the control stick to move your character and you hold right on the control stick, your character moves right. One may think that this means the action RIGHT_PRESS is input, in actuality a list of actions is generated.

The list may look something like : {ANGLE___0, RIGHT_TAP, RIGHT_PRESS}.
Where: 
    ANGLE___0 means that a control stick is being held right.
    RIGHT_TAP means that the right action has been tapped. (Starts the Run Action)
    RIGHT_PRESS means that the right action has been pressed. (Continues the Run Action)

This is important to note the angles as using it means that Actions that take place in different directions can happen simultaneously. (Moving Right while Attacking Up).

The source code for the parser can be found here. I plan to add in-depth documentation for this python code in the GitHub, I also hope to upload the code onto PiPy as a module so it can be added to a python environment directly with pip.

Because this is the first replay tool for Rivals of Aether that I have seen, I would like to release it back to the community that helped make this project viable.

Finally, the last thing that I did during this break was create the Demo for out project. This involved packaging together frames and action sets. This was actually quite an easy task, because of all the preemptive work Matthew and I put in. The frames were already synced pretty well with the replay file, after some minor adjustments it was pretty much perfect.

As stated earlier, the code for the demo is quite simple. It follows a very simple set of actions:

  1. Create a list.
  2. Grab all the frame .npy files.
  3. For each .npy, create a tuple (frame_num, frame) and add it to the list.
  4. Grab all actions from a replay file.
  5. For each action, create a tuple (frame_num, action) and add it to the list.
  6. Sort the list by the first element in the tuple.
  7. Pair actions with the nearest frame following them.
Then, in order to present the pairing. We just output the frame to a png, and the action_list to a .txt, both of which can be read by other programs. When we want to move on to the next frame, we overwrite the temp png and txt.

The source code for the demo can be found here.
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

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