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.