Starcraft documentation.

[Kyukka]

I would like to find some info on how Starcraft does LAN connections and ingame communication, like attacking, moving etc.

I'd like to try whether I can create a program that joins a LAN game and does some stuff in it (actually, for starters, just a program that can take commands similar to what you have at your disposal in regular starcraft from another overlying program).

I think if there is good documentation on this like there is on Battlenet packets, it'd be doable, but if I'd have to analyze and decipher every packet by hand, it'd be nearly impossible to do.

[iago]

It's a fairly ifficult and intricate protocol.  It's based on UDP communication that simulates TCP's reliability.  As far as I know, nobody has ever worked on it publicly before. 

Your best bet is to start reverse engineering Starcraft.exe and Storm.dll.  Good luck!

[Kyukka]

Hehehe.

I've got some knowledge on network communication (I've built a TCP protocol, a fairly simple one missing lots of functionality, but it gave a lot of insight), but reverse engineering I know squat about.

I suppose I could research on it, but with documentation I could produce something that could actually do something in a not too huge amount of time, whereas with something like this, I think it'd cost me at least a year to get a general idea of what is going on, and then another to fully and precisely document it.

Reading disassembled Starcraft code is probably not as instantly insightful as a TCP protocol RFC...

[iago]

No, it's not.  I did some reverse engineering on it, and I got a headache fast.  It's nasty. 

They re-implemented stuff like SEQ/ACK, and Checksums, and all the other fun stuff.  Adron and some others might be able to give you some more insight.  In fact, I remember them posting a pretty good overview of it somewhere, but I wouldn't know where to start looking.  Maybe search Adron's posts for "udp" or something.

[Kp]

Just a quick warning: don't even try to make an SC gamebot that can actually play independently.  Every client runs the entire game, so your bot would need to have some way of visualizing the map and modeling all the units based on what the other clients told it.  Essentially, you'd need to reimplement Starcraft's game engine.  Making a gamebot that sits on top of Starcraft and issues commands to it is viable, if you know what commands you want to do.

[iago]

It's not impossible to make a bot that can join and sit in a game.  I know Skywing did it.  It keeps itself in a base state, and never tries to do any actions

What kp suggested is much more possible, and useful, though.

[Kp]

It's not impossible to make a bot that can join and sit in a game.  I know Skywing did it.  It keeps itself in a base state, and never tries to do any actions

Right, and that's about all that you could do without implementing some substantial part of SC's engine internally.  If you want to take any action, you need to know what unit(s) you're commanding, where to send them, etc.  All that requires the game engine.

What I'd meant when I said "play independently" was to play without a Starcraft client available to the bot.

[Kyukka]

Yeah, I know about the independent game bot requirements, you can conclude that from the replay files, which are also merely a collection of commands. SC communication is logically the same kind of thing, just commands.

However, even if implementing it on top of SC, I still doubt it'd suddenly be easy to know exactly how the map looks and where the units are.

[Kp]

However, even if implementing it on top of SC, I still doubt it'd suddenly be easy to know exactly how the map looks and where the units are.

Hence the need for some leaps of faith.   Units know where they are, but I've never located the underlying terrain structures.