Skip to main content

Matthew - Capstone Blog Post 2

In Towards Integrated Imitation of Strategic Planning and Motion Modeling in Interactive Computer Games, Dublin City University researchers Bernard Gorman and Mark Humphrys detail their experiments in using imitation learning techniques to teach an artificial agent to play a first person shooter—in this case, Quake—in a way that would convince onlookers and other players that it is human. They describe a superior agent, which imitates "the observed goal-oriented behaviors of a human player," (p. 2) in order to play with competence, exhibit strategic thinking, and employ "believably human-like motion" (p. 1). In other words, they want to create a bot that can pass a kind of Turing deathmatch.

Gorman and Humphrys describe the behavior model which serves as the basis for their work. The model specifies several levels of control, where each level corresponds with roughly how much time the agent has to form a plan. These range from immediate ("scrambled control") to long-term ("strategic control"). Furthermore, their model relates these levels of control to three kinds of behavior—strategic, tactical, and reactive—which together are supposed to form the building blocks for an agent's motion modeling capabilities (p. 3).

In their experiments, Gorman and Humphrys emphasize the "human-like motion" mentioned above. Specifically, they limit their agent's problems to those of environmental navigation and item acquisition. Their methods involve topology learning (p. 3), Markov decision processes or MPDs (p. 4), and motion modeling based on "action primitives." The action primitives, the recorded gameplay, and relevant state space information comprise the training data (p. 6-7). They applied their agent in two types of tests: "pickup sequence" tests, in which the agent must pick up a series of items, and "continuous gameplay" tests, which were of a more free-roam nature (p. 8-9). The researchers noted that the agent performed "showed impressive performance and adaptability" during the pickup sequence tests (p. 8). Otherwise, they noted one issue in the continuous gameplay tests: the agent would sometimes struggle to choose among competing utilities (p. 10-11).

Gorman and Humphrys note in their conclusion that their work relates closely to that of Christian Thureau of Bielefeld University. They mention several works from this author throughout the paper. Please consider joining me next time as I explore this researcher's work.

Comments

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

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)