Pippin -> Anti-Cheat Systems (8/18/2003 8:10:59 AM)
|
I am writing this letter in order to emphasis game-play security with EIA. Too many times I have witnessed great games turn into avoided games due to simple hacks. Sometimes this is the result of simple hex editing, other times it’s due to more sophisticated patching. This is all too common with those familiar in titles by Blizzard & Hasbro, etc. I would like to see EIA being played in many war game clubs. I believe this will be a reality, however it just takes one person fooling around with the package to make a decent mess of things and always lay doubt. However, I have been involved in a few projects in which I saw some good measures taken in order to counter these cheating tactics. Some are better than others, but I will list one that has so far worked well for TCP/IP where dice rolls need to be secure (no intervention). When it comes to dice rolling, it is common practice to grab any dice rolls from a current phasing side. Though sometimes the user hosting the game is giving this as a full position. What ever the case, because one user is controlling the dice, this is what causes the hazard. It is much too easy for someone to intercept their own dice rolls and substitute these for values of their own liking. Naturally, it is a habit for people to want to win, and this temptation becomes too great for some. HOWEVER, if a combined key system were used, this will eliminate the falsification of the random dice as no one user can control the dice at any given time. This is how it works. A battle is about to be fought, and X amount of dice rolls need to be done. At this moment, each player’s system (up to 7 users in EIA), draft up a random number. These numbers in turn are then sent to each other, & combined through an algorithm making use of XOR operations and what other operations the developer has decided. From these X amount of combined keys, the dice values are determined. If any tampering had occurred, the other 6 players would know since there was a disagreement despite using the same keys on the same algorithm. Though this is not a problem anyhow, as the game would most likely crash at that point. The only precaution needed, is to not supply the dice TOO early, as a cheater could look into the future buffer (so to speak), and then decide which action to take depending on the next dice in the que. Hopefully, MG takes this point strongly into consideration. If anyone else has any other pointers, I’d like to hear.
|
|
|
|