Anti Cheat-tecniques

Started by
52 comments, last by ajoling 19 years, 10 months ago
quote:Original post by bmsfx
they idea behind it was that the item db server & gameserver had a ID system for each item dropped generatet from server (hardcoded, item ID will NOT change if dropped and picked up or anything)

Example on a ID way :

year-month-day-hour-minute-second-millisecond-dropid

where dropid = what drop it or where it was purchased.

eg:

20040604143619301521


I don''t want to be harsh or anything, but if your server is well designed, such an anti-duping system wouldn''t be useful
If there was any duping problem, it should be solved in the server design, not by implementing huges IDs based on timestamp.
I cannot see how some lag would allow you to dupe items if your server architecture is nicely done.
Darkhaven Beta-test stage coming soon.
Advertisement
The difference is whether you treat items like game stats (I have 3 +10 Flaming Banana Swords) or like items with their own identity (I have items 236, 457 and 11238).

Items with identity means that duping is hard, but it also introduces significant overhead. I know, I''ve shipped product using that method! However, it has so many other nice properties (including no-duping) that I think it''s worth the overhead.

Also, if you want a scalable system, you want to support players on more than one physical database server machine. Thus, if I trade you an axe for a donut, the transaction of "remove my axe, give me the donut, remove your donut, give you the axe" needs to have transactional semantics, which pretty much requires a transaction monitor and two-phase commit style of implementation. Or just defer it to a clustered database back-end -- but then, be prepared for huge server software costs, and really terrible performance.
enum Bool { True, False, FileNotFound };
quote:Original post by hplus0603
Nice Coder,

Nice try, but no prize. When your ISP changes your IP address (which happens every once in a while), something not depending on DNS would go to some host not under your control anymore. Whoever is on that host could have a field day, downloading adware, keyboard sniffers, viruses, and whatever else they liked to your client.


Close, but no cigar.
Asymetric encryption would mean that your servers could distribute the patches, but no-one could put in data!
Also, i would get multiple free web accounts (geocities, netfirms, ect.). And have them all have the ip adress of the server. if one of them does not match, no download is performed. During the time that your ip adress changes (midnight on the last day of the month iirc) You set them alll to NODOWNLOAD. Once you have your ip adress, you change them back to your ip.

Click here to patch the mozilla IDN exploit, or click Here then type in Network.enableidn and set its value to false. Restart the browser for the patches to work.
quote:Original post by Pxtl
Ultimately, the way to beat aimbots is to design a game such that a computer could not beat possibly beat a human at it. That is pretty hard.
Well that kind of destroys having bots in FPS games doesn''t it?
I think some kind of intelligence techniques are best to stop doping. Just using statistics is no good though - with a million people playing even an average player can have an amazing run every now and then. Unless someone gets like 100 headshots consecutively that''s hard to detect. If you throw out all the top players...

This topic is closed to new replies.

Advertisement