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}.
    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.


Popular posts from this blog

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 …

Rei - Capstone Blog Post 1

Over the past couple of weeks, Matthew and I have been trying to narrow down our idea for capstone. We have settled on a "Modular" AI that can play First Person Shooters or other similar video games. However, we decided to put a slight twist on the idea of an AI playing games. Most of the AIs that are currently out have more information than they should possibly have at that time, like the location of players. We decided that our AI would only have information that would be accessible to a human player. We also noticed that many of the "PlayerAIs" out there are reactionary, not planning. While reacting is a key part to many of these games, so is strategy. We want to create an AI that thinks, at least a little bit, about that actions it is making or should make.

Since narrowing down our topic we have split off and started looking at different existing technologies and research that could help us understand and create this project. I decided to look at some computer…

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 descentalgorithmsdo, 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 …