Nework Protocol Hacking - Feasible?

[tristan256]

Ok I don't know much about game network protocols, so this maybe is impossible.

But, would it be possible to packet sniff a lan game to work out the network protocol used by RTW? Like when you move unit forward, would the machine send a packet saying "MOVE UNIT 12 TO 567,788 1"?

Ok so if you could work out how this works, you could write bot players - a program that knows how to communicate with a RTW lan game and all the clever programmers out there could write descent AI algorithms.

It seems that one of the biggest hard coded issues with RTW is the AI - it stinks and theres nothing you can do about it. Would this get around it?

Of course, if the game uses some remote method calling system, DCOM/Corba whatever, then I suppose its not really feasible.

[tristan256]

Damn spell check doesn't check the title hey.

[felix]

You can take a look at the protocol by installing a protocol analyzer like
http://www.ethereal.com/

However, the hard part with writing a bot player is not network related. The bot needs to maintain the game state somehow, and given that the protocol is not a true distributed simulation protocol, but rather a command distribution protocol, you would need a write a virtially identical state machine as RTW. Pretty hard without using the source ;)

Much easier to just write an RTW clone and you'll have full freedom of choice for AI and network algorithms :)

[tristan256]

However, the hard part with writing a bot player is not network related. The bot needs to maintain the game state somehow, and given that the protocol is not a true distributed simulation protocol, but rather a command distribution protocol, you would need a write a virtially identical state machine as RTW. Pretty hard without using the source ;)

Hmmm, I don't geddit. What are "true distributed simulation" and "command distribution" protocols?



Much easier to just write an RTW clone and you'll have full freedom of choice for AI and network algorithms :)


Oh yeah why didn't I think of that before ;)

[felix]

Hmmm, I don't geddit. What are "true distributed simulation" and "command distribution" protocols?

For example, DIS, the Distributed Interactive Simulation protocol used by the US Army.

Another design principle of DIS is that, within a particular configuration, there is no central computer with the responsibility for interaction detection and resolution. This prevents single-point failures from disrupting the overall exercise or mission being supported by a DIS configuration. Each node is responsible for determining its own interaction with the rest of the electronic battlespace. It does this by locally detecting and resolving interactions of the entity that it is simulating with all the other entities on the battlespace. A node communicates any changes in state caused by interactions and resolutions to the rest of the configuration.

To communicate its current status (location, velocity, orientation, etc.) to all other entities within a particular exercise, each entity's host computer broadcasts updates to its status. The receiving entity's host computer takes this status information from all the other entities in the exercise and calculates ground truth. The computer can then determine what can be seen (by either visual or electronic means) by the entity it is simulating and updates displays as necessary.

DIS reduces communication requirements by requiring that each node maintain a simple model for all of the entities on the battlespace that it is not simulating. These entities are called remote entities. Between the receipt of updates from the remote nodes actually responsible for simulating those entities, the local node executes these simple dead reckoning models for those entities to estimate their current state. Each node also maintains a simple model of its own entity's state in addition to the high-fidelity model it calculates. When the low-fidelity model differs from the high-fidelity model by a certain amount, the node communicates its entity state to the rest of the configuration (see Figure 3-1:). This approach allows the local node to update its entity's state locally at a rate dependent on local needs (for example, a 30Hz update rate necessary for a visual system) without overwhelming the internode communication system. Communication of the state of remote entities is an asynchronous action with respect to the simulation processing performed on the local node. Therefore, the dead reckoning algorithms are also used to extrapolate the state variables of all remote entities in order to re-establish the synchronous environment necessary for the simulation of the local entity.

This is a very different approach from that used in the Total War series, where the unit commands are communicated between the hosts and their consequences are syncronized by means of common random seeds.

[felix]

Hmm, just found this

Specifically, you may not host or provide matchmaking services for any of our games or emulate or redirect the communication protocols used by The Creative Assembly or in the network feature of its games, through protocol emulation, tunnelling, modifying or adding components to the game(s), use of a utility program or any other techniques now known or hereafter developed, for any purpose including, but not limited to network play over the Internet, network play utilising commercial or non-commercial gaming networks or as part of content aggregation networks without the prior written consent of The Creative Assembly;

But that is not the licence agreement, so I'm not sure who this "you" referers to. Probably only those who signed up for the totalwar.com forums.

[tristan256]

the unit commands are communicated between the hosts and their consequences are syncronized by means of common random seeds.

Common Random Seeds? Is that like when the client sends a command, it gives it a key so when the server responds the clients knows which command it was related to?

As far as keeping state goes, wouldn't the client have commands it can execute to get the state of the game? Like the list of units, their position, numbers, morale etc?

By the way thanks for the posts, very informative stuff.


Specifically, you may not host or provide matchmaking services for any of our games or emulate or redirect the communication protocols used by The Creative Assembly or in the network feature of its games, through protocol emulation, tunnelling, modifying or adding components to the game(s), use of a utility program or any other techniques now known or hereafter developed, for any purpose including, but not limited to network play over the Internet, network play utilising commercial or non-commercial gaming networks or as part of content aggregation networks without the prior written consent of The Creative Assembly;

Err maybe we shouldn't be talking this ... POOF! *disappears in a cloud of smoke*

[felix]

Common Random Seeds? Is that like when the client sends a command, it gives it a key so when the server responds the clients knows which command it was related to?

Not exactly. The "Unit A attacks Unit B" command is sent from computer X to computer Y and Z. Now, how successful was the attack? E.g. say there's 20% chance that a particular soldier is hit, all computers need to use the same dice roll to see if he is killed. It's not nessecary to send the dice rolls between computers (would take too much bandwidth), but fortunately random generators are not that "random". If you seed them with the same seed on all computers, and make sure they roll their dice in the same order, you'll get the same result everywhere. However, the quantum properties of the electrons sent between the computers can complicate things :dizzy2: So beware of Schrödinger Flaming Pigs!


Err maybe we shouldn't be talking this ... POOF! *disappears in a cloud of smoke*

Oh, pity, it's my favourite topic :)

[tristan256]

Ahhhhhhhhhhhh. So it is partially distributed, I see.

I thought the state would be maintained entirely by the server, didn't realize that the that clients would be doing their own mechanics. I didn't think it would be that bigger problem for LAN games, but I suppose that would be bit of tough on Internet games, and they aren't going to write two different protocols.

Oh well, cheers for the info.

[Simetrical]

There's not really any point in central tracking, even for a LAN. Of course, someone could theoretically hack or mod the game somehow so their units are tougher or what have you, but all that results in is desyncs: my computer says my toughened unit is still alive, everyone else's says it's dead, then I order my unit to attack, and your computer says "WTF? The unit's dead, cheater!" and boots me (or otherwise deals with it).

[tristan256]

As suspected, my idea turned out to a bad one, but in the process I learnt some interesting stuff about game network protocols. Cheers for the info.