   An alternate look at this MMO insanity
  Hey,First off, i would like to say that no, i have not in fact only just joined Gamedev forums. I think i let my account get deleted somewhere around the time of the attempted attacks.. I tend not to log in unless i have something to say, which has been nothing for a couple years now.Anyway, i've been seeing many people following this "i wanna make a MMORPG" cliche, and its been making me wonder the possible reasons:(personal opinion, obviously)1. Supposed monetary gain2. the concept of creating a world in itselfNow, thinking along the lines of the latter, there have been a few cases of people thinking "i want to make a MMO" when they really want is something more along the lines of the old GIGAS engine once being developed for gamepark.That thing was awesome. It was an "RPG Maker", but, instead of being a toolchain and editors, etc, it had the editors for the game embedded within the game itself.I've been tossing this idea around for a few months now, and i've thrown together an idea, not for an MMO or the likes, but instead a server and client concept that would allow such things to be created, given enough basic skills and creativity.The idea revolves around almost everything being controlled by scripts. exposing the functionality of the server itself to scripts accessible by the clients (with restrictions, of course), and in fact represented as game objects. Building a world involves writing scripts within the game itself, using the client, attaching them to objects, and replicating said objects, and so on. Running off of the MMO concept, for instance, NPC's and monsters would actually be connecting clients spawned by the server, or by a seperate process.However, i am having trouble getting to user authentication. I have never done anything security related, so this isn't really my area.Currently, there is no user authentication implemented in the code. I am using Zoidcom for networking, and the clients are allowed to access anything they want on the server. There is no game persistence code either as of yet, object instances reset on server restart, but scripts and sprites, etc, sent to the server are recorded in flat files, but i can easily move game objects and variables to a database if it is the best way to authenticate everything..So i guess i am asking, how exactly should i implement authentication?Should i: store a list of users and privileges (such as running certain scripts and moving objects) as a table, giving each object (scripts being counted as objects themselves) a string containing the username, which the server then checks before performing any actions.That seems to be the only way to do it, but i'm not sure if there are any caveats. i'm guessing that at the very least that the server should associate the current session with a username/password combo.. but if i don't send the password to the server with every request, can the session be spoofed?and is there any alternate way to authenticate users?Finally, if anyone is interested in the engine in more detail, I have written some design drafts, which i will be more than happy to post as well. I can also dig up and clean up some tech demos I've written over the last week.Hopefully this isn't too long, and that you can understand what i've written, my thoughts can come out a bit jumbled sometimes, heh..   
  You're thinking of a MUSH. Some MUDs also allow players to build things, but tinyMUSH and descendants are designed around the idea of players creating the world they play in.   ;  You will want to study SecondLife's design, which already does everything you describe, and is apparently safe enough to support real currency. They also have/had to deal with considerable security and scalability issues with their design.   ;  Maybe you should think along the lines of UNIX file permissions? Instead of associating each object with a user name, an object would have an owner field and a group field. The owner field would be the database ID of the player who created the object (initially -- said player might transfer ownership?). The group field would be the ID of a group of players to which the owner belongs. Finally, using a bitmask, you can assign various permissions to the owner, his group, and to everyone else.If you need more fine-grained control you can always add access control information for individual users on top of the simple UNIX permission model. For example, let's assume that player A wants to grant his friend, player B, the right to modify one of A's objects. B belongs to A's group, so he could simply grant the entire group modify permission on said object. However, what if he wants to give it exclusively to B? In that case, another access control record is added to the object, and bound to B's player ID.   