Re: [Widelands-public] AI and networking

[Nicolai H. <pre...@gm...>]

On Friday 24 September 2004 16:08, Si...@gm... wrote:
> > Game logic simulation is blocked by player commands. So if we have not=
=20
> > received commands from all players for a given point in time, we cannot=
=20
> > simulate the game beyond this point.
> What happens then? A "waiting for player" message and the game stops?

Note that this is actually perfectly normal in the early phases of the game=
=2E=20
When the game starts, all hosts agree on what the initial game state looks=
=20
like. Then they start sending player commands immediately, but of course=20
game simulation cannot begin yet. Within half a minute of play we should be=
=20
able to figure out a reasonable (local time - gametime) difference,=20
although we should adapt this difference over time in case the network=20
behaviour changes.

Now as I mentioned before, there needs to be a user-definable upper limit o=
n=20
the difference between local time and gametime. We enforce the limit by not=
=20
sending anymore player commands if the difference becomes too high [1] If=20
we are blocked that way for more than a second, pop up a warning message.
=20
> What about anti cheating? Some ideas. If all hosts share all data,
> cheating should be easily detectable and avoidable (When something
> impossible is done, like producing a ware though this building should
> work for another minute).=20

Rule cheating, yes. A simple idea that was in the back of my head is to kee=
p=20
a CRC checksum of executed Cmd_Queue commands. So whenever the Cmd_Queue=20
executes a command (player command or CMD_ACT), it feeds the current=20
gametime plus e.g. the serial number of the Map_Object in question to the=20
CRC algorithm. We exchange CRCs once a second to detect desyncs and rule=20
cheat attempts. [2]

Unfortunately, we can't prevent knowledge cheating.

> I played wesnoth yesterday on the net and we had some serious
> out-of-sync problems while playing. I wonder how hard a time we will
> have if a round based game like wesnoth is unable to stay in sync....

We *must* implement recording functionality and tell all players to always=
=20
record their games. Combined with CRC checksums, this can be used to find=20
out where the desync happened.

I'd love to do all this, but I'm currently in the middle of another huge=20
project (the R300 DRI driver) which is unfortunate :/

cu,
Nicolai

[1] This means the limit must be high enough for the connection, or there=20
will be *horrible* stuttering.

[2] Note that this will only desync when the cheat actually makes a=20
difference. Locally increasing your stock of wood from 1000 to 20000 makes=
=20
no gameplay difference, so it will not cause a desync - unless we have an=20
algorithm that tries to move the wood to a different warehouse for=20
balancing.