I’m afraid, Leknor is basically right.
If you need to make sure (e.g. when money is involved), throw the dice on the server.
This might be annoying and ugly and oppose network overhead that might be significant - but at least it solves THAT problem.
We have the same topic. For us, we CANNOT do much on the server (performance, bandwidth and playability-wise).
One thing I thought off was to download and run a Java class from the server (e.g. at startup and/or from time to time, maybe using WebStart) that reflects the running client, checks wether certain classes are loaded, wether they have the right methods and fields, wether some variable contents are correct, wether the classloader is the one expected … and so on.
The class then sends a checksum to the server where it can be checked against the expected value. If it failes, close line, ban the player forever (hopefully you have his credit card number
).
Of course, this class has to change frequently and unpredictable.
In the end, this can be one of the things making cheats harder - yet not impossible. This might be sufficient if you have a mean to punish cheating attempts, like banning a credit card, keeping money a player had to pay upfront (oh oh, legal issues). This would make cheating dangerous for the cheater.
For our thingy here - we don’t expect it to be very popular and THAT easy to cheat that it won’t be fun to do.
We’d never sacrifice an optimal software design with low bandwidth and server resource needs to these damn cheaters…
But we also don’t want to make money with it 