< Back to Index

Posted April 22nd, 2020

This is a brief post about a paper I've put up on arXiv. If you just want the paper, click here!

Research Impact

Getting everyone - not just researchers or business leaders - involved in the process of making new research accessible and useful is really important for two reasons. The first is that some research can’t simply be made profitable, but is still useful, valuable or interesting to people. We can’t rely on profit alone to guide decisions like this. Social impact and academic impact are both metrics for evaluating research too, which helps a bit, but industrial support is an amplifier and so profitable ideas tend to get seen, shared and heard more.

The second reason is that profitability usually isn’t the best guide for how to apply a research idea most effectively. Often our desire to use something to turn a profit outweighs other factors like who it impacts or where it could do most good. One of the aims of my current research fellowship is to investigate how AI game designers might impact the modern games industry. A lot of people are already worried about how technology might make their jobs harder, more exploitable or simply erase it altogether.

While there's no reason to panic right now if you work in the games industry, it is absolutely the right time to start talking about this, planning around it, and scoping out the future together. AI-assisted game design isn’t as far off as my AI's broken nightmare hellscapes might make it seem, and it’s important that we act now to explore how it might happen, talk with the people who will be most affected, and think about how this research can find its way into the hands of everyone who makes games, big or small.







Code-Driven Automated Game Design

Over the past six months I've been working on several new AI game design projects. These systems are smaller than an ANGELINA, but are designed to demonstrate a new way of working with AI game designers with a blurrier line between the AI system and the game you're working on. The idea is to develop a new framework for automated game design, designed to work alongside a team of people who are making a game. I currently call these new systems code-driven automated game designers which is a bit of a mouthful, but the aim is to underline the most important thing about them: they work directly with game code.

What this means is that instead of having a separate AI tool, or a new special language like ANGELINA uses, or having to rewrite your game in another engine so an AI can work on it, you can instead attach this automated game designer directly to your code. Its understanding of your game design comes from what's in your codebase, as well as extra annotations you leave for it in-code that add information to help it put things in context. Importantly, these systems are designed to be secondary to a team of people, not to work alone like ANGELINA. The key aim here is to support people, not replace them.

Writing up how these systems work is a story for another time - it's in-depth, and will require a couple of papers. They aren't making games that I really feel happy with yet, and I'm sidetracked on other research work so they haven't been worked on for a little bit. However, even though I don't have results from the systems to share with you, I've already discovered a lot of fascinating things about building AI systems that work so closely with real game code. My process was to write a game first by myself, and then attach my system afterwards, and I noticed that even the smallest engineering decision on my game code woudl have a big impact on the AI system.

This led me to write a somewhat vision-flavoured paper which I’ve submitted to IEEE’s Conference on Games. In it, I explain that if an AI needs to read and understand your game code, it might need you to change your software engineering habits in order to have the clearest, cleanest conversation with the AI. In the future we might need to make tradeoffs between code that people can read easily, and code that AI can read easily, which is an interesting problem to study! If you're interested in software engineering, AI game design, or just making games, you might like to read the paper - there's a link just below.

Read More

This is early days, and I have a lot more to say about this line of research. But if you’d like to read the paper, I’ve put a version on arXiv, which you can get here. If you make games, of any size, with any tools, for any reason, I'm interested in hearing your thoughts on how you'd want AI to help you (or stay out of your way). I'll be doing a lot more on this topic in the coming years. Thanks for reading, and I hope to share some games with you later in the year!