[greedy_buffer]

> Starcraft is a continuous game and the game state is not 100% known at any given time.

It seems to me that multiplayer games may feel continuous to a human player but are still designed around a series of discrete states called ticks where each tick is determined from the previous state plus inputs.

Why is this distinction made in the context of how difficult it is to develop an AI?

[teraflop]

Technically you're right, but there's a real qualitative difference. Each "tick" in a game like StarCraft is on the order of tens of milliseconds. When you send out an army to attack your opponent, it's quite possible that the actual confrontation won't happen until 10,000 ticks in the future.

Also, the dimensionality of the state space in a "continuous" game is orders of magnitude larger. In a game like chess or Go, you may have dozens or hundreds of moves available at each turn, but only a few of them will be "locally optimal". In StarCraft, there are many more degrees of freedom -- attack timing, positioning, formation, banking versus spending resources, and so on. A good AI will need to be able to abstract that huge state space down to something more tractable.

[gambler]

To the best of my knowledge, the only thing in SC2 that requires pixel-level precision is selecting units. Everything else can just as easily be represented as a fairly coarse grid with no loss of expressiveness. Buildings are explicitly snapped to a grid, and moving your units several pixels to either side simply doesn't matter. So calling SC2 "continuous" in terms of space is misleading.

I don't think there is anything that requires super-fast response times either, so you could conceivably get ~1 frame per second and not lose much information.

Well, IIRC, there are some visual indicators that rely on blinking, but I don't think they are crucial.

[smallnamespace]

Even with the restrictions you put in place, SC2's state space is much larger than any board game.

A typical game might last 15 minutes = 54000 60fps frames and a typical map is larger than 10k x 10k in terms of 'coarse units'.

For any given frame of animation there are at least a million valid actions - if you have 10 units then you can move any subset of those units to any place on your screen.

[gambler]

>Even with the restrictions you put in place, SC2's state space is much larger than any board game.

That depends entirely on how you represent it. You're forgetting that there are plenty of AIs that actually play the game right now. They just don't use the same kind of "interface".

>For any given frame of animation there are at least a million valid actions

That's Google's marketing cool aid. "Actions" that produce the exact same result cannot be meaningfully counted as separate actions, especially when you're trying to compare them to board game moves.

[jncraton]

You're basically correct in terms of SC not technically being continuous. There are discrete steps under the hood.

One of the significant challenges is figuring out how to use 42ms (the frame duration on fastest speed) of computing time to decide what actions, if any, to take next. You don't have the luxury of taking many minutes to decide one move as you would in a game like chess or go. You also don't alternate taking discrete turns with your opponent, despite having discrete frames. It may be best to not take an action in a given frame. This is particularly true if the AI is attempting to stay under an APM threshold, as it has to decide if an action is worth the opportunity cost.

It is also necessary for a quality SC AI to remember what has happened in the past. A chess board position is identical regardless of how the game got there, but this is not the case in StarCraft. An AI has accumulated lots of information about its opponent that is no longer visible to it in the current frame (unit movements, gas/mineral counts, number of workers active, etc), and this needs to be recalled and play into decision making.

[haeffin]

SC2 ticks faster than SC1 - you only have 22ms. You don't need to tie everything to tick rate though, a strategy module could update way slower.

[giblaz]

Bingo. If this had the tasks split up among multiple threads/processes correctly and using a very fast performing language + good developers, the tickrate is less important. Some army control module could manage the unit micro within the bound of a tick with other modules updating other info the system draws from to perform actions.

[jjn2009]

Its computationally difficult to calculate every possible move a character might do in the occluded region. This requires a long attention span and running simulations of possible opponent actions based on previous 'frames'. Alpha go solved some of this by reducing the amount of space searching and instead search the likely set of possible choices by the opponent but each evaluation is for a single frame. If for some reason a piece on a go board could disappear and reappear then during that time it was gone its impact on decision making would be either nil or skew heavily towards nil compared to the rest of the opponents pieces depending on how many frames in the past are used.