19 Jan, 2012, JohnnyStarr wrote in the 1st comment:
Votes: 0
My current project separates mud / lib. The mud portion is on the server. The lib is
primarily written in javascript for the client end. Without getting to in depth, I can
tell you that the client-side hooks into the server via AJAX and retrieves a minimal
JSON packet.

I haven't worked out all the kinks, but so far I'm very pleased with the speed and the
potential for client customization; images, music, widgets, etc.

Right now, I am just outputting links to the javascript files via a recursive algorithm.
This allows me to arbitrarily change the folder structure.

However, once the client gets a hold of the source files, the entire library is viewable.

I don't view this as too much of a problem in terms of sharing code. If all goes well, I
will release a final version. But, security is another story all together.

And by security, I mean cheating. I suppose obfuscation won't stop an eager nerd who is
willing to decode the library.

I don't want to resort to having to write the library in PHP. Right now, all PHP is doing
is fetching database information and returning quick results through a 'hook' / ajax system
I've developed.

I'm at a very early stage in development, so I don't mind taking an alternate route, but I'm
not sure what that would be.

PS: The primary goal, is to provide a codebase that can run on any web-server. I'm not currently
interested in node.js or any sort of TCP/IP options.
19 Jan, 2012, Runter wrote in the 2nd comment:
Votes: 0
Yeah, you're designing the Hindenburg. Fundamentally, for an MMO to be secure (such that a player can't cheat), it must not depend on the client for computation of game logic. The client can compute in parellel such that you may be able to avoid latency, but never unilaterally without sanity checking the server at each step of the way. In other words, the server must not depend on the client; it should have access to the state as a read only object. And the only way to do that is that the state, and the processes by which the state is changed, is done on a trusted machine. (Your server.)

So the only thing a client should be able to do is what mud clients can do. They get information about the state of the game and they display it. They transmit instructions to be carried out. They modify state through these carefully designed interfaces that exist to give access to processes only the server has authority over.
19 Jan, 2012, JohnnyStarr wrote in the 3rd comment:
Votes: 0
@Runter

Very good points to consider. It seems that I really don't have much of a choice other than to
rely on the server to do the heavy lifting. I was hoping on the client being able to handle timed
events, battle and other things. I don't know how, but I imagine the client could be hacked to alter
character data and what have you.
19 Jan, 2012, Runter wrote in the 4th comment:
Votes: 0
You'd be surprised at how easily it is to modify javascript and/or the messages it transmits. It's also very easy to clean up the code enough to read it even if it's in a compiled state. You're facing the same problems websites have faced for ages.
0.0/4