So why not use Matt's version for SC2 that doesn't provide map hacks?

https://graphics.stanford.edu/~mdfisher/GameAIs.html

I imagine it also has something to do with convenience. Being such an old game, the technical requirements are quite low, which allows them to easily have that setup of multiple virtual machines on a few servers. Also, I believe they can use the same CD Key for each instance, and it doesn't require a connection to the internet, reducing variables and potential problems.

That said, it would be cool to see SC2 for this, and maybe we'll see it eventually. But I think Blizzard would have to allow it in the end, considering they've been in direct contact with them about this.

Maybe they didn't know about it? First I've heard of it.

Looks really great. I hope they look into this.

Using that on Battle.net violates the TOS. So your account will get banned if you do that.

It has always seemed to me that there is a truly "proper" way to construct an AI 'bot' for a networked game, and that is to write your own headless game client software that connects to the game's network—emulating the physics well enough to avoid desynchronization with one's opponent, but otherwise being entirely its own program, rather than having anything to do with the reference client per se.

It's really really hard even for developers of the actual client to avoid desyncs. Trying to reverse engineer the exact physics engine down to the bit would be a massive achievement technically in itself, I'd say.

This is, of course, because being a good game developer doesn't make you a good network programmer.

In the MMO sphere, where the people being hired for development tend to have a decent grasp of how networking is supposed to work, you don't see the "reference client" being developed until quite late—first you get a server, and a client library that does enough physics and network-messaging to appease that server. Then both integration test suites for the server, and the reference client, are written in terms of that library. Thus, the "business rules" of the game's simulation are forcibly decoupled from the particular UI used to present them.

You can tell when a game team has hired some good network programmers, because—at least if the game is a competitive one—the game will have "match recordings" that are able to be replayed on reference client versions newer than the one used to create them. This is true of SC2 (and false of a ton of other games, even much more recent ones like, say, Super Smash Bros U.)

How do they do that? Simple: they keep all the old versions of the "business rules" simulation library around together with the reference client, with a stable ABI such that the newer client can load the older library versions. When you want to watch a match recorded for a given simulation ruleset, it loads the relevant simulation library.

So, if there exists such a library for your game, you don't have to reverse-engineer the entire client; only the library. Mind you, you could just use the library, the same way the reference client does; but the low coupling makes such a library also much easier to analyze and reverse-engineer. So both options are on the table for SC2 in a way they aren't for most games.

That would be an order of magnitude more work though, right?

Is it problematic to capture screen and generate mouse/keyboard input?

In that way there would be no need of any privileged API... and it would be more natural (i.e. interacting with the real way, instead of its abstracted version).

Indeed, DeepMind has already demonstrated mastering a game using only screen input and controller output, e.g., Breakout https://www.youtube.com/watch?v=V1eYniJ0Rnk

writing API library based on screen capping is what, 100? 200 man hours job?