Skip to main content

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 phase one goes as it should we will hopefully not be too overwhelmed. Having to go back and research during the next semester might be disastrous depending on the circumstances.

In order to protect ourselves from our own project, we aim to design a modular system. By this I mean that the AI will have "central executive" or core platform for general learning and decision-making which will take input from other, more specialized submodules. For example, we may decide to use a scene segmentation submodule. By taking this approach we can control the scope of our project by adding or cutting features as needed. Our worst case scenario would likely involve converting a failed project into a paper, such a literature review or postmortem depending on how we are advised.

How phase two goes depends substantially on what we do now. I am aware of two general approaches that are available to us at this stage. One of them, the literature review, involves investigating how other researchers have tried to solve the same problem or similar ones. The other, a technology assessment, consists of selecting a specific tool or technique and then determining how we might use it. The former can be difficult because there might be a lack of extant work, or their might be an unmanageable excess. It has the advantage of helping us avoid reinventing the wheel or falling into known pitfalls, though. To contrast: the latter might lead to innovative solutions, but it might also bring unforeseeable risks and challenges.

So far, Rei has pursued the route of technology assessment. Hopefully I can complement their excellent work with a detailed literature review. That will have to wait, however, because I am simply not there yet. I have collected a small body of relevant literature to look into. One of the documents I have is about an AI that learned to play Quake through imitation learning. The researchers' goal was to ensure that their AI played in a way that resembled how a human would, with natural movement and strategic planning. I also intend to read the ViZDoom papers, which should offer a variety of approaches to the problem of making an AI play Doom competitively. Beyond those papers, I have several others that address less holistic problems, such as moving target search. Overall, I think that the extant literature will prove manageable; there is an excess relating to technologies that might prove useful, alongside a comfortable amount relating to our particular problem.

Our biggest challenge, by far, will be learning as much as possible in a short amount of time about a topic that is not especially safe. We will have to contend with our own inexperience and lack of knowledge in the face of one of the bleeding edges of computer science.

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

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

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