So how 'bout those Mets?

[Taqwus]

Odd. I would have thought that a PBEM TBS server-client game design would follow one oft-espoused rule: Never trust the client. If one does follow that, it should be impossible for a client to cheat outside of having a more efficient or useable interface -- and interface modifications are perhaps less unfair dangerous in a PBEM TBS than in practically any other genre.

You don't let a client program directly modify the server's concept of state, such as how much resources a side has available. The client will modify its local perception of state (e.g. adjusting gem quantities during alchemy) but the modifications need to be noted and checked for legality.

You don't let a client program have more information than it should. MP FPSes may often break this, I suspect, and let the clients do LOS testing for computation cost reasons, but they really shouldn't in theory.

You do let a client program submit instructions (proposed modifications to state, essentially) but need to check for bogosity. Having the client record "have this commander with a dwarven hammer forge this item" is very different from having the client itself define the new gem and item inventories.

I'm reminded of Netrek, which had an open client architecture with known protocols and open sources but a two-pronged approach to client security --

(a) 'Blessed' clients tested with cryptography-based challenges, where keys were supplied to certain trusted people who compiled with 'em. Could probably still be bypassed with a proxy-type architecture in which an unblessed client would forward challenge/response to/from a 'blessed' client, although this would be much harder if the challenge/response sequence modified local game state in an obscure but predictable way e.g. depended on and itself changed the state of a PRNG such that the 'unblessed' client would somehow get out of sync in a detectable fashion. Eh.

(b) More importantly, regardless of whether or not the client passes the periodic RSA-based server/response, the server tracks game state and enforces rules. Ships controlled by rogue clients still can't be invulnerable, can't gain energy or repair faster than they should, don't get told the locations or velocities of cloaked ships, don't get told how many armies enemy ships are carrying, can't recharge their phasers any faster, can't fire their torpedoes more often, can't teleport, and so forth, because the server doesn't trust the client. A rogue client -can- have illegal interface mods, such as having turn keys to allow simultaneously changing direction while aiming somewhere else, or automatically correctly leading a target assuming known locations and known, constant velocities (subject to server-imposed torpedo wobble), or even indicating which incoming enemy torpedoes seem likely to hit unless the user alters his velocity vector, but that's much more difficult to control because it doesn't require that the server send or accept anything unusual.

In a game like Dom II, unusual / illegal interface mods wouldn't seem to be a huge potential problem; I could see attempts to set tax policy more efficiently (applying a rule system to each of scores of provinces every turn, say) without user tedium, or archiving previous battle replays for the intelligence value... but it would actually be pretty impressive if somebody managed to write these. Simply editing the gem or item treasury shouldn't be possible, however, without a server detecting that the values aren't in sync.

A host could still cheat, but a sufficiently paranoid system could be set up to defeat cruder attempts like a host modifying data after receiving it, or reading turn files before submitting his own; it would increase the number of Messages -- e.g. players submit files encrypted with single-use keys (key pairs, preferably), all encrypted files duplicated at a second host site (a public key algorithm would allow verification of authorship), both hosts process the same files using the same PRNGs and math, both hopefully coming up with consistent results which could be reasonably checked using message-digest algorithms without revealing unencrypted state to all players. Either host in such a system could potentially learn full game state, but only after their turns were submitted, and it would require conspiracy or freakish luck for a host to be able to edit the turn files. Separate host-controlled game state files could be similarly signed/encrypted using keys submitted by all the players, to reduce the probability of the host being able to independently modify or read that file as well. Feh.

But simply a better architecture with regards to not trusting the client would allow better security with respect to the non-host players without too much fuss over message exchange, and likely without damaging gameplay (it's not like it's an FPS requiring blazing-fast processing coupled with minimal bandwidth and detailed rendering).