|
I don't think you understand what I meant. A simple example would be something like this (very simple):
[code] Server>
function send_update
send Current_Seed
end function
function send_request
send Time
end function
function recieve_code (Client_Code)
if Client_Code <> Current_Seed + Time * 3 then
call Report_Bad_Client
end if
end function
Client>
function update (Seed)
set Current_Seed = Seed
end function
function seed_requested(Time)
send Current_Seed + Time * 3
end function[/quote]
Now, the test itself is 100% random. The method used still needs to sync, based on what "time" the server thinks it is, so the correct response is returned, but the method used to get it could be a complex algorythm, not just "Current_Seed + Time * 3". Understand what I mean?
See, this could work, without completely ****ing off the player base. The problem with your approach is that, unless I am missing something, you have to download an update to the client every day. It would certainly frustrate me, since I don't have anything but dialup. It might still bug people that have better connections. And there are problems with you making mistakes in the client, which make it fail with the server, bugs that can cause crashes in the client, etc. Every time you have to change the binary of the program to adjust the encryption, you risk having and entire mud full of players wondering, "Why can't I connect?", or, "Why does by client keep crashing."
And, as someone else pointed out, the minor form of safeguard you are talking about "may" be covered in some countries under "interoperability" statutes. A full encrypted system, which uses a clear algorythm, would be covered under either the DMCA or other legislation, including that it other countries, where encrypting a few bits may not quite qualify in that country.
And you "need" to consider all of those things. The mud I play on is running in Sweden and populated by people from Sweden, England, Canada, the US and I think even one Australian. Exactly "which" countries legal stance covers you attempt to prevent duplication of the client? Probably half the players "may" be on dialup, since its one of the few things you can play that work right over it, so constant downloads of patches is "not" going to make those people happy. I know at least two people, out of about 100 "active" players on the mud I play that use text readers, and several others that have worked on tying them into Mushclient, so they can use it. And then, as I mentioned, there are all the things that go wrong.
Now, personally, the mud I play one has **very clear** guidelines for botting, and people *have* been permanently banned for doing so. Scripting they don't care as much about, as long as it only provides information to the player and "never" acts as proxy to their own input. Harder to catch, but people are "still" caught at it. I happen to be one of those that use various scripts to help me play, **none** of which directly send anyting to the mud itself, unless I specifically type something to initiate it, and even then, most of it is indirect stuff, like changing my description based on my mood, custom random emotes, etc. There is no way in hades I would use a client that cut me off from the ability to do this. I doubt "anyone" that plays on my mud would, no matter what "features" the client included as standard. In fact, most of the people there now use Mushclient, "precisely" because, even though most don't use its scripting at all, even its basic features tend to do more than most other clients.
I find it hard to imagine what could or would make playing some place that uses such a client would "possibly" make it worth all the hassles, unless the process by which the clients are authenticated is 100% transparent. But nearly any such system "can't" include the sorts of updates you are talking about, nor are most of them impossible to hack.
|