Opinion: What's In A Game?

[In this technical, reprinted #altdevblogaday-opinion piece, AI game researcher Luke Dicken looks at what goes into actually playing a game, examining the process by comparing it to the challenges that participants face in the StarCraft AI Competition.] Have you ever stopped and thought about what it actually takes to play a game? I'm not talking about at a high-level like in an eSports league; I mean literally, just making something happen within this virtual world. The reasoning process that goes into that is actually kind of astounding when you start breaking things down and digging into it. So, guess what I'm going to do next… It's been on my mind a bit lately because I've been working with one of my students on an AI player for StarCraft, with a view to entering (next year's) StarCraft AI Competition. For those of you not familiar with how the competition, a couple of years ago, some very smart people put together a framework that could hijack StarCraft and take control of the player's units. This meant that for the first time ever, it was possible to write third party AI routines to play StarCraft. I don't know for sure that this was the first AAA RTS game to enable this, but it certainly seems to be the most popular game to have this done, and it has been the most successful. So, we have a situation where hobbyist bedroom developers and students can sit down and design AI, so some people decided it would be fun to organise a tournament, and it's now part of the Artificial Intelligence and Interactive Digital Entertainment (AIIDE) conference. The "Brood Wars API" (BWAPI) injects itself into the StarCraft process somehow (the mechanics of this are quite a bit above my head) and allows your code to take command, with the API exposing a variety of features of the gameworld, if not in fact everything that you might ever want to know. It runs in C++, but there's also a "client" system that allows other applications to hook into the process and interact with it, so it doesn't require strong C++ foo to work with. It's actually fairly easy to get up and running in other languages too – Java being the one I'm familiar with as a member of the JNIBWAPI project doing just that. Interactions back to the game take the form of orders, what unit you want and what you want it to do – perhaps move to a set of coordinates or attack an opposing unit. Games can be played with full information (bypassing the fog of war) or without. It's a pretty robust system that lets you get down and dirty writing AI for a game we all know and love, without the overheads of trying to build a clone of the game, or bothering about graphics and balance. For AI developers, it's pretty close to paradise, inside a really awesome playground. That is itself inside a candy store. But it's tough. The amount of reasoning that we do as humans it turns out is significant when we play a game like this. We're juggling a variety of concepts. Consider just building a new unit, say the human's worker, the "SCV". First of do you have enough resources? Next do you have enough "supply" or population space to construct this unit. If you don't, you'll need build a "Supply Depot" to get more space. But after you start building, you also need to be aware that you've started building one so you don't spam requests for a lot of them at once – it will take a while for the first one to come online and give you what you want, so you need to remember that you've got one coming and be patient. Even just creating this building is tough – you need to position it so that it's clear of everything else, ensure that it doesn't interfere with access to important areas of your base and that it isn't, for example, interfering with your resource gathering. When you break down even the most simple of tasks, such as allocating workers to gather resources, its something that humans can do fairly implicitly, but the logical process behind it is murky at best. More abstract concepts like the rate of change of our resource stockpiles can be evaluated with a glance, while for a machine these take all sorts of support systems to track, primarily due to the AI's discrete frame-based sense of time. In many ways, it turns out that this is a follow-up to my last article where I tried to answer questions Richard Fine had about feature selection for Game AI. I talked there about representing things not in absolute terms but with fuzzy and abstract representations. For example, it doesn't matter that I have 32 SCVs; what matters is I have a lot or maybe enough -- later on as things change, maybe 32 will become not enough, but as much as 32 might be not enough, it's unlikely that 33 will be enough -- these discrete steps probably don't exist. Equally, do players think in terms of concrete locations when choosing locations for new buildings, or do they think about placing them "somewhere over there"? It feels like mechanically, thinking about the game world in terms of absolute truths and concrete values isn't how humans deal with it. With this many units on screen, the amount of clicking involved can be intense.At the same time, though, one thing that is true is that faster players tend to win. In StarCraft, there is a metric known as Actions Per Minute, which reflects how fast you are issuing orders. Although APM isn't the sole deciding factor, and some of the fastest players are not considered top-tier, a strong player will generally have a much higher APM than a weak player – in fact one of the standard mods for StarCraft is a monitor for your APM that alerts you when you drop below a certain threshold. The default value for this is 60.5 APM, although some of the top ranked players of StarCraft approach an APM of 300 (and in the interests of full disclosure, I manage to keep mine at around 30…). Bearing in mind that's counting clicks and actual orders, not intended orders (and an AI player doesn't miss when trying to click), we know that we're probably not going to need to keep up with these blazingly fast guys. 300 APM shakes out at 5 actions per second, which translates to 200ms per action. In terms of Game AI, that's an eternity, and we're probably not having to work even that hard to keep up! This suggests that the problem in making bots for StarCraft isn't one of horsepower; it's almost entirely in this question of representation, both in what aspects of the world we are exposing to an AI and how we are asking it to use these aspects. This is unfortunately another statement about what I wrote about last time, and Richard's questions about general approaches to representing features to AI systems. We've still not got a good solution, but I think that the StarCraft AI Competition is going to help us get there – for RTS games at least. What I really want you to take away from this post, however, isn't really to do with the AI stuff directly. What I want you to do is take a long hard look at what you actually are doing and thinking when you next sit down with a game. Like a dog walking on its hind legs, the amazing part isn't that we can do it well – it's that we can do it at all! It's important to note, as something of a disclaimer, that the competition is aimed at building strong (as opposed to realistic or believable) players. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]