[MUD-Dev] Re: Using HTML for a Mud character generator

[John Bertoglio]

From: s001gmu at nova.wright.edu <s001gmu at nova.wright.edu>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Wednesday, May 13, 1998 7:55 AM
>
>On Wed, 13 May 1998, John Bertoglio wrote:
>
>[...]
>
>> Of course the server will have to make the same checks as the JS in the
>> form so players with HTML savvy can't create monster characters by
>> overriding the internal limits. This hacking element makes the backend
work
>> so much more complicated than it really needs to be.....
>
>You should be able to hide the entire contents of the javascript code by
>referencing a file, rather than embedding the script code in the html that
>they DL.  The java script still gets DL'd (of course), and executed
>locally, but should they choose to look at the html source, all they see
>is a tag referencing a file.  I don't recall the details (I've never
>worked in javascript), but I do know you can do it.

The key is the form code is exposed to users. They can easily take the
HTML, cut out the javascript validation routines and submit numbers outside
of the established limits. You cannot actually hide the code. You can use a
file include and this is good practice once the code is stablized.

My actual point was more general: Designers can not trust the output from
their client program if any calculation takes place that has in-game
consequences. This vastly complicates using standard client-server
techniques to reduce server loading. Essentially, all significant
processing has to be done by the server. Take a over-simplified example:
Most inventory control numbers (stock numbers) use a check digit scheme
where they perform a simple calculation on the numeric values of the stock
number to generate the final digit. This dramatically lowers the number of
bad numbers entered into the system because if you miss-type a number,
there is 90% (actually even higher than 90%) chance the check digit will
flag it as an invalid number. This calculation can be performed in the
client program. Bad numbers beep and prompt for a reentry. The server does
not have recheck the numbers, so this (minor) load is distributed to all
the client programs.

In game clients, it would be easy to download player information to the
client and do a lot of work on the local computer. But the client programs
are then hacked and rigged so the users have special advantages. Data
encryption can be done in the client, but you are trading one process for
another since the data stream must be deencrypted (if that is a word?) back
in the server.

Having said that, I think I would design the client (not an issue for me
since it is currently beyond my skills to do so) to handle as much
processing as possible and encrypt the data flow. The advantages of doing
so are just to great. In addition, I would follow the model of one of the
new online startups. They have stated that any modification of their client
software will be considered an attack on their server. This apparently puts
the game hacker in the same class as someone hired to crash a coporate or
government server. The offense is federal and the penalties are very
severe....who knows it might work. (No, I don't know how you would handle a
hacker in Burma...)

>[...]
>
>-Greg
>
>
>--
>MUD-Dev: Advancing an unrealised future.
>



--
MUD-Dev: Advancing an unrealised future.