Cheating, Hacking. How much?

[SlowThinker]

First to clear some things:
I see these possibilities:

• 1) There is no server, only clients. Clients not only take actions of players, but also process them, then send deltas to other clients. (I suppose this is the case of Wesnoth?)
• 2) There is a server and clients. Clients only pass player's actions to the server. The server processes them, and sends deltas to clients:
  • 2a) the server sends full deltas and so shares all world state information
  • 2b) the server sends a visible information only

BTW all RTS games must use "my" system, these games need more resources, so they are much more vulnerable to the attacks, and still they exist contentedly.

With this sentence I wanted to say option 1) was not possible with RTS (I admit I said something else, and also it didn't work as an argument in that context): a client gets the information with a lag and so it cannot process an attack if it doesn't know whether the attacker still lives. (to be precise, option 1) is possible only in "private" map areas that don't interfere with other clients)
I see RTS games can be both 2a) or 2b).

[09:10] <Soliton> you can run into sync issues either way.
[09:10] <Zarel> True

I don't see the point. IMHO 1) requires a synchronization, while 2a) and 2b) don't. There is nothing to synchronize in case only the server processes all events (only reason you may want to synchronize is to find bugs in client and server applications)

[09:10] <Zarel> ...it's easier when clients have complete information.
[09:10] <Zarel> Since you can just push deltas out to everyone.
[09:10] <Zarel> And not have to push different deltas to each individual client, and then store knowledge information about each individual client from which to push deltas from...

Hm, in case the information is filtered the server does stuff that the client would still have to do.
And it looks to be easy. For example Wesnoth: the server just stores a visibility status for each hex (shroud, fog, terrain visible but not unit, fully visible) and for each side, and filters the deltas according to the visibility status. This is demanding neither to memory nor to CPU.

[Soliton]

[09:10] <Soliton> you can run into sync issues either way.
[09:10] <Zarel> True

I don't see the point. IMHO 1) requires a synchronization, while 2a) and 2b) don't. There is nothing to synchronize in case only the server processes all events (only reason you may want to synchronize is to find bugs in client and server applications)

If there is nothing to synchronize how can there be bugs/errors that you can spot with synchronization? What do you think out-of-sync errors are anyway?

[09:10] <Zarel> ...it's easier when clients have complete information.
[09:10] <Zarel> Since you can just push deltas out to everyone.
[09:10] <Zarel> And not have to push different deltas to each individual client, and then store knowledge information about each individual client from which to push deltas from...

Hm, in case the information is filtered the server does stuff that the client would still have to do.
And it looks to be easy. For example Wesnoth: the server just stores a visibility status for each hex (shroud, fog, terrain visible but not unit, fully visible) and for each side, and filters the deltas according to the visibility status. This is demanding neither to memory nor to CPU.

I'm curious, is there anything that you would consider demanding? Have you actually implemented one thing you're making arbitrary judgment calls about in this thread?

[pauxlo]

First to clear some things:
I see these possibilities:

• 1) There is no server, only clients. Clients not only take actions of players, but also process them, then send deltas to other clients. (I suppose this is the case of Wesnoth?)

In the Wesnoth case, there is a server, but it only forwards deltas from one client to others (and keeps a memory of them for later added clients and the replay save). And it generates random numbers for all clients.

[SlowThinker]

If there is nothing to synchronize how can there be bugs/errors that you can spot with synchronization? What do you think out-of-sync errors are anyway?

I said I expected Wesnoth was done according to option 1) ("peer-to-peer", see my last post). I think so because Wesnoth reports sync errors and there is nothing to synchronize if option 2) ("server-client") is used:

With option 2) there is one world only (the one on the server), other worlds are just copies, so there is nothing to synchronize. (The copies may contain errors if server or client are buggy, or if the client is changed (hacked). You might want to verify this, but this is not a synchronization)

So I suppose Wesnoth uses option 1). But even with this option synchronization is not a must:
You don't have to synchronize, if you assure that all clients use equal starting conditions: equal data (equal starting world: map, gold, recruitable units, other variables...) and equal procedures (WML macros). Processes in the world are deterministic (supposing equal random numbers are used), and so all next iterations of the world remain equal.
Wesnoth creates OOS, so apparently equal starting conditions of the clients aren't verified. I suppose this is because files of some MP scenarios are very large, the data that need to be verified are not separated and so all files would have to be verified. (It would be sufficient to verify data and procedures that define the world, but Wesnoth doesn't separate them from data and procedures that create the human interface (e.g. graphics, messages). Am I right?

I'm curious, is there anything that you would consider demanding? Have you actually implemented one thing you're making arbitrary judgment calls about in this thread?

I implemented nothing related to computer games. I am not a professional programmer and my programming experience is quite low. But I can imagine what exactly is needed in order to filter the info passed to clients according to the visibility:

The server has to store the info visible/unvisible (also fog, shroud etc. in case of Wesnoth) for each hex and each side (a very low need of memory). This serves as a mask when the server sends deltas: for example if the delta is a unit move between two adjacent hexes, at least one hex must be visible in order to pass the delta to the client.
There is one thing that requires more CPU time: the moment when a unit moves and the server must re-adjust visibility:
the server must count which hexes were visible from the previous unit's position and which ones are visible from the new unit's position; the demandingness of the algorithm is O(ln(n)*sqr(n)), where n is speed of the unit. I didn't try to count how many simultaneously moving units of speed 50 would load the processor adequately, but I estimate the number would not be low.

1) There is no server, only clients. Clients not only take actions of players, but also process them, then send deltas to other clients. (I suppose this is the case of Wesnoth?)

In the Wesnoth case, there is a server, but it only forwards deltas from one client to others (and keeps a memory of them for later added clients and the replay save). And it generates random numbers for all clients.

Isn't the way of a net communication you explained called "client-queue-client"?
But I think we use the term "server" for several things, which is confusing.
In several last posts I understood the term "server" not as a physical computer, but as an application that offers a service. This service is the computation of the status of the world and distribution of delta information to the clients.
(That server (service) may be a part of the Wesnoth application of one of the players, or the server may run on the Wesnoth game server)

My question was whether the computations of the world status are done centrally (by the server/service, case 2 in my last post), or whether this work is distributed among all participants of the game (case 1).

[Gambit]

In several last posts I understood the term "server" not as a physical computer, but as an application that offers a service.

It is still on a physical computer though; one with limited resources and other programs.

[Zarel]

I don't see the point. IMHO 1) requires a synchronization, while 2a) and 2b) don't. There is nothing to synchronize in case only the server processes all events (only reason you may want to synchronize is to find bugs in client and server applications)

There's tons to synchronize in 2a and 2b. You're confusing "the entire map doesn't have to be synchronized" with "nothing has to be synchronized at all". If nothing were synchronized at all, you wouldn't be playing a multiplayer game in the first place, would you?

[SlowThinker]

There's tons to synchronize in 2a and 2b. You're confusing "the entire map doesn't have to be synchronized" with "nothing has to be synchronized at all". If nothing were synchronized at all, you wouldn't be playing a multiplayer game in the first place, would you?

I was more detailed in my answer to Soliton (Posted: Tue Feb 16, 2010 1:04 am).
Can you tell me what is wrong in that answer, or tell me an example of that tons of stuff to be synchronized?

(And I believe sending deltas from the server to clients and user's actions from clients to the server is enough to play a multiplayer game.)

[Pentarctagon]

How much ram does the server have anyways? 3gb at most I imagine.

i dont think anyone answered this so far, and i am genuinely curious about how much ram the wesnoth server has.

[Zarel]

All you say w.r.t. that is here:

With option 2) there is one world only (the one on the server), other worlds are just copies, so there is nothing to synchronize. (The copies may contain errors if server or client are buggy, or if the client is changed (hacked). You might want to verify this, but this is not a synchronization)

If other worlds are just copies, then those copies must be synchronized.

I think you misunderstand what the word "synchronize" means.

I implemented nothing related to computer games. I am not a professional programmer and my programming experience is quite low. But I can imagine what exactly is needed in order to filter the info passed to clients according to the visibility:

Yes, well, so can I, but I bet the devs can assess the amount of effort required better than you can. They have already determined the amount of effort to be disproportionate to the small benefit received.

[Max]

My question was whether the computations of the world status are done centrally (by the server/service, case 2 in my last post), or whether this work is distributed among all participants of the game (case 1).

why not ask such essential questions prior to getting in such a lengthy discussion?

[SlowThinker]

If other worlds are just copies, then those copies must be synchronized.

It looks we don't understand one another. I will express my thoughts again and another way:

At the game beginning, the server sends world status (StartingWorld) to the client. The client has a full info and no synchronization is needed.
Then server sends delta1. The client has a full info about the world (the world status is StartingWorld+delta1) and no synchronization is needed.
Then server sends delta2. The client has a full info about the world (the world status is StartingWorld+delta1+delta2) and no synchronization is needed.
etc.

The synchronization is needed when the server doesn't send StartingWorld at the start, the client has its own instance of the starting world, and so it is not assured whether they are equal.
(I suppose this is why Wesnoth creates OOS, see my answer to Soliton above)

[Gambit]

Murhpy's law.

[SlowThinker]

My question was whether the computations of the world status are done centrally (by the server/service, case 2 in my last post), or whether this work is distributed among all participants of the game (case 1).

why not ask such essential questions prior to getting in such a lengthy discussion?

This question originated during and thanks to that lengthy discussion.
Now a more essential question for me is this one:

Is my estimation why Wesnoth creates OOS (http://www.wesnoth.org/forum/viewtopic. ... 27#p410427) correct?

[ilor]

Wesnoth doesn't "create" OOSes. In fact whatever method of MP gaming you have, "OOS" can still happen one way or another.

To answer your question: wesnoth works by having each client maintain a game state and change it when that player moves, and when other players move on their turn. OOS errors happen generally when the actions sent from another player are invalid in the state the receiving player has. This does not happen often, unless there are bad network problems, outright bugs or data file inconsistencies / cheating.

The server is responsible for relaying messages and actions between players, and does not have to maintain a game state at all, only a log of actions (ie the replay).

[Zarel]

It looks we don't understand one another. I will express my thoughts again and another way:

At the game beginning, the server sends world status (StartingWorld) to the client. The client has a full info and no synchronization is needed.
Then server sends delta1. The client has a full info about the world (the world status is StartingWorld+delta1) and no synchronization is needed.
Then server sends delta2. The client has a full info about the world (the world status is StartingWorld+delta1+delta2) and no synchronization is needed.
etc.

The synchronization is needed when the server doesn't send StartingWorld at the start, the client has its own instance of the starting world, and so it is not assured whether they are equal.

Yes, well, sending deltas is a method of synchronization. This is mostly just a semantic argument, though.